腾讯云数据库技术实践精选集 2022年版
腾讯云技术实践精选集腾讯云技术实践精选集 版权声明 本册精选集版权属于腾讯云计算（北京）有限责任公司和InfoQ极客传媒，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明“来源：腾讯云计算（北京）有限责任公司和InfoQ极客传媒”。违反上述声明者，将追究其相关法律责任。 参与编写单位及人员 内容指导 徐樱丹刘颖 内容策划 刘亚琼周璐璐温晓桦扶婕 专家顾问 王义成贾瓅园唐彦刘少蓉伍鑫潘安群 作者（按拼音首字母） 张倩 王鲁俊 潘怡飞 唐彦 卢卫 刘家文 窦贤明 孟庆钟 陈育兴 丁艳飞 孙勇福 杨亚洲 陈昊 王宇庭 田清波 贾瓅园 韩硕 汪泗龙 韩锋 孙亮 彭涛 南云鹏 刘畅 雷海林 刘迪 伍旭飞 孙旭 刘生洲 顾雅各 余成真 胡锦前 杨珏吉 王宏博 胡翔 谢灿扬 朱阅岸 内容编辑 任传英 卷首语 过去数年间，在云计算发展和国产化趋势的双重驱动下，国产数据库呈现出百花齐放、齐头并进的新格局。回望2022年，国产化替代进程加速，国产数据库投产的广度和深度持续增加。从广度来看，一方面，给国产数据库产品和服务能力带来了更大的挑战；另一方面，也给诸多数据库厂商提供了广阔的机会；从深度来看，数据库开始大规模落地于银行、证券、保险等金融企业的核心业务系统。 在数据库竞争与变化的新格局中，腾讯云作为数据库领域的前沿探索者，其自研数据库的历史可以追溯到2006年。历经数十年的磨砺，腾讯云在数据库核心层自研、生态工具打造，以及数据库在不同场景下的落地解决方案等方面，积累了足够多的经验，并持续向业界输送。 在过去一年中，来自腾讯云的技术专家，通过DBTalk技术公开课、QCon全球软件开发大会、ArchSummit全球架构师峰会以及DIVE全球基础软件创新大会，分享了腾讯云数据库的技术探索与不同场景下的落地实践。《腾讯云数据库技术实践精选集》2022版，收录了全年40余场分享的内容，也涵盖了优秀企业数据库应用的成功案例，相信一定能给数据库领域的各位同仁带去一些思考和启发。 展望未来，国产数据库的“进化”之路仍任重道远，愿与君携手，百尺竿头，更进一步！ 腾讯云技术实践精选集 目录 腾讯云技术实践精选集 扫码关注腾讯云数据库公众号 回复关键词【精选集】，即可获取嘉宾演讲PPT回复关键词【DBTalk】，即可获取DBTalk系列视频 第1章：数据库架构设计 CDWPG大规模在线数仓技术构架分享 腾讯云原生数据库TDSQL-C架构探索和实践腾讯云数据库云上SaaS生态演进 基于LSM-Tree的分布式组件化KV存储系统 探索分布式数据库的多级一致性及构建技术演进之路敏态扩展，灵活应变！TDSQL新引擎TDStore技术探索Redis如何实现多可用区？ 新一代云原生数据库畅想 基于压缩数据直接计算技术，定义新型数据库处理 第2章：数据库性能优化 数据库事务一致性实现上的各种细节，你注意到了吗？还在为数据库事务一致性检测而苦恼？让Elle帮帮你向量化执行从理论到实现，仅需五步！ 节省30%磁盘空间的同时如何保障数据安全？一些有趣的B+树优化实验 基于LSM-Tree存储的数据库性能改进 面向个性化需求的在线云数据库混合调优系统 第3章：数据库运维管理 云原生数据库管控探索和实践 腾讯云MongoDB智能诊断及性能优化实践数据库纳管平台DBhouse的技术路线与实践从0到1实现智能化运维 2 8 13 19 38 50 70 82 95 101 116 131 147 159 172 195 203 208 221 229 第1章：数据库架构设计 1 数据库架构设计 第1章 金融级分布式数据库架构设计与对接实践 国产金融级分布式数据库在金融核心场景的探索实践 金融级分布式数据库TDSQL升级版引擎架构和关键技术介绍深度解析金融级分布式数据库一致性技术 金融业数据库选型之路 金融应用对分布式数据库的诉求 银行核心业务系统数据库主机下移架构与实践分布式数据库在金融场景下的实战 TDSQL破局敏态业务背后的技术演进TDSQL在TP领域的技术探索和实践 新一代云原生数据库TDSQL-C关键技术突破KeewiDB轻TP技术实践 只有时代的Oracle,没有Oracle的时代-看国产数据库如何突出重围！得物数据库中间件平台“彩虹桥”架构演进及落地实践 云原生下缓存架构如何演变？ 在敏态业务场景中，微盟数据库的应用实践之路50W+小程序开发者背后的数据库降本增效实践TDSQL-PG数据库在微信支付的应用实践 如何像用自来水一样使用数据库？ HTAP数据库存储引擎技术演进 如何利用资源管理技术，让HTAP负载同时运行HTAP数据库最佳实践 HTAP系统的问题与主义之争 238 248 256 263 285 291 298 308 318 329 339 348 355 367 377 386 392 399 406 417 429 436 445 CDWPG大规模在线数仓技术构架分享 张倩 腾讯云数据库专家工程师 腾讯云数据库专家工程师，中国人民大学博士，具备多年数据库内核研发经验，曾在Teradata天睿公司以及华为公司高斯实验室工作多年。加入腾讯后，负责CDWPG数据仓库内核优化器、执行器等多项核心功能研发。 腾讯云数仓产品CDWPG是一款面向超大规模集群海量数据分析的在线数仓。通过创新的数据转发平面、全自研列式存储、分布式延迟物化技术，以及向量化执行引擎等核心技术为用户带来极致的数据分析体验，可以真正将海量数据所蕴藏的价值释放出来。ArchSummit2022北京站上，腾讯云数据库专家工程师张倩带来题为《CDWPG大规模在线数仓技术构架分享》的分享，主要聚焦CDWPG在构架设计以及核心优化上面的一些经验和思路。 CDWPG发展历程介绍 CDWPG是腾讯基于PostgreSQL自主研发的分布式在线关系型数据仓库。PostgreSQL是一个单机版数据库，我们在这个基础上开发了一个无共享MPP架构，支持行列混合存储，同时支持超大规模集群，目前集群规模可以支撑到上千节点，同时可以支撑超高速的计算能力。 整体架构演进 大规模集群面临的一大挑战是集群扩展性挑战，分布式JOIN消耗大量网络连接和对应资源。对于分布式JOIN，数据是分布在不同节点上的，数据的分布键和分布式JOIN的键并不是 CDWPG的整体架构如上图所示。 完全一致，这时数据需要重分布，重分布之后再进行JOIN连接才能得到最后结果。数据的重分布通过DN节点，把本DN自身的数据通过模块连接发送到对应的其他DN上。如果DN节点非常多，每个DN都要和JOIN建连，则一个数据重分布就会有很多连接。假如有200个DN节点，有100个并发查询，如果每个查询5个重分布，这种情况下可以计算出10万个连接。每个连接在每个节点上对应一个进程，对服务器的压力非常大，也是限制分布式数据库拓展性的问题之一。 原来的集群架构显然不适合大规模集群，所以我们在这个基础上开发了异步执行框架，一个新型的分布式架构。在这个架构里，我们会在查询优化阶段分析物理查询计划，统一创建DN上的各层执行进程，各层执行进程之间不需要建立直接连接，不同层级进程可以异步启动执行。假设我们有N个节点，就会产生N个进程数，这是进程数上的优化。 我们在连接数上会进一步引入FN，FN来负责节点间的数据交互。每台物理机只需要布置一个FN节点，FN节点会负责本台物理机和其他集群内其他物理机的数据交换。在本机节点上，这个FN与CN和DN之间是通过共享来进行数据交互的，本机和其他的物理机进行数据交互的时候是通过网络进行。在这样的分布式架构下，假设有N个节点，不管JOIN有多么复杂，查询可以有十几个JOIN，它们只有N*（N-1）个连接数。 在优化器阶段会查询计划分片。优化器是根据代价来审核的最优计划。在单机上的代价是一些算子，每个算子有不同的代价；但在分布式的情况下，数据重分布也有自己的代价。优化器会生成代价最优的计划，在分布式的计划里可以看到，RemoteSubplan会有数据重分布节点，数据重分布节点会把下层执行的数据按照一定规则进行数据重分布，生成分布式的计划之后会变成整个执行计划，对这个计划进行分片。分片的原理很简单，我们对每个数据分布节点下面的Log节点作为一个组数，划分成一个分片，把分片用FID编号。每个分片除了Remote Subplan节点，下面的计算都可以在本地完成。本地完成之后再通过RemoteSubplan节点把数据发送出去，串联起整个分布式的计算。生成这样一个分布式计划之后，会下发这个计划分片到对应的执行进程上，每个分片会在每个执行节点上创建一个进程来执行对应的计划片段。 在这个JOIN里会分成两个FN片，会有FID1和FID2，FID2对数据重分布，然后再跟FID1做一个JOIN，这样两个计划分片在DN片会有4个进程。这4个进程，每个进程会负责执行自己收到的进程，然后把数据通过RemoteSubplan节点，不会直接建连，而是把数据发送给本机的FN，FN负责把数据转发。不同层级之间的进程是异步启动执行的，下面的分片和下面的分片是同时启动执行的，通过FN进行数字交互。 自研列式存储 我们自研的列式存储支持按照行存储和列存储建表，列表和行表之间可以相互操作，行列表之间的混合查询保证事务一致性。很多查询都是点查询或者是只会操作比较少量的数据，在这种情况下，我们点查每次只出一行数据，在这个行数里面可以获取这一行数据进行处理。但是在AP场景中，对于宽表来说它的列会非常多，每次用户操作的时候只操作其中几列，比如说只查名字或者只查名字和部门，或者只查名字和年龄，后面的几百上千列都不会管。如果还按行存储就会浪费很多IO。后面的列数都是我们需要的，每一列单独存储，多个列逻辑上组成一行，一次的磁盘IO只包含一列数据。这种情况下，因为这一个数据文件只存储单列的数据，它的数字类型都是固定的，很方便做数字压缩，也能够提供比较高的数字压缩效果。在我们的数据库里支持行列存储，既可以在行存表和列存表，可以同时互相操作，也可以查询复杂的操作，行列表之间的混合查询能够保证数据的一致性。 分布式集群里一个比较难的问题是保证分布式数字一致性。我们是基于Timestamp的分布式提交协议。我们会有一个GTS集群，GTS集群包括GTS组和GTS位。GTS集群是提供给数据控制节点，它是从内部开始，内部单向并且唯一由GTS维护，由硬件来保证使用源的稳定度。在这个情况下，加上数据库内部的MVCC的存储能力（MVCC是整个并发控制的基础），这两个结合起来提供了分布式事务的一致性。GTM单点可靠性是由GTM主备来支持的，也就是说主节点可以通过对外提供服务来保证分布式事务的一致性，然后主备之间是通过日志簿时间戳的状态来保证GTS的可靠性。对于单点可靠性，数据库里面如果是非常繁忙的业务，TS85服务器每秒能够处理1200万的GTS，可以满足绝大部分业务团队的需求。 上图介绍了我们自研的列式存储，主要包含两部分。第一部分是左边的表，会有一些信息，有C1文件和C2文件，每个文件里面的数据是按照Silo来仓储的，对应的Silo信息会存储在这个表里，同时Silo的输出上，事务的信息也是通过这个表来保证的。 在这样的基础上，可以看到这种数据结构比较适合大批量的数据导入，也就是说我们在做大批量数据插入的时候很快会填满，再写入下一个Silo，内存的效率最高。但是在很多业务场 景中，这个场景并不是很单一，也有可能除了大批量的数据插入之外，还有一些小数据量的操作。这种情况下如果我们还用Silo来存储就会显得效率比较低。为此我们开发了一个Stash表，它是一个行情表，主要目的是在用户进行小数据量操作的时候，这些数据都会进入到Stash表里，提供一个像行存一样的性能和访问能力。在后台我们会有一个StashMerge操作，会定期Merge。数据积累到一定程度，我们有了整个Silo的数据，就会把它生成一个Silo，从而获得批量性能提
