多级索引结构构建：提升时序数据库TDengine中海量tag检索速度的内部机制

在探讨 时序数据库 的性能时人们往往将目光聚焦于极高的写入吞吐量和极低的磁盘扫描延迟上。然而在海量物联网场景中最先遭遇性能瓶颈的往往不是“查数据”而是“找设备”。试想当一个智慧城市系统接入了 5000 万个传感器如果你想查询“海淀区、所有处于报警状态的、A 型号烟感探测器”的历史数据底层 database 需要在几毫秒内从 5000 万个设备中精准筛选出符合条件的几百个设备然后再去读取它们的时序数据。为了实现这种犹如大海捞针般的极速定位TDengine 构建了一套极其精密的多级索引结构。一、 标签Tag检索面临的挑战在 TDengine 的架构中每个设备对应一张子表而描述设备静态属性的元数据如地理位置、设备型号被称为标签Tag存储在超级表Super Table的元数据区。 随着设备规模的膨胀标签数据的体量也变得极为庞大。如果在执行查询时系统需要遍历 5000 万个设备的标签来匹配查询条件这种线性的全表扫描将会耗费数秒甚至数十秒的 CPU 时间彻底拖垮后续的时序数据分析。因此必须为这些元数据构建极其高效的索引机制以便在进入耗时的时序数据读取之前完成设备的极速过滤。二、 内存倒排索引瞬间锁定目标设备为了提升海量 Tag 的检索速度TDengine 在管理节点m-node和虚拟数据节点vnode的内存中构建了高效的多级索引结构其中最核心的便是倒排索引Inverted Index。 传统的关系型数据库通常采用 B 树构建正向索引通过记录 ID 找属性而倒排索引则是“通过属性找记录 ID”。在 TDengine 的超级表机制中系统会自动为用户定义的 Tag 列在内存中维护倒排表。 例如针对 model型号这个 Tag内存中会维护一个类似哈希字典的结构 Model A - [表ID1, 表ID5, 表ID100...] Model B - [表ID2, 表ID8, 表ID99...] 当业务端发起 SELECT * FROM super_table WHERE model Model A 的查询时查询优化器直接命中倒排索引时间复杂度接近 O(1)瞬间就能拿到所有符合条件的表 ID 集合。三、 多条件过滤与位图索引Bitmap Index交叉现实中的查询往往是多维度的例如不仅要查 model A还要查 location Beijing。此时单列的倒排索引就需要进行交叉合并。 为了极速处理多条件查询时序数据库 在底层大量应用了位图索引Bitmap Index和高效的位运算机制。系统将每个 Tag 属性对应的表 ID 集合映射为一串超长的二进制位图0 和 1。当执行多条件 AND 操作时底层的 database 引擎只需在内存中将两个位图进行极速的按位与Bitwise AND运算。现代 CPU 处理位运算的速度快得令人发指这使得即便是在数千万设备的几十个维度中进行复杂的组合筛选也依然能够将耗时死死压制在毫秒级别。四、 结合时序跳数索引的多级穿梭完成了设备标签的极速筛选后多级索引的接力棒交给了我们在前文提到的“时间主键索引”与“数据块跳数索引Skip Index”。 这构成了一个完美的多级检索漏斗 第一级Tag 倒排/位图索引从千万级设备中毫秒级过滤出目标的一百个设备。 第二级时间戳主键索引针对这一百个设备直接定位到目标时间范围如过去两小时所在的物理文件块。 第三级跳数索引读取文件块的头部元数据跳过不包含目标数值如最大值不足以触发报警的数据块。 通过这种从内存元数据到磁盘文件块、层层递进的多级索引结构TDengine 成功地在浩如烟海的工业数据中开辟了一条极速的时空穿梭隧道重新定义了物联网 database 的查询体验。