在之前的一期内容里，咱们讲到了如何利用正当的配置 vnode 实现 TDengine 的数据分片（这几个神秘参数，教你 TDengine 集群的正确应用形式），本期咱们来持续讲讲 TDengine 如何从工夫维度去对数据进行分区治理。

首先，先看看官网的相干形容：

“TDengine 除 vnode 分片之外，还对时序数据依照时间段进行分区。每个数据文件只蕴含一个时间段的时序数据，时间段的长度由 DB 的配置参数 days 决定。这种按时间段分区的办法还便于高效实现数据的保留策略，只有数据文件超过规定的天数（系统配置参数 keep)，将被主动删除。而且不同的时间段能够寄存于不同的门路和存储介质，以便于大数据的冷热治理，实现多级存储。

总的来说，TDengine 是通过 vnode 以及工夫两个维度，对大数据进行切分，便于并行高效的治理，实现程度扩大。”

能够看出，在这个过程中 keep 参数在施展着非常重要的作用。然而同样，keep 参数也算是比拟典型的，容易令使用者蛊惑的参数了。

官网文档对于 keep 的形容是这样的：“数据库中数据保留的天数，单位为天，默认值：3650”，和他一起搭配应用的还有一个 days 参数：“一个数据文件存储数据的时间跨度，单位为天，默认值：10”。

从使用者的角度，对于这句话的了解就是数据保留 keep 的天数后就不应该能够查问到数据了。然而，在实际操作的时候，常常能够看到曾经超出工夫范畴的数据仍然呈现在了查问后果当中。

why？

首先，咱们来简略理解一下 TDengine 的存储逻辑：数据写入数据库后，会先保留在内存中的缓冲区（buffer pool）当中，当达到阈值后（缓冲区 1 /3，或者敞开数据库服务）内存中数据就会落盘到该表所属的 vnode 的目录上面（默认 /var/lib/taos/vnode/vnodeX/tsdb/data）。其中 vnodeX 中的 X 能够通过 show vgroups 命令看到。

示范如下：

测试的时候，只有随便插入一条数据，而后做一下服务重启：systemctl restart taosd，刚刚写入内存的数据当初就会落到硬盘上。

注：重启服务是一个很实用的测试操作，能够触发内存中的数据落盘——目前，只有数据落盘时才会触发主动删除机制（后续在初始化时也会减少主动删除触发）。如果该数据库前面不再有数据落盘，那么数据文件即便过期了也是不会被删除的。

当初，你就能够找到你的数据文件了，下图能够看到，在重启之前这个目录下还没有任何文件。但在重启之后，就看到了三个以 1880 为编号的一组文件。

从狭义上来说，这三个文件都属于数据文件，前面提到的数据文件都是指他们三个造成的文件组。

接下来，咱们回到理论的场景中。

想测试数据存储策略的同学对上面这个场景肯定不生疏：建库的时候，咱们指定 keep 为 10，days 为 10。如果数据文件是 1 月 1 日生成，然而到了 1 月 19 日的时候，1 月 1 日插入的数据却还是能够被查问到。于是，你从 taos shell 里退出来一看——果然，1 月 1 日生成的数据文件竟然还没有被删除。

奇怪——难道是 keep 参数没有失效?

想搞懂这个问题的答案，咱们还须要晓得的是 days 参数的设计：咱们所说的 days 定义——“数据文件保留的数据时间跨度”，它是以零碎工夫断定的，逻辑是：数据文件第一次生成的日期为起始日期，与零碎工夫做计算（注：该计算只以天然日为切分，不以 24 小时计算）。一旦文件生成超过 days 天数，在下次数据落盘的时候就会生成新的数据文件。

事实上，当你发现旧数据仍然能够查问的时候，99.9% 的状况都不是 keep 不失效。最基本的起因其实是 TDengine 要等到数据文件外面的所有数据过期后才会删除它们。还是下面的场景（keep 10 days 10）：1 月 1 日产生的数据文件中是可能存在 1 月 10 日的数据的，所以在 1 月 19 日的时候，这部分数据还没有到 10 天，所以在设计上是不容许删除的。因而，就拖带着 1 - 9 日间的数据也没有被删除掉。

以上，就是文章题目的答案。

能够看出，因为数据文件是以 days 为单位存储在一起的，所以 days 越小，主动删除就会越精准。那为什么咱们不罗唆把 days 设置小一点呢？其实这样是没问题的。然而在性能上，days 越小意味着意味着数据文件的数目越多，从而导致太多文件频繁开关读取减少开销。所以，默认值取 days 为 10 就是一个折中的抉择。

当初，咱们来到了新的问题：

1.TDengine 是在什么状况下才会删除过期文件呢？

2. 咱们要通过什么形式来疾速判断主动删除机制是否在失常工作呢？

咱们能够把这两个问题交融在一个场景下进行答复：

问题一：答案只有接着上文的场景持续推动就能够失去（keep 10 days 10）：工夫来到 1 月 21 日时，第 3 批数据文件生成，此时第 1 批数据文件的最初 1 天的数据终于也超过了 keep 值。这个时候，keep 才会正式失效并把第一组数据文件从存储中删除。当初回到 TDengine 外面，你就查不到这部分数据了。

问题二：答案是只有数一数 vnode 上面的数据文件组数就能够了：比方在下面的状况下（keep 10 days 10），vnode 目录上面的数据文件数最多也就只有两组：1-10 日 11-20 日（工夫范畴），当存储 21-30 日的数据文件生成时，1-10 日的数据文件曾经被删掉了，所以最多只能保留两个，计算形式为 keep/days+1。在这种状况下，只有 vnode 下的数据文件数小于等于 keep/days+1，就能够认为主动删除机制在失常工作。

然而在 keep 不能被 days 整除的状况下，还会呈现上面的状况：

咱们假如 keep=3 days=2。在这个配置下，第一批数据文件中存储的工夫是 1 - 2 日，第二个数据文件为 3 - 4 日。能够看到，当第一个文件中的第 2 日数据要在第 5（2+3）日完结后才会过期，所以到 6 日开始时，12 日的数据文件才会被删掉。这样一来，在 5 日和 6 日之间的时间段内，就会呈现 12 日，34 日，5 日三个文件共存的景象。

以上就是官网文档上所说的：“给定 days 与 keep 两个参数，一个典型工作状态的 vnode 中总的数据文件数为：向上取整 (keep/days)+ 1 个”的真正意思。

所以，只有你的 vnode 目录下的文件数目合乎下面的两种场景的后果，那么就没必要放心主动删除机制没有失常工作。

看到这里的读者，当初你理解了 TDengine 的主动删除机制了吗？如果还没有，那肯定是我的尽职了。