您现在的位置：首页 --> 查看专题： NOSql
今天在书店里翻完了一遍《七天七数据库》。这本书简单介绍了postgreSQL，riak，mongodb，HBase，riak，Neo4j，redis七个数据，并着重谈了数据库的特性差异和在部署维护时候的特点，并对不同需求下的数据库选型做了很多建议，感觉受益非浅。 我的几个项目，都遇到了mysql 向nosql过渡的问题，应该如何选型，我终于有了初步的方案。
关系数据库的不足：
a. 不能很好的为Web 2.0的业务做建模（搜索与社交图谱），
b. 无法在数据库层面很好的与JSON等做数据交换,
c. SQL语言与编程语言的差异带来的开发学习使用成本,
d.是否开源，代码能否改动,
f. 关系数据库的优化器、解析器代价太大，影响响应时间、吞吐量，
g.不能很好的满足业务对Scalability以及低成本服务器的需求，
h.在Scale out的情况下的管理复杂度，
i. 不能方便的调整业务的ACID需求，主要为Relax Consistency与Relax Durability的需求。
NoSQL根据不同的数据模型，大致可以分为4类，分别是键值对存储(Key-Value Stores)，列族存储(Column Families)，文档数据库(Document Databases)以及图形数据库(Graph Databases)。四者从容量来讲，依次下降，而从复杂度来说则相反。 下面我根据最近看的一些资料，列出了目前常见的NoSQL数据库系统的一些主要特性，不一定都正确。另外，后面列了一些参考资料，偏向于PostgreSQL，个人觉得还不错。
2012年5月10日，Sauce Labs公司的首席架构师Steven Hazel，写了一篇关于弃用NoSQL数据库CouchDB产品，介绍他们将Couch数据库的数据迁移到MySQL数据库平台中。 在Sauce Lab(酱油实验室)里，我们刚刚庆祝完成一个重大项目—将最后的CouchDB数据库转变为MySQL数据库，以提高服务正常运行时间和可靠性。 由于大部分无故停机的是由于CouchDB数据库宕机引起的，因此完成这种迁移是我们一个重要的里程碑。
本文是对《big data glossary》第三章MapReduce的个人翻译，无版权 在传统的关系数据库世界中，所有的处理都发生在信息被载入存储之后，使用特定的查询语言处理高度结构化和优化的数据结构。而由Google引领，然后被许多其他网络公司所接纳的替代方式是：创建一个读写任意格式文件的流水线，在每个阶段以文件的方式交换中间结果，并且跨机器分布计算。通常基于MapReduce方法进行分布式工作的方法都需要一套全新的工具，我将在下面介绍。 Hadoop 最初是由Yahoo！开发的一套Google MapReduce架构的克隆系统，但随后被开源。Hadoop帮助你的代码在跨机器的集群上运行。它负责对输入的数据分块，并发送到各自对应的机器，在每个分块上运行代码，监测运行的代码，将结果发送到下一步的处理阶段或者最终存储下来，执行发生在map和reduce阶段间的排序工作并将排序后的数据发送到
近日Oracle提供了不久前公布的NoSQL数据库的下载，目前只有企业版，开源的社区版还没提供，也就是说还看不到源码。不过根据文档也能大致了解这个NoSQL数据库怎么样。快速看了看，总结如下。一、数据模型key包含一到多个major key component和零到多个minor key component，组合起来唯一标准一条记录。key component为Java String，按对应encoding排序。value则是字节流。key和value的大小都没有严格限制。记录还有版本号，每次更新...
NoSQL现在风生水起，hbase的使用也越来越广，但目前几乎所有的NoSQL产品在运维上都没法和DB相提并论，在这篇blog中来总结下我们在运维hbase时的一些问题以及解决的方法，也希望得到更多hbase同行们的建议，:) 在运维hbase时，目前我们最为关注的主要是三大方面的状况： 1. Cluster load； 2. 读写； 3. 磁盘空间。
TCMalloc(Thread-Caching Malloc)是google开发的开源工具──“google-perftools”中的成员。与标准的glibc库的malloc相比，TCMalloc在内存的分配上效率和速度要高得多，可以在很大程度上提高MySQL服务器在高并发情况下的性能，降低系统负载。
RDBMS的优势在于功能，包括事务，强一致性，同时支持随机读和顺序扫描，索引。NOSQL系统的优势在于扩展性和性能。Google的经验告诉我们，系统设计的关键点还是在于可扩展性，依赖于底层GFS+Bigtable提供的无与伦比的可扩展性，Megastore能够在上层不断完善功能，兼具RDBMS和NOSQL系统的优点。 1, 兼顾随机读和顺序扫描。Bigtable底层的存储引擎为MemTable + SSTable构成的Merge-Dump存储引擎，SSTable设计成8K ~ 64K的块，块之间有...
由于 MySQL 的局限性，很多站点都采用了 MySQL+Memcached 的架构。另外一些站点放弃 MySQL 而采用 NoSQL，比如 TokyoCabinet/Tyrant 等。不可否认，在做一些简单查询 (尤其 PK 查询) 的时候，NoSQL 比 MySQL 要快很多很多。而且网站上的绝大多数查询都是这样的简单查询。 像其他大规模的公司一样，DeNA 也面临过类似的问题。但最后...
在NoSQL的许多产品中，我们通过benchmark可以看到的都是写性能极度提升，而读性能并没有太大的涨幅甚至相对传统RDBMS还有下降。比如Cassandra，MongoDB这两个NoSQL的杰出代表。究其原因，我们可能会想到是因为当前UGC模式已经发展到白热化，用户产生内容导致读写比已经接近或者说小于1：1。
NOSQL系统一般都会宣传一个特性，那就是性能好，然后为什么呢？关系型数据库发展了这么多年，各种优化工作已经做得很深了，NOSQL系统一般都是吸收关系型数据库的技术，然后，到底是什么因素束缚了关系型数据库的性能呢？我们从系统设计的角度看这个问题。
随着数据存储技术的迅猛发展，随着各种 NoSQL 技术的产生，无论是我们同事之间还是整个互联网行业，都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种： 去关系型，NoSQL是王道 NoSQL靠边站，关系型才是王道以关系型为核心，NoSQL为补充 三种意见中前面两种观点较为极端，都是“非对即错”的选择，当然也有更为理性的第三种方案。如果作为开发人员，从我目前所了解的信...
在历史工程上修补是件麻烦的事情。前两天说起梦幻西游服务器的优化。这几天我到广州住下来，打算专门花一周时间搞定这件事。由于以前都是网上聊天，只有坐到一起才能真正理解问题。目前，梦幻西游，只使用单台机器，最高配置 8 个 CPU ，配置 8G 内存。就算最热闹的服务器，也用不完这些资源（大约只用满了 3 个 CPU ，一半的内存）。核心程序差不多就是 10 年前写的，从大话西游延续至今。这两年一直在享受免费的午餐，随着硬件配...
跟着时下炒得火热的NOSQL潮流，学习了一下mongodb，记录在此，希望与感兴趣的同学一起研究！ MongoDB概述 mongodb由C++写就，其名字来自humongous这个单词的中间部分，是由10gen开发并维护的,关于它的一个最简洁描述为：scalable, high-performance, open source, schema-free, document-oriented database。MongoDB的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两...
最近几个尝试性的Cassandra应用中碰到了一些问题，在查找问题的过程中发现之前有些理解不到位，或者有偏差遗漏的地方，在v0.1的基础上，修改补充了小部分内容。从实际应用来看，Cassandra节点的稳定性还有很多工作要做，而实际系统的运维也还有很多的细节需要逐步规范下来。此PPT中有错漏或者待补充完善的地方，也欢迎大家指正。
[ 共32篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
近3天十大热文
-
[67] Go Reflect 性能 -
[65] Oracle MTS模式下 进程地址与会话信
-
[62] 如何拿下简短的域名
-
[60] 【社会化设计】自我（self）部分――欢迎区
-
[60] android 开发入门
-
[58] 图书馆的世界纪录
-
[58] IOS安全–浅谈关于IOS加固的几种方法
-
[54] 视觉调整－设计师 vs. 逻辑
-
[48] 界面设计速成
-
[47] 给自己的字体课（一）——英文字体基础
赞助商广告
