当写下这个题目的时候，很多人会说，哎，又来key-val数据库了，市面上的key-value存储这么多了，为啥还要自己去实现一个？其实最初我也是这样想的，新浪以前不是开发过一个memcachedb么，所有产品线都用就行了呗。后来才弄清楚，原来这个世界上，到目前为止没有像mysql一样的关系数据库垄断key-val数据库是有很多原因的。

先说几个大家熟悉的key-value 解决方案吧，好对比我们的方案。

memcached

memcached不用说了吧，就是传说中的万金油，哪儿痒了点哪里，只要是一个中型网站以上，一般都有memcached的存在。它的好处呢，我觉得太多了，多到没有你不用的理由的地步。在内存这么便宜的年代，memcached 依旧是缓存的最好的解决方案。

但是，它是个cache缓存，也就是不能持久化，当然就不能算作数据库了。但是memcached的作者从来都没有计划把它开发成一个DB，因为cache就是cache嘛，做好这件事情就行了，国外的大神们做的产品，就是专注，不想国内的很多产品经理，一个产品做出来，完全是为了把页面占满。

当然，也有人做了memcached的持久化，这句话有点错，应该是“用memcached的协议，对传入的数据做了持久化”，比如我浪08年开发的memcachedb (更多…)

如果你知道 Tokyo Cabinet ，那么就应该知道 Kyoto Cabinet，因为他们都是同一个作者（平林幹雄）开发出来的 Key-Value 数据库。

Kyoto Cabinet：a straightforward implementation of DBM，主页：http://fallabs.com/kyotocabinet/ ，演示文稿：http://www.slideshare.net/estraier/kyotoproducts-5886452 。

Tokyo Cabinet：a modern implementation of DBM，主页： http://fallabs.com/tokyocabinet/

以下Tokyo Cabinet简称为TC， Kyoto Cabinet简称为KC，本文主要对KC做介绍。
KC是TC的后继者或兄弟项目，因为KC在各方面都超过了，所以作者在TC的首页上的开头向所有人推荐使用KC（我也是这个推荐才开始关注KC的）。TC为C实现，为了更好的可维护性，KC采用C++实现。

以下内容的英文原文来自：http://fallabs.com/kyotocabinet/spex.html (更多…)