毕业论文研究方向是基于键值存储（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。
提醒一下：你的 SSD 是否开启了 TRIM 优化？ 在长时间压测下，SSD 本身的垃圾回收（GC）可能会和 RocksDB 的 Compaction 发生“共振”，导致 I/O 吞吐断崖式下跌。 论文加分点建议：你可以监控一下系统的 iostat 数据，画一张 写放大系数 vs. 空间放大系数 的帕累托前沿图（Pareto Frontier），通过量化分析来证明你改进算法的有效性。
写放大和读延迟的权衡是 LSM-Tree 的经典难题。 检查一下你的 Compaction Priority 设置。如果你更看重读性能，应该优先合并重叠度最高的 SST 文件。针对 P99 延迟问题，建议开启 Rate Limiter（速率限制器），平滑后台 IO。论文里可以分析一下：在牺牲一定写入峰值的情况下，如何通过流控换取更稳定的响应曲线，这是非常有价值的稳健性分析。
