分布式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的查询总量.这样的速度对于任何一个网站都是足够用的了
