在工业物联网与车联网的浩瀚数据海洋中，底层 database 面临的最大考验是极端的写入压力。单条产线或单个车队每秒都可能产生数十万甚至上百万个微小的传感器数据点。如果采用传统的 B+ 树存储引擎，海量的随机并发写入会引发毁灭性的磁盘 I/O 瓶颈。为了打破这一物理限制，现代实时数据库的存储引擎在底层进行了彻底的重构。其中，LSM-Tree（Log-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 的处理极限。当内存表的数据量达到预设的阈值后，系统会将其瞬间“冻结”为不可变的结构，并由后台线程以纯顺序的方式刷入磁盘，形成持久化的 SSTable（Sorted String Table）文件。这种将“海量随机碎数据”拼装成“巨大连续数据块”并进行顺序落盘的机制，完美契合了机械硬盘和固态硬盘的物理特性，从而在单节点上即可榨干数百万 TPS 的极限写入能力。
三、 标记删除与后台压缩（Compaction）
在 LSM 树架构中，数据的更新和删除并没有去修改磁盘上的旧数据文件。现代系统通常采用标记删除机制（Delete Bitmap）或者直接追加一条带有“墓碑（Tombstone）”标记的新记录。在查询时，系统会自动过滤掉被标记的数据。 然而，随着时间的推移，磁盘上会积累大量包含冗余和过期版本的小型 SSTable 文件，这会导致查询时需要扫描多个文件，严重影响读取性能。为了解决这个问题，TDengine 引擎在后台会持续运行压缩（Compaction）过程。它将多个小的 SSTable 读取到内存中进行合并排序，剔除过期数据和被标记删除的数据，然后重新生成一个更大、更紧凑的新文件。这个过程全部在后台异步进行，完全不会阻塞前台的千万级并发写入。
四、 面向时序的深度定制与升华
虽然 LSM 树强大，但通用的 LSM 树依然存在“写入放大”的困境。作为专用的 时序数据库，TDengine 针对时间序列“绝大部分是按时间顺序产生”的天然特性，对标准 LSM 树进行了深度优化。 在 TDengine 中，由于同一个设备的传感器数据天然就是按照时间戳递增的，这使得数据在写入内存表时几乎不需要进行复杂的重新排序。同时，系统在底层以数据块（Data Block）为单位进行极高比率的列式压缩。通过这一系列面向时序特性的软硬件协同优化，企业不仅获得了一个能够扛住千万级并发写入的钢铁洪流底座，更将其存储和 I/O 成本压缩到了传统 database 的十分之一。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
