如下内容是Sanjay发表在Google Groups leveldb 上的初始设计方案。实际实现可能与此不同。对于bloom filter的支持是在最新的1.4版本中加入的，在此之前的版本中并无此支持。
人们希望可以在LevelDB中加入bloom filter的支持。目前针对一次查询，LevelDB可能需要在每个level上进行一次磁盘随机访问。通过使用bloom filter可以大大减少所需要的随机访问操作次数。比如，假设调用者正在查找一个值为”Foo”的key，LevelDB会从每个level下选择相应的SSTable文件(那些range包含了该key的文件)，之后会在这些SSTable文件上进行随机读。如果每个SSTable都有一个对应的bloom filter，那么查找时就可以很容易地通过检查bloom filter跳过那些不包含该key的SSTable文件。
说明：转载请保留全部信息
作者：Patrick O’Neil &Edward Cheng etc. 1996
原文：http://www.springerlink.com/content/rfkpd5yej9v5chrp/
译者：phylips@bmy 2011-12-25
译文：http://duanple.blog.163.com/blog/static/7097176720120391321283/
【随着NoSql系统尤其是类BigTable系统的流行，LSM-Tree这个名词也开始变得不再陌生。相信大多数了解NoSql系统的人，基本上都会听到过LSM-Tree这个名词，但是读过其原始论文的人估计就不是很多了。在我看来，LSM-Tree之于BigTable的重要性就像一致性hash之于Dynamo。溯本求源一向是本人的追求，希望可以从最初的文字中找到蕴含在结构之下的更多思考。老实说，这篇论文也算是很长的了，原文共30页，涉及了不少公式，因此翻起来也不会那么简单。
作者：Jeff Dean, Sanjay Ghemawat
原文：http://leveldb.googlecode.com/svn/trunk/doc/index.html
译者：phylips@bmy 2011-8-16
译文：http://duanple.blog.163.com/blog/static/70971767201171705113636/
LevelDB库提供了一种永久性的key value存储。Key和value都是任意的字节序列。在这个key value存储系统中，key按照用户声明的比较函数有序排列。