分布式key-value存储系统的比较列表

http://blog.csdn.net/startfromheart/article/details/4583169

也许你正在考虑使用 专门的 key-value 或 document 存储，而不是传统的关系数据库。
原因可能包括以下几个方面：

1. 你对云计算(Cloud-computing)极端痴迷;
2. 为自己找一个使用Elang的理由;
3. 你听说CouchDB很酷;
4. 你对MySQL不感冒，尽管PostgreSQL是好得多，但仍没有象样的复制机制。没钱购买Oralce的许可;
5. 您的数据存储和检索主要是通过主键进行，没有复杂数据关联。
6. 面对海量数据时候，传统关系型数据库的大量数据碎片以及复制失败时的情景，让你感到后怕。

无论基于那种原因，你总是会有非常多的选择。在Last.fm时候，我们在Hadoop中做了大量的批量计算，并将结果导出到另外的机器进行索引，然后通过HTTP来提供服务(比如：这周在英国伦敦最流行的音乐是啥)。目前我们使用自己定义的索引格式，通过关键值，来指向一些大数据。类似于这篇文章中提到 Facebook照片方法。这已经能正常工作了，但是由于上面提到的4，5，6原因，我们正在寻一个分布式，可扩展的key-value的存储系统,而不是在此之上建立我们自己的的复制和分区系统。

词汇与背景阅读：

• Distributed Hash Table (DHT) and algorithms such as Chord or Kadmelia
• Amazon’s Dynamo Paper, and this ReadWriteWeb article about Dynamo which explains why such a system is invaluable
• Amazon’s SimpleDB Service, and some commentary
• Google’s BigTable paper
• The Paxos Algorithm -  读取这篇文章是是为了让你了解，Paxos的实现，是不是正是你想要做的。

下表是一些可能用来替代关系型数据库的系统，其中一些不仅仅是key-value的存储系统，其中一些不适用于low-latency data serving，但是这些仍然非常值得关注。

项目名称
语言
容错性
持久性存储介质
客户端协议
数据模型
文档
赞助商/社区

Project Voldemort
Java
partitioned, replicated, read-repair
Pluggable: BerkleyDB, Mysql
Java API
Structured/blob/text
A
Linkedin, no

Ringo
Erlang
partitioned, replicated, immutable
Custom on-disk (append only log)
HTTP
blob
B
Nokia, no

Scalaris
Erlang
partitioned, replicated, paxos
In-memory only
Erlang, Java, HTTP
blob
B
OnScale, no

Kai
Erlang
partitioned, replicated?
On-disk Dets file
Memcached
blob
C
no

Dynomite
Erlang
partitioned, replicated
Pluggable: couch, dets
Custom ascii, Thrift
blob
D+
Powerset, no

MemcacheDB
C
replication
BerkleyDB
Memcached
blob
B
some

ThruDB
C++
Replication
Pluggable: BerkleyDB, Custom, Mysql, S3
Thrift
Document oriented
C+
Third rail, unsure

CouchDB
Erlang
Replication, partitioning?
Custom on-disk
HTTP, json
Document oriented (json)
A
Apache, yes

Cassandra
Java
Replication, partitioning
Custom on-disk
Thrift
Bigtable meets Dynamo
F
Facebook, no

HBase
Java
Replication, partitioning
Custom on-disk
Custom API, Thrift, Rest
Bigtable
A
Apache, yes

Hypertable
C++
Replication, partitioning
Custom on-disk
Thrift, other
Bigtable
A
Zvents, Baidu, yes

我所寻找的系统是一个低延迟，自动复制，分布式的key-value存贮系统，扩展简单，维护方便，api也非常简单，只是简单hash维护，set(key, val), get(key), delete(key) 等等，因而，以上列表中有5个并不能达到要求，但是他们还是值得一提的：

1. Hbase 在hadoop中有重要的应用，然而因为延迟现象严重，所以并不适合我们的需要
2. Hypertable 受google的 bigtable项目而创建，最近百度成了他的赞助商，但是这个项目同样因为延迟而不符合要求
3. Cassandra 好像Facebook从来没有真正把它当作开源项目运作，极度缺乏文档。
4. CouchDB ，总体来说是个不错的项目，可以通过RESTful HTTP/JSON API 与数据交互，然而应该来说还不够成熟，要达到像数据库字段一样的存储，包含一个一个字段的内容，还有有一段路要走
5. ThruDB 不错的文档存储引擎，包含了四个部分，但是因为与Couchdb同样的原因，也被放弃了。

除去以上5个，剩下列表中的都可以作为分布式KV存储系统的备选，基本上都有很好的扩展性，以及low latency

1、MemcacheDB 采用在后端BDB存储数据，然而在数据库sharding以及复制方面还没有考虑（原文如此，似乎最新的版本已经做了部分的考虑），其他的 memcached sevrer 比如repcached 考虑了复制问题，但是在sharding上没有做好。

2、Project Voldemort 看起来非常不错。官方网站的Design章节，包含如何运行，结构示意图，hash描述文档等。Project Voldemort非常容易复制和分区数据，并非常容易使用和架构。我们可以很容易看到，系统如何交互以及对各个不同组件进行测试。它不能对运行中集群运行中添加节点，但是按照官方的邮件列表说明他们正在做这方面的工作。如果和java的负载均衡服务结合起来(参考物理结构图)，并暴露出Thrift的接口供非java的客户端使用，看起来将很适合我们的要求。

– 未完，其他参考本地址原文 –
==========================================================
Benchmark Test of DBM Brothers(嵌入式db测试比较)
Benchmark Test of DBM Brothers

This benchmark test is to calculate processing time (real time) and file size of database.
Writing test is to store 1,000,000 records. Reading test is to fetch all of its records.
Both of the key and the value of each record are such 8-byte strings as `00000001', `00000002', `00000003'...
Tuning parameters of each DBM are set to display its best performance.
Platform: Linux 2.4.31 kernel, EXT2 file system, Pentium4 1.7GHz CPU, 1024MB RAM, ThinkPad T42
Compilation: gcc 3.3.2 (using -O3), glibc 2.3.3

Result
NAME
DESCRIPTION
WRITE TIME
READ TIME
FILE SIZE
QDBM
Quick Database Manager 1.8.74
1.89
1.58
55257
NDBM
New Database Manager 5.1
8.07
7.79
814457
SDBM
Substitute Database Manager 1.0.2
11.32
0.00
606720
GDBM
GNU Database Manager 1.8.3
14.01
5.36
82788
TDB
Trivial Database 1.0.6
9.64
2.22
51056
CDB
Tiny Constant Database 0.75
0.87
0.80
39065
BDB
Berkeley DB 4.4.20
9.62
5.62
40956
QDBM-BT-ASC
B+ tree API of QDBM (ascending order)
2.37
1.78
24304
QDBM-BT-RND
B+ tree API of QDBM (at random)
10.90
4.82
15362
BDB-BT-ASC
B+ tree API of BDB (ascending order)
3.04
3.06
27520
BDB-BT-RND
B+ tree API of BDB (at random)
10.03
4.15
29120

本人用过BDB分别在java和python下的使用，可以说在java环境下使用确实很麻烦，在python下使用非常方便，而且选择的存储类型也有四种，当然本来python就是比java使用方便。NDBM只有python和c的接口支持，QDBM没有python的接口，可是有perl和 java,c等的支持。