共计 3843 个字符，预计需要花费 10 分钟才能阅读完成。
简介：PolarDB-X 是一款计算存储拆散的云原生分布式数据库，在 PolarDB-X 2.0 的 AUTO 模式下，数据库会依照表的主键主动 Hash 分区，将数据平均的散布到各个数据节点中，最现实的状况是各分区间数据和流量都是平衡的，能充分发挥出多节点的分布式解决能力。为了达到最现实的成果，就要求数据库尽量避免呈现热点分区，包含流量的热点和数据量的热点。防止热点的呈现，首先就须要疾速便捷地发现热点分区，从而能进行针对性的解决，因而疾速精确地找出热点分区就成为分布式数据库所需的一项重要能力。
背景
PolarDB- X 是一款计算存储拆散的分布式数据库，分布式的解决能力是 PolarDB- X 的外围个性之一，单个数据库实例的多个计算节点会均摊全副的 SQL 流量，这样就能够通过节点的扩缩容来疾速满足不同的流量峰值场景。
在 PolarDB-X 1.0 时代，用户经常应用分库分表的形式对库表进行拆分从而达到数据和流量在多个节点间平衡，该模式下拆分键的抉择对数据库的性能体现起关键性的作用，要选出最佳的拆分键组合就要求用户在建表初就对业务库的库表构造和数据分布十分相熟。
为了帮忙用户升高应用分布式数据库的技术门槛，PolarDB-X 2.0 时代引入了通明分布式的理念，用户无需再逐个指定拆分键，应用分布式数据库就像应用单机 MySQL 一样简略，同样也能享有分布式数据库的优异个性。这既是用户体验上的一次降级，也是技术架构和理念的一次飞跃，从中间件模式进化到云原生架构，数据库不再是须要用户费神保护的高级技术组件，而是一种随用随得的云服务，让用户能够充沛享受云架构带来的技术红利。
在 PolarDB-X 2.0 的 AUTO 模式下，数据库会依照表的主键主动 Hash 分区，将数据平均的散布到各个数据节点中，最现实的状况就是各分区间数据和流量都是平衡的，能充分发挥出多节点的分布式解决能力。为了达到最现实的成果，就要求数据库尽量避免呈现热点分区，包含流量的热点和数据量的热点。防止热点的呈现，首先就须要能疾速便捷地发现热点分区，从而能进行针对性的解决。因而疾速精确地找出热点分区就成为 PolarDB-X2.0 所需的一项重要能力。
成果展现
性能概览
首先选取一个小范畴数据做介绍，如下图，纵轴示意了逻辑库、逻辑表、逻辑分区间的关系，并且分区依照逻辑序号进行排序，横轴示意工夫，图像下方和右方的柱形图示意了汇总数据，下方柱形图示意纵向的求和，即某时刻所有分区的访问量的求和，右方的柱形图示意横向的求和，即某分区所有工夫范畴内的访问量求和。
存储节点视角
如何想查看存储节点视角的热点状况，能够点击上方“DN View”按钮切换到存储节点视角，数据会依照不同的存储节点进行分类，能够不便剖析出数据在物理存储节点间是否平衡，是否存在物理存储节点的热点。
TPC- C 热点剖析
用 TPC- C 流量进行测试，能够看到一个残缺的热力散布状况，从图中能够显著发现 TPC- C 的流量存在两块热点区域，并且通过纵轴的宽度比照也能发现数据量的热点。
设计考量
1. 展示形式尽可能简洁易懂
热点数据具备多种维度耦合的特点：数据量、访问量、工夫、各分区间的关系、逻辑库表和分区间的关系、物理节点和逻辑库表间的关系、热分区和冷分区的区别，这些剖析所必须的要害因素间互相耦合，缺一不可。要将简单的信息整顿清晰，给用户一个很清晰简洁的出现。
2. 防止影响数据库外围性能
要精确找出热点分区，就必须对数据库的数据量和申请量进行采集，流量和数据量是继续变动的，因而采集的过程也须要是继续的，这就更加要求信息采集的过程不能对数据库的外围性能造成负面影响。
3. 实现链路缩小对外部组件的依赖
随着 PolarDB- X 产品的倒退，衍生出了多种部署状态，有阿里云上部署的私有云版本、有面向线下 PoC 场景部署的 K8s 版本、还有面向用户公有环境轻量化部署的 DBStack 版本，还有奉献给社区的开源版本等等，为了尽可能让更多的版本领有等同能力，应用的内部组件须要尽可能的少，这样多状态部署时面临的兼容性问题才会起码。
4. 管制采集数据量
因为流量数据的采集是一个继续的过程，实践上就会产生无穷无尽的统计数据，因而必须要限度统计数据的大小，要有数据时效范畴，否则无穷大的数据无奈存储。数据量尽可能的小也能缩小数据传输过程中的 IO 和网络压力，缩小对内核外围性能的影响。
设计方案
交互方式
通过在多种类型图表间比照，以及和业界其余相干解决方案的比照，最终抉择用“热力求”这个模式来展现分区热度信息，横轴表白工夫，纵轴则表白分区，用对应矩形的色彩明暗来示意拜访热度的高下。一眼看去，最亮堂的矩形就是热度最高的分区。
热力求能够很好表白访问量的热点，那么如何展现数据量的热点呢？咱们创新性的利用了纵轴做文章，纵轴每个分区的高度都是相等的，然而宽度能够不相等，数据量越大的分区，宽度就越宽，这样一来，通过宽度的比拟一眼就能发现数据量最大的分区。
有了以上两个展示的基本要素，再增加上一些动画：缩放、拖拽、色彩调整、hover 等其余交互成果，就能很清晰残缺的表白热点分区的信息了。
数据处理
时间轴的解决
依据热力求的展现特点，数据采集的频率定在 1 分钟 / 次，采集的统计数据最多保留 7 天，估算下来热力求的横轴最多会有 7 * 24 60 = 10080 个点，数据依照工夫来存储就须要 10080 行数据。然而，浏览器展现的网页宽度通常在 1000px 单位左右，如果用户要看 7 天的全量数据，那么 1px 单位的宽度里就须要塞进 10 个时间轴，这种展现成果就会大打折扣了。因而必须对时间轴的数据进行解决，缩小时间轴的标识密度，然而又不能失落数据。
要缩小时间轴的数量，很容易想到的计划就是升高采样精度，比方把采集频率改为 30 分钟 / 次，然而如果用户只看 1 小时内的数据，那页面就剩下 2 个工夫点了，显然也是不能承受的。这样升高采样频率就会呈现一个矛盾点：小时间段范畴的显示精度要求和大时间段的显示成果要求间的矛盾。
因而，最终抉择对时间轴进行分级解决，远工夫范畴的数据升高精度，近工夫范畴的数据保留高精度，这样也合乎大部分用户的应用习惯，最近的数据看得更具体。采集精度改为最近 1 小时内数据 1 分钟 / 次，第 1～8 小时内数据 2 分钟 / 次，第 8～24 小时内数据 6 分钟 / 次，第 24 小时～7 天内数据 30 分钟 / 次。这样时间轴最大数量就从 100080 缩小到了 60 + 210 + 160 + 288 = 718 个。
因而采纳的数据结构如下图，多层环形队列，每一层从队尾插入新数据，从队头挑选出要指定的数据进行合并后插入下一层的队尾，而后从队头删除已合并的数据。每个环都有指定大小，当环满时向下合并数据，最初一层环满时间接抛弃数据。
分区轴的解决
热度统计数据的定时采集过程为了防止内部组件的依赖，因而利用了内核的调度器，在主计算节点每分钟发动一次采集工作，工作下推到各个存储节点获取原始数据，最终在主计算节点上解决。由此可见，采集过程的性能耗费和分区数量有很大关系，当分区数量少时，简直无性能耗费，然而当分区数量特地多时，各个存储节点就会返回大量数据汇总到主计算节点，计算节点须要解析和排序，就会造成很大的内存和 CPU 压力。
因而，采集的分区数量必须要放弃在肯定的界线范畴内，须要在保障热点诊断性能可用的同时又不影响数据库内核的性能。依据视觉效果和数据大小的理论状况计算发现，展现的分区数管制在 1600 以内会达到最佳的成果，默认单张表 16 个分区的状况下能够反对 100 张表的热点剖析，能够满足大部分的利用场景。
分区表个数超多的状况也是会理论存在的，因而咱们设计了将分区数超过 1600 且小于 8000 的状况，能够对分区统计信息进行合并，升高分区精度来反对分区数超大状况的热点剖析，实践上曾经能够反对 1000 张表的热点剖析了。
对于数万或者数十万张表的状况，无论是信息的采集过程还是前端展现都会对内核和性能链路造成较大的资源压力，因而对于极其状况，默认不进行热点数据的采集，然而反对用户动静批改数据库参数，来指定须要进行热点剖析的库表，指定剖析范畴按需剖析。
综上，对小规模分区准确展现、中等规模分区升高精度显示、超大规模分区可指定范畴显示，笼罩了多种不同的用户需要。
性能剖析
为了测验热点剖析性能对数据库内核性能的影响，进行了几组 TPC- C 的比照试验，论断是该性能对内核的性能影响极小。在将 PolarDB-X 内核的 CPU 压力压到最大的状况，别离测试开启该性能和页面刷新继续获取诊断后果的极其条件下，对性能的影响管制在 1% 左右稳定，思考到测试过程的失常统计误差，能够认为该性能对内核性能影响极小。
性能彩蛋
当用户没有建任何分区表时，页面没有数据可供显示，惯例思路是前端显示一行文字“暂无数据”来揭示用户，这就让用户无奈体验到该性能的乐趣。为了让用户在没有数据时也能提前体验到热点剖析性能的高兴，PolarDB- X 对空白页“搞事件”，联合热力剖析性能的前端特色，绘制出“NO DATA”的图像，让用户没有数据时也能同样体验到热点剖析性能。
当用户的分区数量超出显示下限时，会绘制出“TOO BIG”的图像进行提醒。
热力剖析性能除了上述“支流”用法之外，开动你的小脑袋，施展你的想象力，还能整出各种“非主流”用法，比方咱们能够利用热力图像的色彩特点，准确管制分区访问量，整出一个“爱心”的热力图像，你将成为世界上第一个用数据库表白胜利的地球人！
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。
