SlateDB项目中墓碑标记在最后排序运行中的过滤优化

在LSM树结构的存储引擎中，墓碑标记(Tombstone)是一个重要的设计元素。当用户删除某个键值对时，系统不会立即从磁盘上删除该数据，而是写入一个特殊的墓碑标记来标识该键已被删除。这种设计在提升写入性能的同时，也带来了一些需要优化的空间。

SlateDB作为新一代的存储引擎，近期社区发现了一个关于墓碑标记处理的优化点。在当前的实现中，所有层级的排序运行(Sorted Run)都会保留墓碑标记，包括最后的排序运行。这种设计存在两个主要问题：

1. 空间浪费：墓碑标记在最后层级的排序运行中实际上已经失去了其核心作用，却仍然占用存储空间
2. 查询效率：不必要的墓碑标记会增加查询路径的长度

技术团队经过深入讨论，提出了优化方案。核心思路是：在数据压缩(Compaction)过程中，当数据被合并到最后层级的排序运行时，可以安全地过滤掉所有的墓碑标记。这是因为：

• 墓碑标记的主要作用是防止读取操作从较低层级获取已被删除的键值
• 在最后层级的排序运行中，已经没有更低层级的数据需要屏蔽

实现方案将通过在Compaction结构体中添加明确的标志位(如include_filters)来控制是否包含墓碑标记，而不是简单地判断是否为最后运行。这种设计更加符合软件工程的高内聚低耦合原则，将业务逻辑集中在Orchestrator组件中，保持执行器的通用性。

这项优化将带来明显的收益：

1. 减少最后层级约5-15%的存储空间占用(取决于删除操作的比例)
2. 提升点查性能，减少不必要的标记检查
3. 降低压缩过程中的I/O和CPU开销

对于LSM树结构的存储引擎开发者而言，这个案例很好地展示了如何通过深入理解数据生命周期来优化存储效率。类似的优化思路也可以应用于其他场景，比如过期的TTL数据清理等。

该优化方案已经由社区贡献者KaguraMilet实现，并通过了核心维护团队的代码审查。这体现了SlateDB社区良好的协作机制和技术洞察力。