影像数据库调研
参考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
如从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
10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读
写性能，我（robbin）也打算有空的时候好好测试一下。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是
特别复杂的Web应用，比方说why we migrated from MySQL to
MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著
的提升。
HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort
据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点
等等。因此像Cassandra常常被看成是一个开源版本的Google
BigTable的替代品。Cassandra和Voldemort都是用Java开发的：
开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了
Facebook之外，twitter和digg.com都在使用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单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并
发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如
Cassandar，Voldemort，Tokyo
Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读
写性能也很不错，每秒超过了1.5万次读写。
特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩
展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在
Cassandra这么热门的主要原因。