关于数据库:何时删怎么删5分钟吃透TDengine过期数据自动清除机制

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

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

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

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

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

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

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

首先，咱们来简略理解一下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日生成的数据文件竟然还没有被删除。

想搞懂这个问题的答案，咱们还须要晓得的是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的主动删除机制了吗？如果还没有，那肯定是我的尽职了。