[转]分布式key-value存储方案介绍：Cassandra，LightCloud，TokyoCabinet

 Cassandra是一个非常可靠的大规模分布式存储系统。高度可伸缩的、一致的、分布式的结构化key-value存储方案，Facebook目前在使用此系统。

• 开发语言： Java
• 授权协议： Apache License 2.0
• 项目主页： http://incubator.apache.org/cassandra/
• 文档地址： http://wiki.apache.org/cassandra/GettingStarted
• 下载地址：http://hudson.zones.apache.org/hudson/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/

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多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

http://www.oschina.net/p/lightcloud Plurk 前陣子放出 LightCloud，試著解決 Amazon 所提出的 Dynamo 用某些複雜方法解決問題。比起 Dynamo 的優點是：

• 使用 Tokyo Cabinet 當底層，這是目前最快的 key-value database 之一，而且檔案也小。
• 因為使用 Tokyo Cabinet，所以可以用他的 master-master replication 取代 Dynamo 內的 replication，也就是固定以 n = 2 解決問題，以 node 本身的 HA 架構解決 Dynamo 裡面的 consistent 問題。(在 Dynamo 裡透過很多方法解決，變成 eventally consistent)
• 增加機器造成資料需要移動的問題是把 hash ring 拆成兩個，一個 lookup ring，另外一個 storage ring，用兩次 query 解決。這個部份我看不懂他的解法，還要再找資料看他怎麼解的。

這個架構如果可行 (要看他解決 routing problem 的解法是否可以達到 scalability 特性)，那麼就有很多有趣的應用可以在這個架構上跑。(直接當 filesystem 來放資料)

开发语言： C/C++ Python Lua
操作系统： Linux
项目主页： http://opensource.plurk.com/LightCloud/

http://www.162cm.com/archives/681.html Tokyo Cabinet的作者叫Mikio Hirabayashi.用师兄覃健祥的话说，作者很猛很持久.这不，作者出了一个QDBM(类似gdbm,ndbm,sdbm,mdbm的一个dbm),estraier,Hyperestraier（前面介绍过，是一个支持中文等东亚文字，可以p2p架构的搜索引擎实现）等一系列c软件，现在又出了一个:Tokyo Cabinet.
Tokyo Cabinet 项目主页:http://tokyocabinet.sourceforge.net/
简介（翻译成中文了)
Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符 串。这里没有数据类型和数据表的概念。当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提 供key,value参数来存储，按key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM等等是相同的，但是比它们的性能要好得多（因此可以替代它们)。当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。
As for database of fixed-length array, records are stored with unique natural numbers. It is impossible to store two or more records with a key overlaps. Moreover, the length of each record is limited by the specified length. Provided operations are the same as ones of hash database.
对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限 制。读取方法和hash表的一样。Tokyo Cabinet是用C写的，同时提供c,perl,ruby,java的API。Tokyo Cabinet在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。

[...] 前面一篇介绍了Tokyo Cabinet,一个DBM. 作者在写完Tokyo Cabinet之后，立马又写了一个应用:Tokyo Tyrant. 这个东东被定义为:一个网络存储，读取接口。网络时代，加上这么一个功能，马上就可以冠上分布式的标签了。 Tokyo Tyrant基于Tokyo Cabinet实现，提供了HTTP协议和memcache 协议的读取／写入等接口。这 不仅仅是贴上了分布式的标签而已：有了http协议，在大公司复杂网络中部署时很多事情简单多了，因为http端口一般不需要专门申请路由了,而其他端口 上部署应用时，要走一堆流程。而memcache协议则解决了很多人尝试用memcache来存储东西时无法持久存储的问题。有了这两个接口，应用 Tokyo Tyrant时，你都不需要调API,php中用来连Memcached的代码直接使用就行。 张宴同学写得比较详细，更实用.请移步研究。

http://hi.baidu.com/ah__fu/blog/item/0f53ff4cfa493af0d72afc99.html Tokyo Cabinet: 资料管理系统分支中的恐龙之翼

   这个奇怪的标题加无聊的比喻来自与对“The Dinosaur Wing of the DBM Forks”的直译，这是TokyoCabinet的作者Mikio Hirabayashi对自己的作品的宣传语。

DBM这个缩写对于非*NIX血统出生的程序员来说的确有些陌生，DBM是database manager的简写，部分网站翻译为资料管理系统。在*NIX 系统中，似乎已是古老经典的一种key-value存储系统了。
这里有一些经典的DBM系统的介绍：《GDBM/NDBM使用介紹》http://blog.chinaunix.net/u/9861/showart_637998.html
此外，开源数据库界出名的Berkeley DB其实也是DBM系统的一种：http://baike.baidu.com/view/1281930.htm
与TokyoCabinet的功能一模一样的MemcachedDb的持久化存储引擎就是用的Berkeley DB。

下面是“恐龙之翼”这段话的原文：(from: http://tokyocabinet.sourceforge.net/spex-en.html)

    Tokyo Cabinet is developed as the successor of GDBM and QDBM on the following purposes. They are achieved and Tokyo Cabinet replaces conventional DBM products.

• improves space efficiency : smaller size of database file.
• improves time efficiency : faster processing speed.
• improves parallelism : higher performance in multi-thread environment.
• improves usability : simplified API.
• improves robustness : database file is not corrupted even under catastrophic situation.
• supports 64-bit architecture : enormous memory space and database file are available.

    As with QDBM, the following three restrictions of traditional DBM: a process can handle only one database, the size of a key and a value is bounded, a database file is sparse, are cleared. Moreover, the following three restrictions of QDBM: the size of a database file is limited to 2GB, environments with different byte orders can not share a database file, only one thread can search a database at the same time, are cleared.

    Tokyo Cabinet runs very fast. For example, elapsed time to store 1 million records is 0.7 seconds for hash database, and 1.6 seconds for B+ tree database. Moreover, the size of database of Tokyo Cabinet is very small. For example, overhead for a record is 16 bytes for hash database, and 5 bytes for B+ tree database. Furthermore, scalability of Tokyo Cabinet is great. The database size can be up to 8EB (9.22e18 bytes).

TokyoCabinet仅仅只是一个DBM系统吗？不尽然，从TokyoCabinet支持的数据引擎来看，功能还更加丰富。TokyoCabinet的数据引擎提供的API有：
·the on-memory hash database API
·the on-memory tree database API
·the hash API
·the B+ tree database API
·the fixed-length database API
·the table database API
假如去掉持久化存储，只使用on-memory hash和on-memory tree两种引擎，则TokyoCabinet的功能与Memcached一致。希望能有高手做一个对比测试，看看不要持久化的TokyoCabinet与Memcached在set/get性能，内存占用，并发处理三个方面的性能有何差别。当然，TokyoCabinet与Memcached的有些功能是有差别的：
·Memcached里，每个key都有过期时间，而TokyoCabinet没有这个功能；
·Memcached里，内存空间满后，插入会失败，而TokyoCabinet在内存满后会丢弃旧的记录；（这个需验证，根据文档得出这个结论，还没实验）
·Memcached里，PHP的Memcached客户端实现了对value的gzip压缩，Memcached服务器端是不支持GZIP压缩的；而TokyoCabinet中，支持多种压缩方式，但是究竟是服务器端实现了压缩，还是客户端实现了压缩，还不得而知；（如果服务端实现了压缩解压缩，则对带宽无法降低）

再看table database这种方式的存储引擎，这不就是内存表嘛，还支持多个索引，更爽了。这个功能是MemcachedDb无法实现的。

其实，在WEB 2.0的应用中，对于数据不敏感的场合，都可以用TokyoCabinet+TokyoTyrant代替Memcached+MySQL，TokyoCabinet的很多功能都将数据持久化做得相当可靠：
1、在一个进程内同时实现cache和持久化，比起Memcached+MySQL来说，更加方便；（一个例外的问题是，通常请求在Memcached和 MySQL中都无法命中的话，也会cache无法命中的信息，而TokyoCabinet对无法命中的请求也会cache吗？）
2、双机冗余，两台服务器之间自动复制数据，且访问任意一台都可以；（在ttserver的参数中配置即可，相当方便。对于TokyoCabinet的同步能力，网上暂无生动的案例，特别是灾难发生时的恢复能力。如何像一个数据库一样更可靠？TokyoCabinet还需要给使用者更多的案例还增强信心）
3、热备功能：在ttserver上实现了，可以端发起一个命令即实现了热备。
4、冷备：还没发现有这样的功能。
5、数据导入：可以将TSV格式的文本导入到TokyoCabinet中。
6、数据导出：已有的API文档中还未发现这样的功能，不过可以自己写一个基于客户端API的低性能实现。
7、update log日志的导入导出：有这样的功能。
有了以上功能，对于数据的可靠性也有了一定保证，又安全又快速，很值得使用！！！

http://hi.baidu.com/llaa27/blog/item/df7e3e8f710a7ee9f11f3663.html Tokyo Cabinet 是日本人 Mikio Hirabayashi开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。Tokyo Cabinet 是一个DBM的实现【虎.无名：是Mikio另一个产品QDBM的继承者】。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。 当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按 key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM 等等是相同的，但是比它们的性能要好得多（因此可以替代它们)。当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删 除函数也都有提供。记录按照用户提供的比较函数来存储。可 以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。
As for database of fixed-length array, records are stored with unique natural numbers. It is impossible to store two or more records with a key overlaps. Moreover, the length of each record is limited by the specified length. Provided operations are the same as ones of hash database.
对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限 制。读取方法和hash表的一样。Tokyo Cabinet是用C写的，同时提供c,perl,ruby,java的API。Tokyo Cabinet在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。
Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。
上面是我从网上摘录的部分介绍~~
用Tokyo Tyrant 加上 Tokyo Cabinet,他们支持双向的M/M同步,也支持单向的M/S同步,可以为网站提供非常可靠的持久化的分布式数据高速Cache,没有了Memcached对内存大小的依赖,而且速度还是飞快.计算一下,按100w每秒的速度,那么每天可以支持最高100w*1440*60 = 8640000w的查询总量.这样的速度对于任何一个网站都是足够用的了.