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

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

开发语言：Java

授权协议：ApacheLicense2.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的平台架构部门领导EvanWeaver写了一篇文章介绍Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常详细的介绍。Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

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

•使用TokyoCabinet當底層，這是目前最快的key-valuedatabase之一，而且檔案也小。

•因為使用TokyoCabinet，所以可以用他的master-masterreplication取代Dynamo內的replication，也就是固定以n=2解決問題，以node本身的HA架構解決Dynamo裡面的consistent問題。(在Dynamo裡透過很多方法解決，變成eventallyconsistent)

•增加機器造成資料需要移動的問題是把hashring拆成兩個，一個lookupring，另外一個storagering，用兩次query解決。這個部份我看不懂他的解法，還要再找資料看他怎麼解的。

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

开发语言：C/C++PythonLua

操作系统：Linux

项目主页：http://opensource.plurk.com/LightCloud/

http://www.162cm.com/archives/681.htmlTokyoCabinet的作者叫MikioHirabayashi.用师兄覃健祥的话说，作者很猛很持久.这不，作者出了一个QDBM(类似gdbm,ndbm,sdbm,mdbm的一个dbm),estraier,Hyperestraier（前面介绍过，是一个支持中文等东亚文字，可以p2p架构的搜索引擎实现）等一系列c软件，现在又出了一个:TokyoCabinet.

TokyoCabinet项目主页:http://tokyocabinet.sourceforge.net/

简介（翻译成中文了)

TokyoCabinet是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM等等是相同的，但是比它们的性能要好得多（因此可以替代它们)。当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。

Asfordatabaseoffixed-lengtharray,recordsarestoredwithuniquenaturalnumbers.Itisimpossibletostoretwoormorerecordswithakeyoverlaps.Moreover,thelengthofeachrecordislimitedbythespecifiedlength.Providedoperationsarethesameasonesofhashdatabase.

对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限制。读取方法和hash表的一样。TokyoCabinet是用C写的，同时提供c,perl,ruby,java的API。TokyoCabinet在提供了POSIX和C99的平台上都可用，它以GNULesserPublicLicense协议发布。

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

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

这个奇怪的标题加无聊的比喻来自与对“TheDinosaurWingoftheDBMForks”的直译，这是TokyoCabinet的作者MikioHirabayashi对自己的作品的宣传语。

DBM这个缩写对于非*NIX血统出生的程序员来说的确有些陌生，DBM是databasemanager的简写，部分网站翻译为资料管理系统。在*NIX系统中，似乎已是古老经典的一种key-value存储系统了。

这里有一些经典的DBM系统的介绍：《GDBM/NDBM使用介紹》http://blog.chinaunix.net/u/9861/showart_637998.html

此外，开源数据库界出名的BerkeleyDB其实也是DBM系统的一种：http://baike.baidu.com/view/1281930.htm

与TokyoCabinet的功能一模一样的MemcachedDb的持久化存储引擎就是用的BerkeleyDB。

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

TokyoCabinetisdevelopedasthesuccessorofGDBMandQDBMonthefollowingpurposes.TheyareachievedandTokyoCabinetreplacesconventionalDBMproducts.

•improvesspaceefficiency:smallersizeofdatabasefile.

•improvestimeefficiency:fasterprocessingspeed.

•improvesparallelism:higherperformanceinmulti-threadenvironment.

•improvesusability:simplifiedAPI.

•improvesrobustness:databasefileisnotcorruptedevenundercatastrophicsituation.

•supports64-bitarchitecture:enormousmemoryspaceanddatabasefileareavailable.

AswithQDBM,thefollowingthreerestrictionsoftraditionalDBM:aprocesscanhandleonlyonedatabase,thesizeofakeyandavalueisbounded,adatabasefileissparse,arecleared.Moreover,thefollowingthreerestrictionsofQDBM:thesizeofadatabasefileislimitedto2GB,environmentswithdifferentbyteorderscannotshareadatabasefile,onlyonethreadcansearchadatabaseatthesametime,arecleared.

TokyoCabinetrunsveryfast.Forexample,elapsedtimetostore1millionrecordsis0.7secondsforhashdatabase,and1.6secondsforB+treedatabase.Moreover,thesizeofdatabaseofTokyoCabinetisverysmall.Forexample,overheadforarecordis16bytesforhashdatabase,and5bytesforB+treedatabase.Furthermore,scalabilityofTokyoCabinetisgreat.Thedatabasesizecanbeupto8EB(9.22e18bytes).

TokyoCabinet仅仅只是一个DBM系统吗？不尽然，从TokyoCabinet支持的数据引擎来看，功能还更加丰富。TokyoCabinet的数据引擎提供的API有：

·theon-memoryhashdatabaseAPI

·theon-memorytreedatabaseAPI

·thehashAPI

·theB+treedatabaseAPI

·thefixed-lengthdatabaseAPI

·thetabledatabaseAPI

假如去掉持久化存储，只使用on-memoryhash和on-memorytree两种引擎，则TokyoCabinet的功能与Memcached一致。希望能有高手做一个对比测试，看看不要持久化的TokyoCabinet与Memcached在set/get性能，内存占用，并发处理三个方面的性能有何差别。当然，TokyoCabinet与Memcached的有些功能是有差别的：

·Memcached里，每个key都有过期时间，而TokyoCabinet没有这个功能；

·Memcached里，内存空间满后，插入会失败，而TokyoCabinet在内存满后会丢弃旧的记录；（这个需验证，根据文档得出这个结论，还没实验）

·Memcached里，PHP的Memcached客户端实现了对value的gzip压缩，Memcached服务器端是不支持GZIP压缩的；而TokyoCabinet中，支持多种压缩方式，但是究竟是服务器端实现了压缩，还是客户端实现了压缩，还不得而知；（如果服务端实现了压缩解压缩，则对带宽无法降低）

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

其实，在WEB2.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、updatelog日志的导入导出：有这样的功能。

有了以上功能，对于数据的可靠性也有了一定保证，又安全又快速，很值得使用！！！

http://hi.baidu.com/llaa27/blog/item/df7e3e8f710a7ee9f11f3663.htmlTokyoCabinet是日本人MikioHirabayashi开发的一款DBM数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是BerkeleyDB等DBM的几倍。TokyoCabinet是一个DBM的实现【虎.无名：是Mikio另一个产品QDBM的继承者】。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM等等是相同的，但是比它们的性能要好得多（因此可以替代它们)。当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。

Asfordatabaseoffixed-lengtharray,recordsarestoredwithuniquenaturalnumbers.Itisimpossibletostoretwoormorerecordswithakeyoverlaps.Moreover,thelengthofeachrecordislimitedbythespecifiedlength.Providedoperationsarethesameasonesofhashdatabase.

对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限制。读取方法和hash表的一样。TokyoCabinet是用C写的，同时提供c,perl,ruby,java的API。TokyoCabinet在提供了POSIX和C99的平台上都可用，它以GNULesserPublicLicense协议发布。

TokyoTyrant是由同一作者开发的TokyoCabinet数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。TokyoTyrant加上TokyoCabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将TokyoTyrant看成是一个Memcached，但是，它的数据是可以持久存储的。

上面是我从网上摘录的部分介绍~~

用TokyoTyrant加上TokyoCabinet,他们支持双向的M/M同步,也支持单向的M/S同步,可以为网站提供非常可靠的持久化的分布式数据高速Cache,没有了Memcached对内存大小的依赖,而且速度还是飞快.计算一下,按100w每秒的速度,那么每天可以支持最高100w*1440*60=8640000w的查询总量.这样的速度对于任何一个网站都是足够用的了