该比较是以延迟和吞吐量为衡量指标，吞吐量越大，造成的延迟就越大，这是一对矛盾，那么哪个NOSQL数据库能够在这对矛盾中做得更好呢？
首先是大量数据Load加载，一亿的数据加载比较如下：
横坐标是吞吐量，纵坐标是延迟，吞吐量越大，延迟越小越好，图中HBase获胜。
HBase 和 Cassandra 写性能方面遥遥领先。
HBase客户端配置为 AutoFlush关闭. 修改聚合在客户端buffer中，一旦缓冲满了，将异步追加写flushed，为了加速服务器端修改处理， 启用延迟日志 flush。在flush阶段WAL edits保存在内存中。
Cassandra写可变数据到commit日志，然后内存in-memory Memtable表更新，这将会慢些，但是比HBase的延迟日志flush将更安全。
下图是各个数据库在读方面能力的性能比较图：
HBase 和 Cassandra不但写能力领域，在电子商务读写1:1情况下，读能力也很强，据此可以认为HBase 和 Cassandra适合读修改1:1的应用场合。
[该贴被banq于2012-11-03 18:17修改过]
[该贴被banq于2012-11-03 18:17修改过]
传统MYSQL在碎片分区下Sharded MySQL读性能最好，MongoDB因为内存映射文件(Memory-mapped files )类型的缓存名列第二， 内存映射文件用户所有MongoDB的磁盘I/O； Cassandra的主键key和列缓存能够有利于频繁读取数据，特别是0.8版本增加了off-heap(超越JVM内部Heap)列缓存特性，显示它有相当的读取性能。主键key缓存保存每一列所有的Key在。因此不再需要查询SSTable索引文件，得益于行缓存，也不必从SSTable中读取行数据；而HBase的随机读取性能就慢了。
那么在以读为主的操作中，四个数据库的修改性能如何？
还是HBase和Cassandra获胜。看来这两个数据库写能力一直很坚强。
只读情况下，sharded MySQL因为缓存和B-tree索引获得胜利。
只有Cassandra和HBase比较，其他数据库或不支持扫描，或其他原因。
HBase性能最好：高吞吐量低延迟。
总结：根据自己业务应用系统的读写频繁度选择相应的NoSQL。
问了很多以前用过mongodb的朋友，都说性能不怎么样。项目开始的时候用，但是后来又转成mysql了。
但是我去SO去问问题，总有人推荐我使用mongodb，现在真不知道这个技术到底怎么样。
banq来个权威的解答吧。mongodb不想mysql那样死板，所以现在非常想用，但是还怕性能不行。
主要选择依据是读写比例，但是这个读写比例操作起来有难度，很多时候只有等到系统完成上线运行后才能知道这个读写比例。但是这时更换数据库相当于更换底层设施，不亚于在新马路上打洞。
有没有在写代码前完成正确的选型呢？
使用CQRS架构。
CQRS也是一种读写分离的架构，写的操作是命令，读的操作是查询，写和读是两条路线，很显然，写路线的存储采取写能力特别快的NoSQL如HBase或Cassandra；而读路线采取读能力比较快，比如Sharded MySQL或MongoDB。
关键是两者同步，结合Event Sourcing，写路线存储的应该是写事件，那么通过一个定时Job，不断从写存储数据库中读取写事件，通过逻辑播放，将结果再写入读数据库中即可。当然逻辑播放是一种批处理机制。如下图：
相关帖：面向事件的数据库
[该贴被banq于2012-11-06 11:00修改过]
