河北建设网站,Python能开发WordPress,网络营销广告名词解释,北京搜索优化推广公司在时序数据库#xff08;Time Series Database#xff09;场景下#xff0c;乱序数据的定义为#xff1a;“时间戳#xff08;timestamp#xff09;不按照递增顺序到达数据库的数据。”虽然它的定义很简单#xff0c;但时序数据库需要有相应的处理逻辑来保证数据存储时的…在时序数据库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 之上如何把数据从 TDengine 2.x 迁移到 3.x 。
