共计 1500 个字符，预计需要花费 4 分钟才能阅读完成。
- 背景 ToplingDB，尽管 fork 自 RocksDB 并且兼容其 API，但实现了本性难移的改良，最重要的就是实现了性能更高的 CSPP MemTable(Rep) 和 SST。ToplingDB CSPP MemTable 设计精要 对 CSPP MemTable 进行了初步介绍。对于共享内存 shm 和内存映射 mmap 的区别是什么？介绍了 CSPP 间接将 MemTable 转化为 SST。2. 减小写放大实际上，间接把 MemTable 转化为 SST，除了间接地缩小 CPU/ 内存 /IO 耗费，还能够带来进一步的收益：减小写放大。LSM 的数据分为多层，通常状况下，每层数据规模是上一层的 10 倍（可配置），Level Compaction 对相邻两层 key 重叠的文件进行合并，由此带来写放大。对于齐全随机的输出，在零碎进入稳固状态时，每层引入的写放大是 10，事实中的理论数据有肯定法则，写放大远小于齐全随机的数据，例如在 TPCC 测试中，通过 ToplingDB 的 WebView 能够看到：
这里写放大远小于随机数据在每层中引入的写放大（10），写放大的计算公式继承原版 RocksDB。咱们将 MemTable 尺寸设为 1G，max_bytes_for_level_base 也设为 1G，开启 convert_to_sst 时，L0 的写放大实际上是 0（图中显示的是 1.0）。与此同时，因为 max_bytes_for_level_base 比拟大（默认是 256M），所以咱们的 L1 尺寸实际上近似于 RocksDB 的 L2，由此，咱们相当于打消了原版 L1->L2 的所有 Compact，假设原版 L1->L2 compact 写放大也是 3.7，咱们这里相当于将总的写放大减小了 3.7。再算上 L0 的理论写放大从 1.0 减到了 0，咱们将总的写放大减小了 4.7！3. 为什么 ToplingDB 能够这样做 MemTable 转化成 SST 能够霎时实现，max_write_buffer_number=2 就足以撑持最大的写压力。CSPP MemTable 的内存是 File Mmap，从而，这些内存能够 swap 进来，特地是当存在不沉闷的 SuperVersion 导致老旧 MemTable 无奈开释时（没有拜访，但也无奈开释），malloc 的内存个别很少被 swap，就要始终占用物理内存。
所以，同样是 5 个（或者 10 个，20 个）MemTable 无奈开释，ToplingDB 只有沉闷的 MemTable 占用物理内存，而 rocksdb 的所有 MemTable 都要占用物理内存。其次，从 MemTable 转化来的 SST，和 MemTable 共享同一份 PageCache，相当于并未耗费额定内存。再次，从 MemTable 转化来的 SST 不须要 BlockCache，又一次减小了内存用量。所有这些劣势叠加，ToplingDB 能够熟能生巧，不附带任何条件地，全方位地优于 RocksDB。【完】【附】write_buffer_size 和 max_bytes_for_level_base = 256M 时（rocksdb 默认值）
【附】write_buffer_size 和 max_bytes_for_level_base = 2560M 时（rocksdb 默认值的 10 倍）
这两个比照充沛地展现了不同配置下写放大的差别：9.0 vs 6.6，因为实际上 L0 的写放大是 0，所以实在的写放大是 8.0 vs 5.6。其中，L4 开始启用压缩，写放大是按压缩后的尺寸计算的，按未压缩的尺寸算，须要乘以 3.3(L4 压缩到 30.6%），按 256M 配置，153.8*3.3 = 505.9，综合写放大是 9.0 + (505.9/221.4) – 1 = 10.3。所以实在的比照是 9.3 vs 5.6!
