在时序数据库(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 年份的三条数据,分别举例三种情况:
综上,在乱序数据写入硬盘的时候,由于数据块和索引文件均是新生成的,因此它对于后续的查询是比较友好的。考虑到乱序数据一定是业务上的偶发场景,因此这样处理基本不会造成性能负担。即便是产生了少部分由于乱序带来的碎片数据、无效数据块也都可以由企业版功能 compact 清除或者重组。
从很多角度来说,TDengine 3.0 都已经达成了长足的优化。因此随着 2.0 时代逐步进入尾声,我们也希望大家可以尽早从 2.0 切换到 3.0 之上:https://mp.weixin.qq.com/s/Vhx8QFZBnTcMoHWhX32ZyA。
页面更新:2024-02-12
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号