ToplingDB 分布式 Compact 与 BlockBasedTable

1. 背景
   ToplingDB 是 topling 开发的 KV 存储引擎，fork 自 RocksDB，进行了很多改造，其中最重要的部件是 ToplingZipTable, 是 BlockBasedTable 的代替品，性能更高而内存占用更低。

一直以来，RocksDB 的 Compact 经常成为系统瓶颈，ToplingDB 就通过分布式 Compact 来解决这个问题，把 Compact 转移到专用的计算集群。于是 ToplingZipTable + 分布式 Compact 就成为一对黄金组合。

然而理论与实践总是存在距离，在实践中，RocksDB 原装的 BlockBasedTable 更加深入人心，于是我们决定推出 BlockBasedTable + 分布式 Compact 作为一个替代方案。

2. 意料之外的问题
   原本 TableFactory 和 分布式 Compact 是完全正交的功能，不管使用 ToplingZipTable 还是 BlockBasedTable，分布式 Compact 是完全无感知的。

按照预期，虽然一直以来我们使用的是 ToplingZipTable + 分布式 Compact，但是要把 ToplingZipTable 换成 BlockBasedTable，只需要修改一下 json 配置，其它都应该一切如常。

但是，现实就是偏偏跟我们作对，只要开启分布式 Compact，BlockBasedTable 就会报错，要么是 checksum 错误，要么就是 key range overlapping ……

这个问题困扰了我们很久，以至于我不得不先放下这个问题，有其它更多的事情等着我们去做……

3. 峰回路转
   虽然暂时放下了，但这个问题就如芒刺在背，让人不得片刻安宁，就在我茫然不知所措之际，有天晚上迷迷糊糊半睡半醒之间，想到了 TableProperties 有个成员 orig_file_number，表示创建 SST 时分配的原始 file_number，使用分布式 Compact 时，orig_file_number 虽然也填入了一个合理值，但在分布式 Compact 结束之后，将 SST 安装进 LSM 时，又重新分配了一个新的 file_number，这个行为和本机 Compact 是不同的。

grep 一下 orig_file_number，立马就有了结果：在 BlockBasedTable::SetupBaseCacheKey， orig_file_number 被 BlockCache 中 Lookup Key 作为用来区分不同 SST 的标志。

4. RocksDB 为什么要这样干
   RocksDB 记录在 LSM 中的 SST 的 file_number 在某些情况下会改变，但是 SST 文件本身又没有改变，如果使用改变后的 file_number，那么原先已经存在于 BlockCache 中的数据就找不到了！

要解决这个问题，就只能使用一个“稳定”的可以标识 SST 的 Key，所以 orig_file_number 就成为一个合理的选择！

在 ToplingDB 分布式 Compact 中，不同的 Compact 任务可能会产生相同的 orig_file_number，于是，BlockCache 中的内容就乱了……

ToplingZipTable 没有 BlockCache，自然不会有这个问题。

5. 总结
   这个问题解决起来是非常简单的。它充分地展示了 RocksDB 演化过程中“头痛医头，脚痛医脚”的现象，告诉我们违反软件工程基本原则会导致的严重后果。