开发者学堂课程【PolarDB-X 开源分布式数据库进阶课程 ：PolarDB-X 数据 TTL 过期删除（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1202/detail/18333
PolarDB-X 数据 TTL 过期删除
内容介绍：
一、TTL 功能介绍
二、实验演示
三、TTL 原理介绍
四、TTL 性能
一、TTL 功能介绍
今天的内容是 ttl 表的使用和原理，相信参加过前面几期课程的对 polarDB-x 有了一定的了解，它是一个存储计算分离的 otp 关系型数据库，今天的内容课程主要分为三个比较大的模块，第一个是 ttl 功能的介绍以及在实验室中的演示，然后等会儿会带着大家一起演示，一起在实验室中操作了一遍 ttl 表的所有的功能，感兴趣的话，可以大家打开实验室一起来做一下这个实验，第二块是表的原理的介绍，polarDB-dx 开源版的内核是如何实现提交表，然后最后一部分是 ttl 表的性能的一个测试，首先在介绍ttl表之前，先跟大家探讨一下为什么我们需要一个体贴表示这样的功能，因为你想如果实际开发过一些应用系统的话，其实大家会发现应用系统中有很多的场景，它的数据是跟时间强相关的，然后典型的话就比如说订单系统或者快递电商以及系统的日志等等，然后这一部分的数据它有一个很长的时效性，然后并且他的数据随时间增长会很快，但是他的热度下降的也很快然后有可能会有一些检查甚至是范围查询的一些请求。但这部分请求访问的也基本上都是比较新的数据，老的数据的话基本上是很少会被访问到的，那如果数据一直存储在我们的数据库中，一直存储在 polarDB-x 中，它是会占用着你的表空间的，那表空间其实意味着你的存储成本会上升，那你查询的效率会下降，与其一直付出代价，来维护着这一些数据，不如去定期的把这部分数据给删除掉，或者说归档到一些成本更低的数据库中，比如说我可以把它归拢到一个内存水库或者说 oasis 等系统中这样的话，这样的话，你是关系型数据库中存储的基本都是一些你需要查询的比较新的数据，然后一些很少之前的就可以在冷存储中执行的。但是归档的话，其实有一个怎么归档的一个问题，那在之前的话，其实大家也比较习惯于比如说直接通过一个的类似语句加一个 where 条件来删掉一些比较老的数据，但是问题就在于 delete 语句它其实是如果删的数据比较数据规模比较大的话，他 mexico 会认为他是一个需要一个全程扫描，然后他会锁住手术整个的家属，也有可能会产生大量的 bing log，因为你删数据的话，你是需要一个是事务性保证的，所以它会占用你大量的磁盘空间，那如果数量太大的话，你甚至会因为你的内存不够，导致删失败等等这样的话其实就是一个比较危险的操作。
业务特性：
数据实效性：
业务数据随时间增长很快，并且业务数据的热度随着时间推移会有明显的降低。
这时候，大部分的请求访问的其实都是较新的数据。如果数据一直存储在 PolarDB-X 中，会降低正常业务查询的效率。所以有些业务场景会定期删除或归档数据。
存储成本：
除了降低查询效率之外，如果数据一直存储在 PolarDB-X 中，也会占用存储空间。一般而言，为了支持高速存取，数据库的存储成本相对于 OSS 等冷存储是比较高的。
归档问题：
通过 delete 语句删除大规模数据，会造成锁表、产生大量 binlog、磁盘空洞等问题，是一个较危险的操作。大规模delete 后一般还需 Optimize 一下，同样可能会继续锁表，以及占用额外磁盘空间。
典型场景：订单、快递、电商、日志等
那即便你删除成功的，那其实你的那个比较占有的空间他还在，所以你其实并没有真正的释放出来相应的磁盘空间，这样的话你存储的成本还是在那里，然后一般来说大规模的 delete 语句之后还需要补一个操作，操作的话其实就是重建一下会把所有的数据作为一个搬运，然后中间可能还会拿一下 m 批加锁，所以那这个的成本也是比较大的。那所以这个其实是原先通过语句的一个删除的问题，当然你其实也可以在我要语句后面加一个语句之类的，但是这样其实也很麻烦，你说要去不断的循环的去算数据，那所以有了这些问题之后，我们其实就可以提出我们的想法，我们是不是可以把我们的表空间按照时间分区，然后按照时间分区之后，你每个分区的数据其实就是包含了不同时间范围的数据，但我们知道 Polar- dx 其实是一个分布式的数据库，那它本身就有分区表的这个功能，你可以看那个右下角这张图，这边 p1，P2P 3p4，意思是假设我们有一张 polar-bx 表，它已经被分成了四个分区，按照哈希做，按照ID来做一个哈士分区，那这张表的数据会均匀的分布在这四个分区中。但是但是每个分区中的数据其实是包含了所有时间范围的分区，那这时候我们就想着能不能在垂直方向上去把每个分区都在按照时间做一下拆分。
需求分析
数据按照时间划分：
PolarDB-X 的分区表通常会将数据路由到多个分区(可以理解为水平拆分)
每个分区内数据的新旧程度不同，如果每个分区内的数据还可以再按照时间分区，会有助于管理数据的生命周期。(可以理解为垂直拆分)
低运维成本：
避免删除数据期间影响业务，尽量让业务无感知。提供一系列运维指令帮助管理和审计相关任务。
打通删除和归档：
支持被删除的数据归档到 OSS，并提供一定的查询能力。提升热数据查询效率，减少存储成本。
(下一次直播会进行演示)
然后可以看到这边有一个 state 的一个视力，其实这就是我们 ttl 想做的一件事情，在 dx 的分区表的基础上再叠加一层，按照时间维度的拆分这个裁缝是直接作用到物理表上，这样的话，我们如果要去删掉，比如说一个老的分区的话，其实我们只要对 p1，P2P 3p4 每一个分区都去做一个交互的 partition 的操作，就是把最老的那个分区那直接给job 掉，那我们其实就可以达到一个很快的删除的效果，然后因为它其实是他对于数据库的内部来说，它其实只涉及到一些原数据的操作，所以他并没有真正的发生一些磁盘，等你数据删了之后，他后台线程可以慢慢再把这部分数据给删掉。所以他这个给力的操作是一个比较轻量级的操作，然后这部分老的数据，其实我们有时候也不希望他直接被删掉，所以我们其实还有一个数据归档的功能会能够将你的数据归档到 oss 这样的存储中，并且提供了一定的存储能力，这就是就是刚刚我们我们说到的归档或者删除下一次直播的话会讲到这个 oss 功能，今天的话主要聚焦在这个 tl的功能上，那我们把刚刚那幅图拉近一下，仔细的看一下这一个这一个内部的实现假设嗯后来他除了支持分区表之外，它还支持一个全局二级索引，并且全局二级索引也是也是能够分布在不同的数据节点上的。
所以你全局2级缩影其实也可以看做一个分区表，只不过它的数据是他的数据的行数跟主表是完全一样的，只不过他可能包含的列数比较少，是主表的一个子集，那对于一个主表带一个三的常理来说，它其实就会是一个这样的结构，假设图标有四个分区，那直接有两个分区，那我们就一共有六个分区，然后ttl可以使用t 2表功能的话，你其实可以有几个参数，重要的参数你可以设定，第一个是每个分区的时间的力度是多少，最少是一天或者一个月，一年都行，然后其次就是数据过了多少个周期之后，它会自动的删除掉，也就是这个 Expire of the counter 的意思，这边这边是 expire of 等于六，意思就是过了六个，16个周期之后会删除掉，那这个 pre allocate count 意思是会提前多少个时间周期创建分区，那这边就是三个。那假设现在创建的时候是这样的一个场景，那过了一个时间的周期之后。我们可以看到下面这边其实创建出了第十个分区这样，然后第一个分区它其实已经过期了，他就会删掉或者归的老 os，那它其实本质上其实是一个类似于滑动窗口的一个结构。我们这边是左边需要指定一个过期的时间，时间的时间周期的数量以及提前分配的时间周期的数量，他跟谁相比过的六个周期之后需要删除，那其实就是有这个来定义的，它默认的时间是当前时间，当然如果你业务有需要的话，其实也可以设置成一个过去的时间或者未来的时间，这这边可以是一个表达式。刚刚讲到了为什么我们需要一个具体表的功能，那现在的话就直接带大家来演示一下这个 ttl 表的功能。
