构建 SaarDB 第三部分：压缩
来源：dev.to — Jul 20
📋 概述
Gagandeep Singh Ahuja 继续他的从零构建数据库系列。LSM 树在写入时追加新 SSTable 文件，但随着文件数量增长，读放大（一个 GET 要搜索所有 1000 个文件）和空间放大（同一键的旧版本占用空间）成为严重问题。解决方案是压缩：定期合并多个 SSTable，只保留每个键的最新值，生成一个新的整合文件。
🔑 核心要点
- 读放大：1000 个 SSTable 文件意味着最坏情况下搜索 1000 次才能找到或确认不存在
- 空间放大：一个键被更新 100 次 = 存储 100 个副本，只有最新的有用
- 压缩合并：读取多个 SSTable → 每键只保留最新值 → 写回单个新文件
- LSM 树的写入优化以读性能和空间为代价——压缩是恢复平衡的机制
- 从零构建数据库系列：WAL→LSM Tree→Compaction，逐步深入存储引擎核心
💡 金句
每写入一个键 100 次，就存储了 100 个副本。1000 次 memtable 刷写 = 1000 个 SSTable 文件。追加写入虽然快，但垃圾会随时间累积。
👍 0
👎 0
← 返回 Dev.to 首页