在时序数据库(Time Series Database)场景下,乱序数据的定义为:“时间戳(timestamp)不按照递增顺序到达数据库的数据。”虽然它的定义很简单,但时序数据库需要有相应的处理逻辑来保证数据存储时的顺序性,这势必会增加数据库架构的复杂性,从而影响数据库的性能表现。
已知完全乱序的数据处理是业界的难题,因此 TDengine 需要重点解决的问题应该是——从实际的业务场景出发,如何对偶发乱序数据的进行高效处理(比如设备损坏断电,网络异常,数据补录等问题)。
TDengine 的数据流向是:硬盘(WAL)→ 内存(Vnode Buffer)→ 硬盘(Data File)。
在 WAL 中,我们记录的是数据到达数据库的顺序,但是数据入库后,是一定要保证时间戳的有序的。因此,乱序数据的处理发生在写入 WAL 后的两个阶段:
基于以上逻辑,我们对乱序数据分为两类:
一. 内存乱序数据:在同一张表的范畴内,指时间戳与内存数据的时间范围相交的数据。
二. 硬盘乱序数据:在同一张表的范畴内,指时间戳与硬盘数据的时间范围相交的数据。
对于类型一的乱序数据,TDengine 会在内存中通过为每张表建立一个跳表结构做好排序,从而解决问题。
场景: 创建某表后,我们写入了从 1970 年到 2023 年的一小批数据(由于数据量较少不足以触发落盘)。当我们再写入一条 1998 年时间戳的乱序数据时,会由跳表进行排序,排序后数据在内存中以“1970-1998-2023”的顺序有序存在。该排序操作的成本由写入操作承担,但由于内存中保留的只是极少数数据,因此影响极小。
当来到落盘阶段时(落盘的细节可参考:文章:与 TDengine 性能直接相关——3.0 的落盘机制优化及使用原则),这三条有序的数据,又都有可能成为乱序数据的存在——即类型二:
首先,我们交代一下硬盘上数据文件的设计背景:由于 TDengine 通过建库参数 duration(days) 做数据分区,假设某库 duration 设置为 10 日,那么自打 1970 年 1 月 1 日 0 时起,每隔 10 天就会划分一个数据文件组。写入的数据时间戳归属于哪个时间范围,便会写入哪个数据文件组中——即每个数据文件组中都包含了固定时间范围内的数据。而这些数据以数据块的形式存在,每个数据块所包含的时间范围视落盘时实际情况而定。
落盘时,数据会各自找到自己所属的数据文件组,根据该数据文件组中已有的数据块的时间范围计算,来判断数据的乱序与否。由此,会衍生出各种不同的情况。我们选出属于 2023、1998、1970 年份的三条数据,分别举例三种情况:
- "2023-01-01 xxxxxxx" 这条数据落盘时,并没有和这个表的任何数据块的产生时间交集——也就是非乱序的正常数据。
- “1998-01-01 xxxxxxxx”:这条数据落盘时虽然和该表的整体时间范围(1970--2023)产生交集,但是局部时间范围内没有和该表任何数据块产生交集。这种乱序通常发生于历史数据的数据补录。比如:被采集的设备断电很久后恢复使用。因此这条数据虽然看似乱序,但实际上和正常数据差别不大。
- “1970-01-01 xxxxxxxx” ,这条数据在落盘时和该表数据块的时间范围产生了交集:早在 2.0 当中,如果落盘时的数据和已有数据块时间戳相交的时候,乱序数据会形成一个子块追加在数据文件中,查询时需要把子块的数据读到内存中再做排序,当子块比较多的时候就会影响查询性能——经过重新设计后,在 3.0 当中乱序数据和原有数据将会合并重写为新的数据块,以追加的方式写入数据文件中并且重写索引,而旧的数据块则被视为碎片文件。这样一来,处理数据的成本就被转嫁给了落盘操作,因此对后续的查询基本没有影响。
综上,在乱序数据写入硬盘的时候,由于数据块和索引文件均是新生成的,因此它对于后续的查询是比较友好的。考虑到乱序数据一定是业务上的偶发场景,因此这样处理基本不会造成性能负担。即便是产生了少部分由于乱序带来的碎片数据、无效数据块也都可以由企业版功能 compact 清除或者重组。
从很多角度来说,TDengine 3.0 都已经达成了长足的优化。因此随着 2.0 时代逐步进入尾声,我们也希望大家可以尽早从 2.0 切换到 3.0 之上:https://mp.weixin.qq.com/s/Vhx8QFZBnTcMoHWhX32ZyA。