几分钟掌握TDengine时序数据的保留策略

小 T 导读:在《这几个神秘参数,教你TDengine集群的正确使用方式》这篇文章中,我们讲到了如何利用合理的配置vnode完成TDengine的数据分片,本期我们来继续讲讲TDengine如何从时间维度去对数据进行管理。

首先,先看看官网的相关描述:

“TDengine除vnode分片之外,还对时序数据按照时间段进行分区。每个数据文件只包含一个时间段的时序数据,时间段的长度由DB的配置参数days决定。这种按时间段分区的方法还便于高效实现数据的保留策略,只要数据文件超过规定的天数(系统配置参数keep),将被自动删除。而且不同的时间段可以存放于不同的路径和存储介质,以便于大数据的冷热管理,实现多级存储。”

几分钟掌握TDengine时序数据的保留策略_第1张图片

可以看出,时序数据的保留策略是由keep和days这两个参数牢牢把控的。但是,如果我们想更加深入地理解TDengine时序数据的存储逻辑,从而优化性能的话,只知道上面这些是不够的。

官方文档关于keep和days的描述是这样的:

keep:数据库中数据保留的天数,单位为天,默认值:3650

days:一个数据文件存储数据的时间跨度,单位为天,默认值:10

TDengine通过keep和days严格控制插入数据的时间戳范围:对于过去的数据,不可以超出当前时间减去keep的时间戳值;对于未来的数据,不可以超出当前时间加上days的时间戳值。

我们假设某数据库的keep参数为7,days参数为3,当前时间为某月9日的0点0分。

由于keep为7,所以2日(9-7)之前的数据一定是不可以写入的。再加上限制未来时间数据的插入,12日(9+3)之后的数据也是不可以插入的。通过这样的方式,就有了TDengine当前可处理数据的时间范围time range(彩色范围),当你试图写入位于灰色时间区域的数据时——就会看到“timestamp out of time range”的提示了。

这组图代表了随着当前时间轴的移动,数据文件的分布情况和可写入数据范围的变化。

几分钟掌握TDengine时序数据的保留策略_第2张图片
几分钟掌握TDengine时序数据的保留策略_第3张图片
随着时间的推移,数据的时间戳会与系统时间做计算,一旦超过keep天数,就会被识别为过期数据,等到这个数据文件内的所有数据都过期后,这个数据文件才会被从计算机上清除。

以上述组图为例,由于2日和4日的数据是在同一个数据文件(Data File 1)中,4日的数据最多可以保留到11日结束,所以2日的数据同样也要保留到11日结束。所以我们可以看到,12日的时候,Data File 1已经被删除掉了。

细心的读者可能会问,假如我写入3日的数据,我是如何知道这个数据会落在345这个区间,还是123,或是234呢。其实是这样——TDengine是从1970年1月1日0时0分0秒起(EpochTime)开始,每3天划一个分区。因此,对任何一个时间戳都是“划到哪一片就算到哪一片”。

由于上述的机制删除粒度较粗,所以为了优化用户的体验,在2.1.5.0版本后,我们通过默认设置SQL查询的where timestamp的起始时间大于过期时间来实现用户侧完全可控的“过期数据删除”。所以,现在凡是过期的数据对用户都是不可见的。

虽然在物理层面上,数据仍然是以数据文件为单位删除的。但是除了对存储空间有极其精细要求的用户,绝大多数用户都是没有感知的。本次优化过后,用户不再需要为删除粒度的粗细而产生顾虑。只要安心根据自己的业务类型,灵活设置days参数的大小以找到性能最优的状况就好了。

此外,由于给定了可写入数据的时间范围(now-keep到now+days),给定了数据切分的时间范围(days),所以只要vnode目录下面的数据文件组数量小于等于keep/days向上取余+1,就可以认为自动删除机制是在正常工作的。

以上就是官方文档上所说的:“给定days与keep两个参数,一个vnode总的数据文件数目最多为:keep/days+2”的含义。

从概念上来说,“TDengine是通过vnode以及时间两个维度,对大数据进行切分,便于并行高效的管理,实现水平扩展。”但是如何让枯燥的概念能转化成自己正确的理解,还是需要学习的。《这几个神秘参数,教你TDengine集群的正确使用方式》与本文正是分别从这两个维度切入TDengine原理的,可以说是比较核心的知识点了。

对于TDengine,我们希望大家可以知其然,也知其所以然。

你可能感兴趣的