关于RocksDB通用压缩num_levels=1时单SST文件的疑问

1. 文档描述是否过时/有误？排序运行能否包含多个SST文件？ #

RocksDB官方文档中“num_levels=1的通用压缩模式下整个数据库可写入单个SST文件”的表述并没有过时或错误，但它描述的是理想场景，而非必然行为。

实际上，Sorted Run完全可以包含多个SST文件：

• Sorted Run的定义是一组键范围不重叠、各自内部有序的SST文件集合，多个SST共同构成一个整体有序的数据集。
• 当你设置target_file_size_multiplier=1时，所有生成的SST文件都会保持target_file_size_base的大小。如果某次compaction需要合并的数据总量超过单个target_file_size_base的上限，RocksDB会自动将合并后的数据集拆分为多个同大小的SST文件，归入同一个Sorted Run。
• 旧的Sorted Run包含更多SST文件，通常是因为多次compaction合并时总数据量持续超出单文件上限，或是写入压力较大时，RocksDB优先处理新数据的flush/compaction，旧数据的合并未完全合并为更少的文件，这都是正常运行逻辑。

2. 监控索引块大小的重要性及方法 #

重要性 #

• 索引块是SST文件的核心元数据，用于快速定位目标键所在的数据块。过大的索引块会直接增加内存占用（若配置为常驻内存），或提升磁盘IO次数（若需从磁盘读取），进而拖慢查询性能。
• RocksDB的索引块有4GB的硬上限（因使用32位偏移量），一旦单个SST的索引块超过此限制，会直接导致SST文件创建失败，引发服务异常。

监控方法 #

• 内置统计属性：通过RocksDB的GetProperty接口获取相关指标，比如rocksdb.sst.index.block.size（单SST索引块大小）、rocksdb.num-index-blocks（索引块总数）。
• sst_dump工具：使用RocksDB自带的sst_dump命令查看单个SST文件的元数据，命令示例：sst_dump --file=your_sst_file.sst --show_properties，输出中会包含索引块的大小、数量等详细信息。
• 集成监控系统：将RocksDB的metrics导出到Prometheus等监控平台，设置告警阈值（比如当索引块大小接近4GB上限时触发告警），实现实时监控。

3. 关于索引块与Sorted Run的补充理解 #

你的判断是正确的：索引块是基于单个SST文件而非整个Sorted Run。每个SST文件都有独立的索引结构（一级索引、若开启则包含二级索引），因此即使一个Sorted Run包含大量SST文件，只要单个SST的索引块不超过4GB上限，就不会触发限制问题。

内容的提问来源于stack exchange，提问作者cmcnealy