小 T 导读：在《这几个神秘参数，教你 TDengine 集群的正确应用形式》这篇文章中，咱们讲到了如何利用正当的配置 vnode 实现 TDengine 的数据分片，本期咱们来持续讲讲 TDengine 如何从工夫维度去对数据进行治理。
首先，先看看官网的相干形容：
“TDengine 除 vnode 分片之外，还对时序数据依照时间段进行分区。每个数据文件只蕴含一个时间段的时序数据，时间段的长度由 DB 的配置参数 days 决定。这种按时间段分区的办法还便于高效实现数据的保留策略，只有数据文件超过规定的天数（系统配置参数 keep)，将被主动删除。而且不同的时间段能够寄存于不同的门路和存储介质，以便于大数据的冷热治理，实现多级存储。”
能够看出，时序数据的保留策略是由 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”的提醒了。
这组图代表了随着以后时间轴的挪动，数据文件的散布状况和可写入数据范畴的变动。
随着工夫的推移，数据的工夫戳会与零碎工夫做计算，一旦超过 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，咱们心愿大家能够知其然，也知其所以然。