。

每个数据文件只包含一个时间段的时序数据#xff0c;时间段的长度由DB的配置参数days决定。

这种按时间段分区的方法还便于高效实现数据的保留策略#xff0c;只要数据文件超过规定的天数#xff08;系…“TDengine除vnode分片之外还对时序数据按照时间段进行分区。

每个数据文件只包含一个时间段的时序数据时间段的长度由DB的配置参数days决定。

这种按时间段分区的方法还便于高效实现数据的保留策略只要数据文件超过规定的天数系统配置参数keep)将被自动删除。

而且不同的时间段可以存放于不同的路径和存储介质以便于大数据的冷热管理实现多级存储。

”

可以看出时序数据的保留策略是由keep和days这两个参数牢牢把控的。

但是如果我们想更加深入地理解TDengine时序数据的存储逻辑从而优化性能的话只知道上面这些是不够的。

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

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

由于keep为7所以2日9-7之前的数据一定是不可以写入的。

再加上限制未来时间数据的插入12日93之后的数据也是不可以插入的。

通过这样的方式就有了TDengine当前可处理数据的时间范围time

range彩色范围当你试图写入位于灰色时间区域的数据时——就会看到“timestamp

out

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

随着时间的推移数据的时间戳会与系统时间做计算一旦超过keep天数就会被识别为过期数据等到这个数据文件内的所有数据都过期后这个数据文件才会被从计算机上清除。

File

1中4日的数据最多可以保留到11日结束所以2日的数据同样也要保留到11日结束。

所以我们可以看到12日的时候Data

File

细心的读者可能会问假如我写入3日的数据我是如何知道这个数据会落在345这个区间还是123或是234呢。

其实是这样——TDengine是从1970年1月1日0时0分0秒起EpochTime开始每3天划一个分区。

因此对任何一个时间戳都是“划到哪一片就算到哪一片”。

由于上述的机制删除粒度较粗所以为了优化用户的体验在2.1.5.0版本后我们通过默认设置SQL查询的where

timestamp的起始时间大于过期时间来实现用户侧完全可控的“过期数据删除”。

所以现在凡是过期的数据对用户都是不可见的。

虽然在物理层面上数据仍然是以数据文件为单位删除的。

但是除了对存储空间有极其精细要求的用户绝大多数用户都是没有感知的。

本次优化过后用户不再需要为删除粒度的粗细而产生顾虑。

只要安心根据自己的业务类型灵活设置days参数的大小以找到性能最优的状况就好了。

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

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

从概念上来说“TDengine是通过vnode以及时间两个维度对大数据进行切分便于并行高效的管理实现水平扩展。

”但是如何让枯燥的概念能转化成自己正确的理解还是需要学习的。

《这几个神秘参数教你TDengine集群的正确使用方式》与本文正是分别从这两个维度切入TDengine原理的可以说是比较核心的知识点了。