【NebulaGraph】如何为 NebulaGraph 的存储引擎增加一个新的 Compaction 策略？

NebulaGraph 3.8.0 存储引擎 Compaction 策略深度定制：从源码集成到生产调优的全链路解析引言：问题界定与场景引入本文将深入解析用户提出的“如何为 NebulaGraph 的存储引擎增加一个新的 Compaction 策略？”这一核心问题。Compaction（压缩/合并）是基于 LSM-Tree 架构的存储引擎（如 RocksDB）的核心后台任务，它直接影响着系统的写入放大（Write Amplification）、读取性能和磁盘空间利用率。一个不合适的 Compaction 策略，极易引发RocksDB Compaction 风暴，导致 Storaged 节点 CPU 和 I/O 资源耗尽，进而引发 P0 级线上事故。我们将聚焦于NebulaGraph 3.8.0版本，系统性地拆解其存储引擎对 RocksDB Compaction 策略的封装机制，并通过一个完整的开发案例，手把手教你如何创建并集成一个全新的、适用于特定业务场景的 Compaction 策略。为了使抽象概念具象化，我们以电信网络故障溯源场景为例。在该场景中，图谱数据具有明显的时间局部性：新产生的告警和设备状态数据会被频繁查询和更新，而超过7天的历史数据则几乎只读，且查询频率极低。默认的