揭秘存储引擎底座：LSM树如何赋能TDengine时序数据库实现千万级并发写入 在工业物联网与车联网的浩瀚数据海洋中底层 database 面临的最大考验是极端的写入压力。单条产线或单个车队每秒都可能产生数十万甚至上百万个微小的传感器数据点。如果采用传统的 B 树存储引擎海量的随机并发写入会引发毁灭性的磁盘 I/O 瓶颈。为了打破这一物理限制现代实时数据库的存储引擎在底层进行了彻底的重构。其中LSM-TreeLog-Structured Merge-Tree架构成为了业界公认的“银弹”。本文将深度揭秘 LSM 树如何赋能 TDengine 等高性能 时序数据库 实现千万级的并发写入神话。一、 传统 B 树的性能诅咒与随机 I/O在传统的关系型 database如 MySQL、PostgreSQL中B 树是绝对的存储霸主。它非常适合于结构化数据的范围查询和精确查找。然而B 树的每一次数据插入都不可避免地需要进行树节点的定位、分裂以及磁盘页的原地更新In-place Update。 当面对物联网海量设备的并发写入时这种原地更新会引发极其庞大的随机写Random Write操作。即使在顶级的企业级 NVMe 固态硬盘上随机写的性能依然远远逊色于顺序写Sequential Write。随着数据量的暴增B 树的层级不断加深写入一条简单的温度数据可能需要触发多次磁盘随机 I/O最终导致整个 时序数据库 的吞吐量呈现断崖式的崩塌。二、 LSM 树的核心哲学化随机为顺序LSM 树的设计哲学极其巧妙它彻底放弃了在磁盘上的原地更新而是将所有的数据修改包括插入、更新和删除全部转化为在内存中的追加以及后续在磁盘上的顺序写入。 在 TDengine 的底层存储引擎中LSM 树架构被发挥到了极致。当设备数据涌入时这些数据首先被高频地写入到内存表MemTable中。由于操作完全在内存中进行其速度几乎等同于 CPU 的处理极限。当内存表的数据量达到预设的阈值后系统会将其瞬间“冻结”为不可变的结构并由后台线程以纯顺序的方式刷入磁盘形成持久化的 SSTableSorted String Table文件。这种将“海量随机碎数据”拼装成“巨大连续数据块”并进行顺序落盘的机制完美契合了机械硬盘和固态硬盘的物理特性从而在单节点上即可榨干数百万 TPS 的极限写入能力。三、 标记删除与后台压缩Compaction在 LSM 树架构中数据的更新和删除并没有去修改磁盘上的旧数据文件。现代系统通常采用标记删除机制Delete Bitmap或者直接追加一条带有“墓碑Tombstone”标记的新记录。在查询时系统会自动过滤掉被标记的数据。 然而随着时间的推移磁盘上会积累大量包含冗余和过期版本的小型 SSTable 文件这会导致查询时需要扫描多个文件严重影响读取性能。为了解决这个问题TDengine 引擎在后台会持续运行压缩Compaction过程。它将多个小的 SSTable 读取到内存中进行合并排序剔除过期数据和被标记删除的数据然后重新生成一个更大、更紧凑的新文件。这个过程全部在后台异步进行完全不会阻塞前台的千万级并发写入。四、 面向时序的深度定制与升华虽然 LSM 树强大但通用的 LSM 树依然存在“写入放大”的困境。作为专用的 时序数据库TDengine 针对时间序列“绝大部分是按时间顺序产生”的天然特性对标准 LSM 树进行了深度优化。 在 TDengine 中由于同一个设备的传感器数据天然就是按照时间戳递增的这使得数据在写入内存表时几乎不需要进行复杂的重新排序。同时系统在底层以数据块Data Block为单位进行极高比率的列式压缩。通过这一系列面向时序特性的软硬件协同优化企业不仅获得了一个能够扛住千万级并发写入的钢铁洪流底座更将其存储和 I/O 成本压缩到了传统 database 的十分之一。