优化点 | 解决的问题 | 业务收益 |
基于垃圾率的主动 GC | RocksDB 原生 GC 仅按"年龄"挑选文件,老文件中可能仍是有效数据 | 更精准回收,磁盘空间更省 |
GC 优先级元数据 | 主动 GC 需要持久化"哪些 Blob 更紧急回收"的标记,原生 BlobDB 无此字段 | 重启后 GC 进度不丢失,DBA 可干预紧急 Blob |
小 Blob 文件合并 | 频繁 Compaction 会产生大量碎片化的小 Blob 文件 | 减少文件数,降低元数据开销 |
Blob GC 直接拷贝 | 默认 GC 需要先解压 → 重新压缩 Blob 数据 | GC CPU 开销显著下降(实测5KB value 提速约1.5倍,10KB 约1.4倍) |
Blob 写入 Sync 优化 | RocksDB 默认强制1MB 一次 RangeSync,现代 SSD 上反而成为瓶颈 | Blob 写入 IOPS 提升,长尾延迟下降 |
Blob 值懒加载 | 范围扫描时即使最终不读 Value,迭代器也提前加载了 Blob | 范围扫描性能提升(如 SELECT COUNT(*)、唯一性校验) |
DeleteRange 加速 | 大批量范围删除会逐条更新 Blob 引用计数 | 大批量删除更快 |
共享 Blob Cache | 默认无 Blob Cache,每次读 Blob 都是磁盘 I/O | Blob 热点读延迟下降(需重启) |
Blob 起始 Level | 上层(L0/L1)数据短命,分离反而增加 GC 压力 | 默认从 L1 开始分离,更平衡 |
按 Level 设置压缩算法 | 不同层数据冷热不同,统一压缩不灵活 | 冷数据可用 ZSTD 强压缩省空间 |

文档反馈