共计 1314 个字符，预计需要花费 4 分钟才能阅读完成。
（一）背景
ToplingDB 是 topling 开发的 KV 存储引擎，fork 自 RocksDB，进行了很多革新，其中一个最重要的性能是分布式 Compact，将 Compact 从 DB 结点转移到由多个 DB 共享的计算集群中执行，实现了降本增效的目标。系列文章：
MyTopling 分布式 Compact（一）：从多线程到多过程
MyTopling 分布式 Compact（二）：CompactionFilter
MyTopling 分布式 Compact（三）：PropertiesCollector
（二）多过程
善战者无赫赫之功，只有选对了方向，前面的事件就自然而然地瓜熟蒂落，兵不血刃。
在 分布式 Compact（一）中，咱们将 Compact 服务实现为多过程，为了配合 Compact 服务的多过程架构，咱们把 ToplingZipTable 的压缩 Pipeline 也拆分成独立的过程。
（三）Compact 中反查 DB
在一些利用中（例如 pika、kvrocks 等等），CompactionFilter 须要反查 DB(应用 DB::Get) 获取元数据，而在 Compact 服务中，只有 SST，没有 DB 对象，这就使得 CompactionFilter 无奈在 Compact 服务中工作。
在 Todis 中，咱们通过当时把 CompactionFilter 反查会用到的元数据捞进去，而后在 Compact 服务中拜访，代替本来的 DB::Get，为此咱们还对 Todis 的数据进行了针对性的编码。
在 kvrocks 中，因为数据的组织形式，无奈通过编码在 Compact 服务中无效地代替本来的 DB::Get，所以，只有 metadata 能力反对分布式 Compact。
kvrocks 中各种数据类型的 metadata 保留在一起，如果照搬 todis 的计划，当时捞数据，捞到的元数据很可能 99.9% 都是无用的元数据，例如 compact hash 数据时，当时捞进去的元数据可能大都是 string 数据。
（四）ToplingZipTable 独立的压缩过程
既然 ToplingZipTable 的压缩 Pipeline 曾经拆分成独立的过程，那么，咱们就能够充分利用这一点：
生成 ToplingZipTable 须要两遍扫描
在第一遍扫描中收集各种统计信息，并且把（解压后的）数据保留到了临时文件中
在第二遍扫描中读取临时文件，压缩数据，生成 ToplingZipTable 的 SST，这一步占了绝大多数的 CPU 耗费
本来这些都是在同一台 Compact 服务器上运行的，如果：
在 DB 服务器上运行第一遍扫描：能够在 CompactionFilter 中执行 DB::Get
在 Compact 服务器上运行第二遍扫描：承接最耗费 CPU 的计算
这个计划的确能以最优雅的形式解决问题，然而相比齐全的分布式 Compact 也有毛病：
第一遍扫描依然要耗费 DB 结点的 CPU
通过网络传输的数据是解压后的数据，要耗费更多的网络带宽
（五）结语
李靖毁灭突厥，仅用数千人的军队，3 个月就完事，每一件事件，如同都是那么自然而然地就产生了，而后就胜利了。
将 Compact 服务革新成多过程的时候，咱们也并没有想着未来要把第一遍和第二遍扫描拆散到不同的机器上，而起初事件就自然而然地产生了……
【完】
