LSM-Tree 存储引擎在写放大（Write Amplification）优化中的性能瓶颈问题

Question

21 浏览2024年8月5日

0

魏鸣谦 2024年7月3日 0条评论

毕业论文研究方向是基于键值存储（KV Store）的 LSM-Tree 压测优化与合并策略（Compaction）改进。目前在基于 RocksDB 进行对比实验时，遇到了两个影响论文核心结论的问题，想请教大家：

写停顿（Write Stalls）严重：在模拟持续高吞吐写入时，由于 L0 层文件积压过多，触发了系统的强制流控。我看文献中提到采用 Leveled Compaction 配合 Tiered 的混合模式可以缓解，但在我的实现中，一旦触发大规模的后台合并，磁盘 I/O 占用率瞬间飙升到 95% 以上，导致前端读延迟（Read Latency）出现了极其严重的“长尾效应”（P99 指标翻了 5 倍）。
具体困惑：

布隆过滤器（Bloom Filter）失效：为了加速点查询，我为每一层都构建了布隆过滤器。但在论文实验中发现，随着 Key 的频繁更新，误判率（False Positive Rate）并没有像理论公式 ϵ≈(1−e−kn/m)k 预测的那样稳定，导致大量无效的磁盘 I/O。冷热数据分离：大家在做冷热分区时，是倾向于在 MemTable 阶段就进行预测，还是在 SST 文件合并到高层后再通过热度统计来迁移？
实验环境：Ubuntu 22.04, NVMe SSD, RocksDB v8.1, 测试工具使用 db_bench。

邵奕杉已回答的问题 2024年8月5日

2 答案

您正在查看2个答案中的1个，单击此处查看所有答案。

score 0 · Answer 1 · 2024-08-05T16:03:23+00:00

提醒一下：你的 SSD 是否开启了 TRIM 优化？在长时间压测下，SSD 本身的垃圾回收（GC）可能会和 RocksDB 的 Compaction 发生“共振”，导致 I/O 吞吐断崖式下跌。论文加分点建议：你可以监控一下系统的 iostat 数据，画一张写放大系数 vs. 空间放大系数的帕累托前沿图（Pareto Frontier），通过量化分析来证明你改进算法的有效性。