漫谈RocksDB(二)基础讲解——仿佛兮若轻云之蔽月，飘飘兮若流风之回雪

前言

古话说得好：“工欲善其事必先利其器”，要做好一件事情之前先把工具或者武器强化一下还是很值当的。所以本文将会把RocksDB的主要概念向大家讲解一下，方便后面具体内容的展开。本文所提到的概念大家仅需要了解和留个印象，如果不是很理解的话不需要纠结，后续的章节中会详细展开。

正文

RocksDB的概念纷繁复杂，我根据自己的理解将概念分为架构概念、存储概念以及操作概念，分门别类，帮助大家理解。下面就按照这个观其貌、识其物、辩其行的顺序进行讲解。

架构概念

嵌入式数据库

首先RocksDB是一个嵌入式数据库，这个根本特征决定了RocksDB不需要单独部署，也不需要单独的进程，随应用程序一起部署即可，节省资源且便于管理。

另外由于RocksDB未实现真正意义上的分布式（虽然底层可以使用HDFS目录进行存储，但是数据未作分片，所以无法实现真正的分布式），准确来说是一个单机的KV数据库。

但是没有分布式的血统不代表没有一颗成为分布式应用的心。在实际的分布式使用场景中以RocksDB作为某个副本的存储介质，上层通过Paxos或者Raft协议来保证副本之间的数据一致性，完美的明确了RocksDB在分布式应用使用场景中的定位与作用。

LSM

这是RocksDB的LSM树模型，具体的LSM树相关的概念和知识请参考之前的博文俗话说别在一棵树上吊死，那为什么那么多NOSQL都喜欢在LSM树上吊死呢？

 根据这个模型,数据的写入流程为：

• 任何的写入都会先写到 WAL，然后在写入 Memory Table(Memtable)。当然为了性能，也可以不写入 WAL，但这样就可能面临崩溃丢失数据的风险。Memory Table 通常是一个能支持并发写入的 skiplist，但 RocksDB 同样也支持多种不同的 Memory Table，下面在Memory Table章节详细讲解，用户可以根据实际的业务场景进行选择，如果没有特殊需求，默认即可。

• 当一个 Memory Table 写满了之后，就会变成 immutable 的 Memory Table，RocksDB 在后台会通过一个 flush 线程根据条件从flush queue中按顺序将 Memory Table flush 到磁盘，生成一个 Sorted String Table(SST) 文件，放在 Level 0 层。当 Level 0 层的 SST 文件个数超过阈值之后，就会通过 Compaction 策略将其放到 Level 1 层，以此类推，直到最底层

Column Family

这是从HBase老师那里学来的，HBase老师就有Column Family的概念，严格上来说HBase是宽列式数据库，列族级别是列式存储，列族内部是行式存储。

由于RocksDB是KV数据库，没有schema的概念，所有数据都是二进制，采用列式存储。不同的Column Family共享WAL，独享sst和memtable，所以Column Family起到了一定的逻辑和资源隔离的作用。

RocksDB的每个键值对都与唯一一个列族（column family）结合。如果没有指定Column Family，键值对将会结合到“default” 列族。

通过共享WAL文件，RocksDB实现了原子写。通过隔离memtable和table文件，RocksDB可以独立配置每个列族并且快速删除它们。

TransactionDB/OptimisticTransactionDB