lsm-tree不是c++标准库组件，需基于跳表或自平衡树从零构建；rocksdb是工程首选，已解决写放大、缓存、并发压缩等核心问题。
LSM-Tree不是C++标准库组件，得从零搭骨架
LSM-Tree是数据结构设计模式，不是现成API。C++里没有std::lsm_tree或rocksdb::LSMEngine这种开箱即用类型——所有主流实现（RocksDB、LevelDB）都是独立库，且重度依赖定制内存管理、WAL日志、后台压缩调度等系统级能力。
直接手写完整LSM引擎不现实：哪怕只支持单线程、无崩溃恢复、纯内存MemTable，也要处理MemTable的并发写入与冻结、SSTable的有序序列化与二分查找、Compaction的文件合并策略和引用计数。这些远超“用C++写个Map”的范畴。
- 别从
std::map或std::unordered_map开始魔改——它们不提供顺序迭代器稳定性和批量序列化接口 - MemTable必须用跳表（
skiplist）或自平衡树（如boost::intrusive::set），不能用std::set——后者无法高效导出有序key-value流 - 磁盘SSTable必须自己定义格式：Magic Number、
Footer偏移、IndexBlock布局——否则连Seek()都做不到
用RocksDB比“手写LSM”更接近真实工程需求
99%的存储系统开发场景下，“基于LSM-Tree”=“集成RocksDB”，而不是重造轮子。它已解决你没意识到的问题：写放大控制（level_compaction_dynamic_level_bytes）、读缓存淘汰（LRUCache）、多线程Compaction队列、CRC校验、IO优先级隔离。
典型误判是认为“RocksDB太重”——但它的核心DB对象实例启动内存占用不到2MB，WriteOptions和ReadOptions可精细控制延迟/吞吐权衡。
立即学习“C++免费学习笔记（深入）”；
- 开启
allow_mmap_reads = true能显著降低小key随机读的page fault开销 - 写密集场景务必设
write_buffer_size = 64 （64MB），避免频繁MemTable flush导致IOPS毛刺 -
block_cache建议用cache = NewLRUCache(512 ，小于512MB时RocksDB会自动降级为<code>NullCache，读性能断崖下跌
绕不开的底层陷阱：WAL、Sync和fsync语义
LSM引擎的持久性不来自SSTable，而来自WAL（Write-Ahead Log）。C++里fdatasync()和fsync()行为差异会直接导致数据丢失——尤其在ext4+默认挂载参数下，fsync()可能只刷到disk cache而非物理介质。
RocksDB默认用O_DSYNC打开WAL文件，这是关键安全边界；若手动实现，write()后必须跟fdatasync()，且不能依赖fclose()隐式刷盘。
- 禁用
disableWAL = true除非明确接受进程崩溃丢数据 - 云环境（AWS EBS、GCP Persistent Disk）需确认底层是否支持
fdatasync()——部分虚拟块设备将其降级为no-op - 使用
env->NewLogger()捕获IO error: While fsyncing the write-ahead log这类错误，这是磁盘故障的第一信号
Compaction不是后台任务，是读写路径的协同约束
Compaction不是“空闲时清理垃圾”，而是读路径的前置条件：未合并的旧版本SSTable会导致Get()扫描多个文件，写路径的MemTable冻结又依赖旧SSTable完成合并才能释放内存。三者形成强耦合闭环。
RocksDB的compaction_pri参数（如kMinOverlappingRatio）直接影响Range Delete的清理效率——若业务大量删范围，不调这个值会导致Deleted keys堆积数小时不释放空间。
-
max_background_compactions = 4在NVMe盘上合理，但HDD应设为1，否则Compaction I/O会饿死前台读 - 启用
universal_compaction前确认key分布：它对时间序写入友好，但对随机key写入会产生严重写放大 -
compaction_readahead_size设为2 （2MB）可提升大文件顺序读吞吐，但小实例内存紧张时可能引发OOM
LSM真正的复杂点不在数据结构本身，而在WAL、MemTable、SSTable、Compaction四者之间的时间窗口博弈——哪个环节的延迟抖动，都会被放大成端到端P99毛刺。这点容易被静态代码分析忽略。
