简单看了一下，不一定准确
每次写入先写WAL，再写入memtable，保证failure后用WAL恢复memtable；当memtable刷到disk后，对应log废弃，过一段时间后删除
LevelDB删除操作也是插入，只是标记Key为删除状态，真正的删除要到Compaction的时候才去做真正的操作；
LevelDB没有更新接口，如果需要更新某个Key的值，只需要插入一条新记录即可；
Memtable达write_buffer_size之后，改成immutable memtable（只读），然后等待flush到磁盘SST文件中，此时也会生成新的memtable供写入新数据；memtable和sst文件中的key都是有序的，log文件的key是无序的
每个column family只有一个memtable，和多个immutable，总memtable size(所有family的)超过db_write_buffer_size；write_buffer_manager发信号说flush； WAL file超过max_total_wal_size时，把最old的memtable flush到disk；某个family的immutable数大于min_write_buffer_number_to_merge的flush immutable到disk
再flush时会去除重复的KV
memtable和Level0有重复（Level0两个sst文件之间有重复，文件内有序，没重复），level N（N>0）文件之间也没有重复，每个sst文件key有序，有个范围，不与同层任何sst文件key范围重叠，在压缩时，轮流选取level N每个sst文件，与N+1层所有key范围有重叠的文件合并（0->1层时选0层某个文件与下层合并时，会把0层其他范围重叠的也一起合并）
Compaction：
每次会挑选compaction score最高的一个level，并在这个level中找到一个文件大小最大，并且上一个level的相交文件没有在compaction的一个文件
通用压缩（Universal Style Compaction ）存储 L0 中的所有文件，所有文件按时间顺序排列。压缩拾取一些在时间上彼此相邻的文件，并将它们合并回新的文件存回 L0。所有文件可以具有重叠的 key。
选择哪一层进行压缩时根据得分：该层size/限定的目标size
层内选文件：最老最小，最老最大？多种，根据优化目标不同【http://rocksdb.org/blog/2016/01/29/compaction_pri.html】
RocksDB 支持 snappy，zlib，bzip2，lz4 和 lz4_hc 压缩。RocksDB 可以配置为在不同级别的数据上支持不同的压缩算法。通常 90% 的数据在 Lmax 级别。
Memtable：解决写放大，memtable越大写放大越小，但会减慢读
用户调用get(key)时，有许多文件可能包含这个key，可能是level0的所有文件以及0以上每层一个文件；在读文件前，先用bloom filter选出可能包含key的file；减少磁盘读取文件数
min_write_buffer_number_to_merge：多少个immutable一起合并，多个合并时，同key的几个update会合并，但get()要检查所有immutable确定是否有该key，所以越大读会慢，但越小写storage越多；
cache：LRU CLOCK
block cache，从磁盘中读取的数据放入block cache
table cache中缓存index和filter block；max_open_files存储上限，-1表示全部存储在内存中
cache_index_and_filter_blocks若设置为true，则存储在block cache中
Simulated cache：模拟shadowcache 模拟更大的cache，测hit/miss看效果；相当于只有key的block_cache； insert时，key进block cache和simulated cache；value只进block cache
(it wraps around real cache object that theDB is using【所以若一个family一个object，也可以一个family一个simulated cache】)
Include\rocksdb\Options.h配置各个family
struct ColumnFamilyOptions : publicAdvancedColumnFamilyOptions {
在Table Cache中，key值是SSTable的文件名称，Value部分包含两部分，一个是指向磁盘打开的SSTable文件的文件指针，这是为了方便读取内容；另外一个是指向内存中这个SSTable文件对应的Table结构指针，table结构在内存中，保存了SSTable的index内容以及用来指示block cache用的cache_id ,当然除此外还有其它一些内容。
每个SST文件一个bloom filter；指示这个sst文件是否包含找的key；bloomfilter不会合并，sst文件合并后重新建立新的bloom filter文件。
参考文章：
github官方文档
http://www.vccoo.com/v/12lpxk
http://blog.csdn.net/u012658346/article/details/45486051
http://blog.sina.com.cn/s/blog_5eb8ebcb0102wpm3.html
http://www.jianshu.com/p/75b93a664ebe