开放原子开发者工作坊

参考Paul Graham比较各种编程语言的方法，我们比较各种数据库的特点如下：

Oracle: 我们需要企业级数据库。

MySQL: Oracle不开源。

PostgreSQL: MySQL的功能不够多。

SQLite: 你可以把我嵌入到任何地方。这样，4种数据库够大家用了。

MongoDB: 为什么我们要用join和模式(schema)?

CouchDB: 为什么我们要有集合(collection)?

Redis: 为什么我们要面向文档？

Memcached: 为什么我们要用硬盘？

Neo4j: SQL缺乏足够的关系。

Bigtable: MongoDB的对web的扩展性不管好。

Hbase: Bigtable不开源。

Cassandra: Bigtable不是Facebook开发的。

Riak: Cassandra不是用Erlang语言编写的。

OrientDB: 让我们把所有东西都放到同一个数据库里！

 

下面看看各种数据库的特点，或许会更清楚其中的幽默～

 

一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet，levelDB

Redis

Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个 数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处 理超过10万次读写操作，是我知道的性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例 如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。

levelDB：LevelDB是Google开源出的一个Key/Value存储引擎，它采用C++编写的，支持高并发访问和写入，特别适合对于高写入业务环境。影像数据库读次数远大于写。

sqlLite：多个进程或线程可以访问同一个数据。可以并行的满足多个读访问。但是只能有一个进行写访问；否则写访问失败并带有一个错误代码(也可以在可配置的超时过期之后自动的重试)。缺点：采用文件锁机制，限制了读写并行执行。

FastDb： 是高效的内存数据库系统，具备实时能力及便利的C++接口。

缺点：FastDB不支持client-server架构因而所有使用FastDB的应 用程序必须运行在同一主机上。对每一 个使用数据库的应用数据库文件被影射到虚拟内存空间中，因而它受物理内存空间大小的限制。

Hibari ：（在日语中意思为“云雀”）是一个专为高可靠性和大数据存储的数据库引擎，可用于云计算环境中，例如 webmail、SNS 和其他要求T/P级数据存储的环境中。Hibari 支持 Java, C/C++, Python, Ruby, 和 Erlang 语言的客户端。

Hibari 并不是一个关系数据库，主要是通过 key-value 的方法进行数据存储。

主要特点：

• A Hibari cluster is a distributed system.
• A Hibari cluster is linearly scalable.
• A Hibari cluster is highly available.
• All updates are durable.
• All updates are strongly consistent.
• All client operations are lockless.
• A Hibari cluster’s performance is excellent.
• Multiple client access protocols are available.
• Data is repaired automatically after a server failure.
• Cluster configuration can be changed at any time.
• Data is automatically rebalanced.
• Heterogeneous hardware support is easy.
• Micro-transactions simplify creation of robust client applications.
• Per-table configurable performance options are available

二、 满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB

1、MongoDB

MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是 类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语 言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的 10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读 写性能，我（robbin）也打算有空的时候好好测试一下。

因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。

最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是 特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著 的提升。

MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。

2、CouchDB

CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于 HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。

三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort

面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数 据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点 等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：

1、Cassandra

Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而 开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。

Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会 被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事 情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。

Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台 架构部门领导Evan Weaver写了一篇文章介绍Cassandra：http://blog.evanweaver.com/articles/2009/07/06 /up-and-running-with-cassandra/，有非常详细的介绍。

Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看 到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并 发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

2、Voldemort

Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个 SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读 写性能也很不错，每秒超过了1.5万次读写。

从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库， 特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩 展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在 Cassandra这么热门的主要原因。