1. Column Families
列族（Column Families）是rocksdb3.0提出的一个机制，用于对同一个数据库的记录（键值对）进行逻辑划分。默认情况下所有的记录都会存储在一个默认列族里：
ROCKSDB_NAMESPACE::kDefaultColumnFamilyName
列族具有的属性
1）可以跨列族进行原子写，弥补了rocksdb在单个进程内只能操作一个数据库的问题。
2）在不同的列族，提供数据库的一致性视图。
3）可以对列族进行独立配置。
4）动态添加和drop列族。
1）列族的配置
ColumnFamilyOptions用于配置列族；
DBOptions用于数据库粒度的配置；
Options继承了ColumnFamilyOptions, DBOptions，因此Options可以执行上述两种配置。
2）主要操作
每个列族通过句柄类ColumnFamilyHandle进行操作，包括列族的创建和销毁都要使用ColumnFamilyHandle完成。
创建列族，下列代码就创建了一个名为"new_cf"的列族：
ColumnFamilyHandle *handl;
db->CreateColumnFamily(ColumnFamilyOptions(), "new_cf", &handl);
db->DestroyColumnFamilyHandle(handl);
使用列族，基于列族打开数据库，和常规的方式不同。具体来说，如果我们以读写模式打开数据库，则必须要给open传入所有的列族，否则open方法会返回Status::InvalidArgument()。
每个列族通过ColumnFamilyDescriptor表示，这个类包含了{列族名，ColumnFamilyOptions}。
下列代码通过读写模式打开了一个包含所有列族的数据库：
vector<ColumnFamilyDescriptor> colume_families;
colume_families.push_back(ColumnFamilyDescriptor(ROCKSDB_NAMESPACE::kDefaultColumnFamilyName, ColumnFamilyOptions()));
colume_families.push_back(ColumnFamilyDescriptor("new_cf"), ColumnFamilyOptions())
vector<ColumnFamilyHandle *> cf_handles;
Status s = db->open(DBOptions(), DB_PATH, colume_families, &cf_handles, &db);
如果使用只读模式打开数据库，那么可以只传入我们需要读取的列族，不过默认的列族是必须要传入给open函数的
// open db read only
column_families.push_back(ColumnFamilyDescriptor("new_cf", ColumnFamilyOptions()));
column_families.push_back(ColumnFamilyDescriptor(kDefaultColumnFamilyName, ColumnFamilyOptions()));
s = DB::OpenForReadOnly(DBOptions(), kDBPath, column_families, &handles, &db);
assert(s.ok());
s = db->Get(ReadOptions(), handles[0], Slice("key2"), &value1);
assert(s.ok());
3) WriteBatch
通过WriteBatch我们可以原子的操作不同的列族，例如可以通过handles[0]去删除handles[1]插入的键值对{"key": "value"}
// put and get from non-default column family
s = db->Put(WriteOptions(), handles[1], Slice("key"), Slice("value"));
assert(s.ok());
std::string value;
s = db->Get(ReadOptions(), handles[1], Slice("key"), &value);
assert(s.ok());
// atomic write
WriteBatch batch;
batch.Put(handles[0], Slice("key2"), Slice("value2"));
batch.Put(handles[1], Slice("key3"), Slice("value3"));
batch.Delete(handles[0], Slice("key"));
s = db->Write(WriteOptions(), &batch);
assert(s.ok());
4) 原理和实现
简单的说，不同的列族是共享WAL的，但是memtable和SST file是隔离的。
2. LSM Tree
rocksdb基本可以认为就是对LSM Tree的实现，因此LSM Tree对于rocksdb是非常重要的。
LSM Tree的设计可以参考论文：
1996, The Log-Structured Merge-Tree (LSM-Tree)
2014, A Comparison of Fractal Trees to Log-Structured Merge (LSM) Trees
2017, WiscKey: Separating Keys from Values in SSD-conscious Storage, TOS
2019, LSM-based Storage Techniques: A Survey
in-place/out-of-place
数据的存储方式，可以分为两种：in-place update和out-of-place update，LSM Tree是out-of-place update的方式，而in-place update的典型代表是B+树。
in-place update的方式，进行数据的写入/修改/删除操作时，是会对硬盘上的已有数据进行修改的，例如写入新数据时，为了维护B+树的结构，可能需要进行节点的分裂，另外，为了维护B+树的结构，写入的数据可能分布在不同的位置，会有比较多的随机io。
out-of-place update的意思，就是说进行数据的写入/修改/删除操作时，并不对硬盘上的已有数据进行修改，而是先在内存中进行记录(写入/修改就记录数据内容，删除就记录需要删除的key)，在达到一定的数据量后，生成一个新的文件，所以硬盘中可能同时存在新的和旧的数据(一般kv存储要求key是唯一的，新写入key0 value1后，旧的key0 value0应当失效，删除掉旧的数据，或者使其无法被读取出来)。为了避免占用的硬盘空间不停上升，以及存在重复数据导致的搜索效率下降，需要定期/不定期的处理重复数据，LSM Tree的处理方法是执行compaction，即选择一些文件进行合并，删除重复的数据后，生成新的不包含重复内容的文件。由于写入和compaction时，写入的都是完整的文件，所以随机io很少，都HDD和SSD来说是比较友好的。但是由于存在compaction操作，一个数据可能被重复读写多次，所以会造成执行io的数据量比实际写入的数据量要大几倍甚至几十倍，也就是写放大问题。
compaction
compaction是LSM Tree进行数据维护的核心工作，compaction的执行主要分为两种策略：Leveling Merge Policy和Tiering Merge Policy。
参考链接：https://blog.csdn.net/xuhaitao2
