【存储工程】LSM-Tree 工程调优：三种放大的权衡
LSM-Tree 的核心设计是把随机写转换为顺序写，但这个转换不是免费的。写入经过 MemTable 刷盘、再经过多次 Compaction 合并，每一字节的用户数据在磁盘上可能被反复读写数十次。读取一个 key 时，最坏情况下需要逐层搜索，直到命中或遍历全部层级。与此同时，旧版本数据和墓碑标记占用的额外空间，在 Co…
write-amplification 标签归档
共 4 篇文章 · 返回首页
【存储工程】存储引擎概览：堆文件到 LSM-Tree 的演化路径
数据库系统的架构可以划分为两大层：上层的查询处理层负责解析 SQL、生成执行计划、优化查询；下层的存储引擎（Storage Engine）负责把数据持久化到磁盘，并在需要时高效地把数据取回来。查询处理层决定"做什么"，存储引擎决定"怎么存、怎么取"。同一个查询处理层可以对接不同的存储引擎——MySQL 的 InnoDB…
【存储工程】SSD 与 NAND Flash：FTL、写放大与磨损均衡
SSD 已经在大多数性能敏感场景中取代了 HDD，但 SSD 并不是"没有机械部件的硬盘"——它是一个完全不同的存储架构，带来了一组全新的工程约束。理解这些约束，需要从 NAND Flash（NAND 闪存）的物理特性开始，逐层向上推导出 FTL（Flash Translation Layer）、垃圾回收（Garbag…
【从零写一个 LSM-Tree 存储引擎】LSM-Tree 全景：为什么要先写日志再排序
从零理解 LSM-Tree 存储引擎的设计哲学：B-Tree 与 LSM-Tree 的本质差异，写放大/读放大/空间放大的三角权衡，以及 WAL、MemTable、SSTable、Compaction、Bloom Filter 各组件的角色与协作关系。从零写一个 LSM-Tree 存储引擎系列第 1 篇。