冥冥之中，打仗到了差异于干系数据库的NoSQL Key-Value存储引擎RocksDB，懵懵懂懂、布满好奇，google一点，满眼皆是LSM-Tree，头晕目眩、若即若离，便有了这篇文章，一起与各人分享这趟探险之旅。

LSM-Tree(Log-Structured-Merge-Tree)

LSM从定名上看，容易望文生义成一个详细的数据布局，一个tree。但LSM并不是一个详细的数据布局，也不是一个tree。LSM是一个数据布局的观念，是一个数据布局的设计思想。实际上，要是给LSM的定名断句，Log和Structured这两个词是归并在一起的，LSM-Tree应该断句成Log-Structured、Merge、Tree三个词汇，这三个词汇别离对应以下三点LSM的要害性质：

很明明，LSM牺牲了一部门读的机能和增加了归并的开销，调换了高效的写机能。那LSM为什么要这么做？实际上，这就干系到对付磁盘写已经没有什么优化手段了，而对付磁盘读，岂论硬件照旧软件上都有优化的空间。通过多种优化后，读机能固然仍是下降，但可以节制在可接管范畴内。实际上，用于磁盘上的数据布局差异于用于内存上的数据布局，用于内存上的数据布局机能的瓶颈就在搜索巨大度，而用于磁盘上的数据布局机能的瓶颈在磁盘IO，甚至是磁盘IO的模式。

LSM连年来已被遍及利用起来，尚有将B家属树和LSM团结起来利用的，像HBase、SQLite4、MongoDB、Cassandra、LevelDB，尚有接下来的主角RocksDB，这些当家数据存储花旦，都或多或少支持、利用起LSM了。

RocksDB

RocksDB是Facebook在LevelDB基本上用C++写的Key-Value存储引擎。其Key和Value都是二进制流。并对闪存(flash)有更友好的优化。先来聊一聊RocksDB的整体布局，然后再聊一聊RocksDB中的一些有意思的抽象，最后聊一聊RocksDB内存上、磁盘上的详细布局。在RocksDB中，将内存布局中的数据写入磁盘布局叫做flush，而差异file、level之间merge叫做compaction。

Architecture

RocksDB如上文所说是基于LSM做存储。RocksDB在内存中的布局叫做memtable，用于形成Log-Structured的file叫做logfile，磁盘上的file布局叫做sstfile，用于记录对file变动的log叫做manifest。

Column-Family

为存储的数据逻辑分族，将差异family相互断绝，分隔设置、存储。column family共享logfile，而不共享memtable和sstfile，这使得column family有以下两点特点：

Filter

RocksDB有一些奇思妙想的filter，这些filter按照特定条件生成，通过数据的key就可以判定数据是否确定或大概被特定条件解除去。有些filter可以用来对读优化，有些也可以用来打点数据的生命周期等。

Bloom-Filter

bloom filter就是一个能提高读机能的filter。通过算法可以生成一个key set对应的bloom filter。这个bloom filter可以判定出任意key大概存在可能必定不存在key set中。每个sstfile在生成的时候，城市建设一个或多个对应的bloom filter，当在读数据的时候，可以快速判定出数据是否大概在sstfile中。在做range scan和prefix查找的时候，bloom filter也能帮上忙。

Time-To-Live(TTL)