共计 4266 个字符，预计需要花费 11 分钟才能阅读完成。
加入 Hackathon 能够接触到内核、工具、生态各个领域中气味相投的小伙伴，通过他们的我的项目学习到十分好的创意。大家的想法都很微妙，充斥了创新力，在平时的研发过程中，很少能接触到这些，Hackathon 可能帮忙咱们关上思维，让咱们晓得原来 TiDB 还能够这么玩。—— He3 团队
TiDB 在应用过程中，随着用户数据量的持续增长，存储老本在数据库总成本中的占比将会越来越高。如何无效升高数据库存储老本摆在了许多用户背后。
在泛滥解决方案中，有一种办法是将冷热数据实现分层存储。在绝大部分场景中，数据其实都能够分为“冷数据”和“热数据”。数据划分的准则，能够依据工夫远近、热点 / 非热点用户等等。用户通常只拜访一段时间之内的数据，例如近一周或一个月。如果数据不做划分，必然会导致肯定水平上的性能、老本损耗。
在刚刚收官的 TiDB Hackathon 2021 中，He3 团队就抉择了冷热数据分层存储来升高 TiDB 的存储老本。 他们在设计中将热数据寄存在 TiKV 上，将查问和剖析几率比拟少的冷数据寄存到便宜通用的云存储 S3，同时使 S3 存储引擎反对 TiDB 局部算子下推，实现 TiDB 基于 S3 冷数据的剖析查问。我的项目取得了评委的统一好评，力夺本届赛事的一等奖。
这个我的项目为前面 TiDB 与 S3 的整合打下不错的根底，在这次 Hackathon 验证了可行性。它的原理其实很简略，将冷的数据放到 S3，将算子尽量下推到 S3，通过 S3 原生的 select 性能减速查问。当然，如果数据曾经在 S3，还能够通过 Cloud 上其余的服务，譬如 Athena，来做更多的查问聚合操作，减速查问。这次大家都是在通过 partition 做文章，毕竟依据工夫片来分的 partition 是十分罕用的一种操作。咱们外部当初也在通过 LSM 做一些跟 S3 整合的钻研，我还是很期待这些都能在往年看到不少的成绩产出。譬如 TiDB Cloud dev tier 集群就能够齐全用这套机制来验证。
—— 评委唐刘点评
为什么抉择冷热数据分层存储这个方向？
He3 团队的队长薛港，队员时丕显、沈政，都是来自挪动云数据库团队的研发工程师，三人平时的工作就是从事云数据库服务的开发，升高用户在云上应用数据库的老本是他们始终谋求的指标。
在去年 7 月份的 Hacking Camp 中，He3 就曾基于 TiDB 实现了提供 Serverlessdb 服务的 Serverlessdb for HTAP 我的项目。用户在应用 TiDB 时能够按使用量付费，不必再像传统 RDS 须要包年包月，大大 升高了用户应用 TiDB 的老本 。该我的项目也因而取得了 Hacking Camp 优良毕业生和最佳利用奖。
随着产品在挪动云上的落地，很多用户在应用了一段时间后发现随着数据量的减少，存储老本越来越高。薛港解释道，在私有云上，块存储免费比 S3 对象存储要高很多，用户局部场景的数据其实很多是冷数据，齐全能够寄存在 S3 上。于是在去年 12 月份时，他们就开始思考如何升高 TiDB 的存储老本。恰好这时 TiDB Hackathon 2021 启动了，薛港和时丕显、沈政一磋商，就决定将冷热数据分层存储作为往年的比赛项目。在问难时，他们专门用了一页 PPT 剖析了使用该我的项目后的老本变动：
我的项目方向定了，接下来就该报名了。队长薛港在看电视的时候对氦 -3 这种元素产生了趣味，通过理解，发现它能够用作核聚变燃料，比现有的核燃料能量更大，并且只有很少的放射性，是一种清洁高效平安的发电燃料。这种个性和他们对分布式云数据库的冀望完全一致 —— 平安、高性能、易用、价格便宜，于是 He3 便成了队名。
在接下来不到一个月的工夫中，薛港作为队长负责整体需要的确认、架构设计、计划验证以及具体框架的开发。其余队员次要负责性能开发，时丕显负责算子下推与数据类型反对，沈政重点在性能优化以及 TPC-H 测试。
该我的项目解决了什么问题？
He3 开发的 TiDB 冷热数据分层存储我的项目，可能以极简的形式实现冷热数据拆散：
针对一般表： 实现 insert into select 的形式实现冷热数据拆散：
- 反对创立 S3 内部表；
- 反对通过 insert into s3_table select from tikv_table where …，把 TiKV 外部表的数据转储到 S3 对象存储上；
- 反对通过 insert into tikv_table select from s3_table where …，把 S3 内部表的数据转储到 TiKV 外部表。
针对分区表： 主动实现分片表转化成 S3 内部表，保留主表和 S3 内部表的主从关系。
反对通过 Alter 分区表操作，把 TiKV 外部分区表的数据主动转储到对应的 S3 内部表中，主动实现以下几件事：
- 外部 TiKV 分区表数据转存到 S3 对象存储中；
- 更改分区表元数据，把 TiKV 外部分区表转化成 S3 内部表，外围要点保留 S3 内部表和主表的分区关系；
- 删除 TiKV 外部分区表数据。
转换后 S3 内部分区表对用户齐全通明，对用户来说，S3 内部表就是主表的一个分片表。例如针对主表的查问后果蕴含局部 TiKV 外部分片表以及局部 S3 内部表对应的分片表数据，那么返回的后果就会来自两局部：TiKV 外部分片表，以及 S3 内部表。
保障用户应用 S3 内部表和 TiKV 外部表没有任何区别：
- S3 内部表反对所有的数据类型；
- S3 内部表反对所有的算子；
- 优化 S3 内部表操作性能在用户可承受的范畴内。
通过反对谓词 (逻辑运算、比拟运算、数值运算），聚合函数、Limit 等算子下推到 S3 节点，利用 S3 的计算能力晋升查问性能。
为了达到冀望所有成果，He3 在此次 Hackathon 中开发批改了 TiDB 一些模块：
SQL Parser 模块、零碎表模块
- 减少一个新的零碎表，用于保留 S3 元数据，每一条记录对应一个 S3 存储元数据：蕴含 S3 的 endpoint, access key, secret key，s3 bucket。insert into mysql.serverobject values(“s3object”,”http://192.168.117.220:9000″,”minioadmin”, “minioadmin”,”s3bucket”)；
- 反对创立内部表，相比一般表减少了 s3option 选型，对应 S3 元数据对象，内部表对应 S3 的存储门路：Bucketname/DBName/TableName create table s3_table(id1 int8,id2 char(30)) s3options s3object；
- 反对分片表主动转换成 S3 内部表
Alter table employees alter partition employees_01 s3options s3object
执行器模块
- 可能辨别操作表是否是 S3 内部表，如果是内部表，写入时，数据以 256M 为粒度保留到 S3 的一个对象中 , 当查问 S3 内部表时，S3 对象会被以流式的形式拆卸到 chunk 中，以反对下层算子操作；
- 反对算子下推到 S3 节点，利用 S3 节点的计算能力减速 S3 内部表的性能；
- S3 内部表反对所有的数据类型，存储在 S3 的数据按 S3 内部表的 schema 对应的数据类型保留到 chunk 里，相干列都会基于数据类型编码；
- 反对 Alter 实现外部分片表数据主动转储到 S3 内部表中，同时保留主表和 S3 内部表的主从关系不变。
优化器模块
大量无奈下推 S3 的算子，He3 批改了优化器阻止这部分算子下推。以后不反对的算子，次要就是蕴含 TopN 算子。
来自性能测试的挑战
He3 最后设定的指标有两个：一是心愿数据可能以比较简单的形式间接实现冷热数据拆散；二是心愿冷数据拆散到 S3 后，它的查问性能可能在正当的工夫范畴内。所以一开始就把跑通 TPC-H 作为指标。
我的项目的冷热数据拆散性能很快就实现了开发，然而接下来他们遇到了一个最大的问题——性能总是无奈达标。一开始的方案设计是将全副数据都读取到 TiDB 上集中处理，但在测试中发现即便只有 10GB 的数据，TPC-H 也跑不进去。三名队员通过探讨、调研、剖析，发现 S3 其实也具备肯定的计算能力，是否能够把局部计算下推到 S3，让 S3 和 TiKV 一样可能承载局部计算？
扭转计划后通过几个场景算子下推，He3 发现性能晋升非常明显，在之后的开发中就将能下推的算子全副下推，我的项目的整个性能优化每天都会以 20% 的幅度在晋升。最终在较量日上，他们跑通了整个 TPC-H 测试。
He3 在 Hackathon 中的 TPC-H 测试问题
此次 Hackathon 中，其实还有另一支赛队 Interstellar 也抉择了分层存储，这也给 He3 队员们留下了一个乏味的画面：在 Interstellar 开始问难时，He3 认为是本人在投屏，慌手慌脚地到处找敞开投屏按钮，直到对方开始问难了，他们才意识到原来是两个队伍的题目撞衫了。
本次参赛的心路历程
He3 队员们其实在去年也加入了 TiDB Hackathon，因为刚接触 TiDB，并没有碰内核。过后心中就埋下一个想法，下次参赛肯定要做够硬的我的项目。这也是薛港在毕业后就给本人建立的指标 —— 做数据库内核 ，并认为这是一件很酷的事件。于是在往年较量中，He3 抉择了最硬核的赛道 —— 内核组。
过来一年的工作对他们帮忙十分大，因为三人平时的工作和 TiDB 联合十分多，在碰到问题的时候就会去想有什么解决方案，这个过程中很容易产生各种好的 idea。例如这次如何升高 TiDB 存储老本的问题，他们过后就想出了至多三种计划：第一种是将 TiDB 底层的编码方式做一些扭转，让 TiDB 的整个压缩比可能再降落 50% – 60%；第二种也是一种冷热数据拆散计划，将 LSM-tree 和 S3 集成；第三种就是当初的冷热数据存储分层计划。但前两种计划在 Hackathon 如此短的周期内很难实现，于是他们就采纳了第三种计划。
将来，He3 还会从三个方向将该我的项目继续演进、迭代：
- 通过新的编码方式以及减速算法，升高数据在 S3 的存储容量，基于本次较量中实现的成果再升高 50% 的存储容量；
- 继续优化 TiDB 对接 S3 的存储差别性能，在这次较量的前期，这块性能每天都有 20% 的性能晋升，He3 认为这里其实还有很大的晋升空间；
- 进一步简化用户的冷热数据拆散形式。对这次我的项目的最终实现，He3 其实还有一些遗憾，一开始设计的时候他们想过当初冷热数据拆散还须要 DBA 来做一些操作，如果能将这个工作进一步实现自动化操作，就能够让冷热数据拆散应用性再上一个台阶，不过因为工夫比拟无限的起因没能实现。
此外，除了我的项目自身持续欠缺外，He3 还心愿在迭代到肯定水平后就将整个产品的代码提交给社区，用开源的形式回馈社区，大家一起共创。
