简介: 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”的图像进行提示。

热力分析功能除了上述“主流”用法之外,开动你的小脑袋,发挥你的想象力,还能整出各种“非主流”用法,比如我们可以利用热力图像的颜色特点,精确控制分区访问量,整出一个“爱心”的热力图像,你将成为世界上第一个用数据库表白成功的地球人!

本文为阿里云原创内容,未经允许不得转载。

PolarDB-X 如何做分布式数据库热点分析的更多相关文章

  1. 分布式ID系列(3)——数据库自增ID机制适合做分布式ID吗

    数据库自增ID机制原理介绍 在分布式里面,数据库的自增ID机制的主要原理是:数据库自增ID和mysql数据库的replace_into()函数实现的.这里的replace数据库自增ID和mysql数据 ...

  2. DTCC 2020 | 阿里云李飞飞:云原生分布式数据库与数据仓库系统点亮数据上云之路

    简介: 数据库将面临怎样的变革?云原生数据库与数据仓库有哪些独特优势?在日前的 DTCC 2020大会上,阿里巴巴集团副总裁.阿里云数据库产品事业部总裁.ACM杰出科学家李飞飞就<云原生分布式数 ...

  3. 开源分布式数据库中间件MyCat源码分析系列

    MyCat是当下很火的开源分布式数据库中间件,特意花费了一些精力研究其实现方式与内部机制,在此针对某些较为重要的源码进行粗浅的分析,希望与感兴趣的朋友交流探讨. 本源码分析系列主要针对代码实现,配置. ...

  4. erlang 分布式数据库Mnesia 实现及应用

    先推荐一篇:mnesia源码分析(yufeng)   - linear hash   ETS/DETS/mnesia 都使用了linear hash算法 http://en.wikipedia.org ...

  5. 分布式数据库中的Paxos 算法

    分布式数据库中的Paxos 算法 http://baike.baidu.com/link?url=ChmfvtXRZQl7X1VmRU6ypsmZ4b4MbQX1pelw_VenRLnFpq7rMvY ...

  6. 云时代的分布式数据库:阿里分布式数据库服务DRDS

    发表于2015-07-15 21:47| 10943次阅读| 来源<程序员>杂志| 27 条评论| 作者王晶昱 <程序员>杂志数据库DRDS分布式沈询 摘要:伴随着系统性能.成 ...

  7. SQL Server分布式数据库技术(LinkedServer,CT,SSB)

    SQL Server自定义业务功能的数据同步 在不同业务需求的驱动下,数据库的模块化拆分将会面临一些比较特殊的业务逻辑处理需求.例如,在数据库层面的数据同步需求.同步过程中,可能会有一些比较复杂的业务 ...

  8. 怎样打造一个分布式数据库——rocksDB, raft, mvcc,本质上是为了解决跨数据中心的复制

    摘自:http://www.infoq.com/cn/articles/how-to-build-a-distributed-database?utm_campaign=rightbar_v2& ...

  9. Amoeba:开源的分布式数据库Porxy解决方案

    http://www.biaodianfu.com/amoeba.html 什么是Amoeba? Amoeba(变形虫)项目,该开源框架于2008年 开始发布一款 Amoeba for Mysql软件 ...

  10. Cobar分布式数据库的应用与实践

    最新文章:看我如何快速学习.Net(高可用数据采集平台).高并发数据采集的架构应用(Redis的应用) 问题点: 随着项目的增长,数据和数据表也成倍的增长,普通的单点数据库已经无法满足日常的增长的需要 ...

随机推荐

  1. day01-项目介绍和功能实现

    项目练习01 1.项目介绍 这是一个简单的项目练习,用于掌握新学习的SpringBoot技术. 项目操作界面 ● 技术栈 Vue3+ElementPlus+Axios+MyBatisPlus+Spri ...

  2. Wireshark在多媒体开发中的使用

    一 概要: Wireshark(前称Ethereal)是一个网络抓包工具. 是一款非常棒的Unix和Windows上的开源 网络协议分析器.尽可能显示出最为详细的网络封包资料.Wireshark使用W ...

  3. Vite+TS项目:论如何便捷的使用pinia

    这里给大家分享我在网上学习总结出来的一些知识,希望对大家有所帮助 pinia 介绍 vue新一代状态管理库,相当于vuex 特性 1.像定义components一样定义store 2.支持ts 3.去 ...

  4. 记录--什么时候会阻塞HTML文档渲染过程?

    这里给大家分享我在网上总结出来的一些知识,希望对大家有所帮助 HTML页面加载过程会发生什么?因为浏览器网络拉取资源是多线程的,但是dom树的操作都是在一个线程中的,所以网页资源的解析.js加载.do ...

  5. axios中设置了response:blol后,如何处理json对象

    axios中文件下载 上传文件后台校验,若失败则下载文件 let loading = this.$common.loading("正在上传"); let form = new Fo ...

  6. KingbaseES V8R6集群运维案例之---访问系统表unrecognized token- false故障

    KingbaseES V8R6集群运维案例之---访问系统表'unrecognized token: "false"'故障 案例说明: KingbaseES V8R6集群在升级补丁 ...

  7. KingbaseES 配置root.sh实现数据库服务开机自启动

    案例说明: KingbaseES数据库在部署完成后,支持数据库服务开机自启动,部署完成后,root用户(Linux)执行安装软件目录下的root.sh脚本后,可以实现数据库服务开机自启动. 适用版本: ...

  8. KingbaseES Insert On Conflict 功能

    针对数据写入时有主键冲突的情况,INSERT ON CONFLICT语法可以将冲突主键的INSERT行为转换为UPDATE行为,从而实现冲突主键的覆盖写入.该特性又称UPSERT覆盖写,与MySQL的 ...

  9. #分块,可撤销并查集#洛谷 5443 [APIO2019]桥梁

    题目 分析 最直接的做法就是在线一边修改边权,询问直接全部重排, 然后用可撤销并查集维护连通块大小,这样时间复杂度为 \(O(qm)\) 同样尽量让大部分的边不需要修改边权,那么每 \(B\) 个操作 ...

  10. Jetty的server模块

    启用server模块,执行如下命令: java -jar $JETTY_HOME/start.jar --add-modules=server 命令的输出,如下: INFO : server init ...