2010-12-29 16:57:38 
阿炯
eansDB 是一个主要针对大数据量、高可用性的分布式K/V存储系统，采用HashTree和简化的版本号来快速同步保证最终一致性，一个简化版的 Dynamo。
它采用类似memcached的去中心化结构，在客户端实现数据路由。目前只提供了 Python版本的客户端，其它语言的客户端可以由memcached的客户端稍加改造得到。
主要特性
高可用：通过多个可读写的用于备份实现高可用；
最终一致性：通过哈希树实现快速完整数据同步(短时间内数据可能不一致)；
容易扩展：可以在不中断服务的情况下进行容量扩展；
高性能：异步IO和高性能的KeyValue数据TokyoCabinet：
可配置的可用性和一致性：通过N，W，R进行配置；
简单协议：Memcache兼容协议，大量可用客户端。
最新版本：0.5
完全放弃了ToykoCabinet 作为存储引擎，它在数据的可靠性、一致性以及大数据量下的性能有不少问题，已经不能满足 beansdb 对数据存储的需求。于是重新实现了一种基于日志结构的存储引擎 Bitcask，借鉴自 Riak 项目的一份设计文档: http://downloads.basho.com/papers/bitcask-intro.pdf
Bitcask 有以下优点：读写低时延，高写入吞吐量，能处理大规模数据集而性能不会显著下降，数据持久化更好，不用担心crash会导致数据丢失，通过简单的rsync就能在线备份数据，还能恢复被错误覆盖的数据.算法简单，代码容易维护和调优，在大数据量和高负载下的性能容易估计。
Bitcask 也有缺点，它要求所有key信息全部放入内存，在启动时一次性载入. 这对内存索引的效率提出了非常高的要求。beansdb中改进的HashTree有更好的空间效率，它根据key的特点进行了重新编码，大大降低了空间消耗，每条记录平均只需20字节，其中包括key、版本、hash、位置等信息，这样一台8G内存的服务器可以存储 4亿条记录；如果记录平均大小为1k的文本，则能存 400G，如果是平均大小为100k的图片，则能存40T。
启动时间也是Bitcask算法的缺点，目前在一分钟大概能载入5千万条记录的索引，还有进一步优化的空间.如果是意外crash后的重启，时间会稍微长一点，视数据量的大小而定，一般也不会超过10分钟。
日志结构存储的另一个问题是会有空洞，beansdb 支持外部控制的在线垃圾回收过程，可以安排在夜里进行，通常在硬盘不是太紧张的情况下，几个月进行一次垃圾回收就可以了。
之前网络层采用的是memcached的代码，它使用libevent，每个连接是跟固定的线程绑定的，在存储引擎中使用这种线程模型容易发生阻塞，磁盘IO操作阻塞当前线程进而阻塞了其它连接的网络IO，因而直接基于epoll/kqueue 实现 leader/follower 模式的线程池，响应时间会更好，尤其是在并发访问比较高的时候。
为了简化维护，在部署beansdb时增加了一层 proxy，它是用 go 实现的，会根据后端存储节点的数据情况自动做数据路由和负载均衡.proxy 时无状态的，可以部署多台开实现扩容和HA，添加新节点时只要改一下proxy的配置，而数据迁移时无需更改任何配置。
项目主页：http://code.google.com/p/beansdb/