乐趣区

关于后端:ToplingDB-如何减小写放大功大欺理

  1. 背景 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!

退出移动版