云原生分布式数据库PolarDB-X(二)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 云原生分布式数据库PolarDB-X(二)

开发者学习笔记【阿里云云数据库助理工程师(ACA)认证云原生分布式数据库PolarDB-X(二)

课程地址:https://edu.aliyun.com/course/3112080/lesson/19088

云原生分布式数据库PolarDB-X(二)

三、云原生分布式数据库PolarDB-X应用实践


了解完架构之后,作为一款分布式数据库,它的常见的应用场景都有哪些以及它的用户案例。

1. 典型业务场景~单机平滑演进分布式

 图片8.png

核心技术

基于分布式的数据拆分和Online DDL,优化单机的大表和DDL引入拆分变更DDL、全局binlog回流单机,确保分布式可上可下

MySQL大表问题(建议大表控制在500万~5000万)

1.B+树深度(行大小为0.5KB+自增主键,3层B+树大约支持4千万记录)

2.业务并发度,会因为B+树深度过深导致分裂的代价偏大

3. MySQL原生Online DDL执行代价过大,会导致主备复制延迟

4.复杂查询性能不友好,MySQL原生为迭代执行效率慢

5.历史数据归档不友好,optimize table回收空间


首先第一个典型场景,作为大号的MYSQL数据库,提供的是单机的平滑演进分布式的能力,这里面的核心技术主要包括了基于分布式的数据拆分和online DDL在线的DDL变更,以及优化单机大表和DDL的能力。


引入的拆分变更的DDL可以支撑业务按需调整它的分布键,同时还提供了基于全局的blog以及刚才的日志节点的能力来回流到单击,确保的分布式可上可下,这里面主要强调的一点是什么样的场景下是必须或者是建议迁移到分布式上面来,基于MYSQL整个引擎的特点,它对大表的处理有以下的一些瓶颈,一般的建议大表控制在500到五千万行之间。


首先,第一个基于B+树的个数据结构,一般的层数,一般B+树的能承载的层数大概在三层四千万条记录左右。随着业务的并发度,或者是因为B数的索引深度过深,会导致架构的分裂代价偏大,性能会有一个断崖式的下降,MYSQL原生的online DDL在执行的过程中,由于大表的原因,会导致主从复制的延迟变得非常的慢,这样对业务会造成一定的可靠性的影响。


同时对于复杂的查询并不友好,MYSQL原生的迭代执行效率也会变慢。对于历史归档数据也非常的不友好,optimize table的回收空间这一块也是需要规划和考虑的,。


在图里面可以显示,在基于有热表或者大表的业务需求情况下,可以将它平滑的演进到分布式里面,自动的做分片键的拆分,可以基于哈希来实现默认的分片,应用无需改造,基于强大的CPU和RPO的能力,自动做一个路由,对应用来是透明友好。


在这种场景下,如果客户有这种业务需求,签上来之后同时基于CDC的生态友好性,也可以将MYSQL作为一个备库,随时准备可以回流到单机的能力。


2. 典型业务场景~分布式容灾需求

图片9.png

作为一款企业级的核心业务分布式数据库场景。对它的这个容灾和高可用能力提出了非常严苛的要求,这里面PolarDB-X支持几乎多样化的容灾能力,满足不同客户的业务诉求。


首先第一个基于同城三机房的典型部署架构里面,基于Texas三副本的公司协议,提供了每个副本里面有leader、follower、logger等等这样的角色,主要的参与投票,是leader follower和logger。这里面提到的一点logger节点本身是只有日志,没有存放数据,也可以将logger节点升级为follower节点,来满足客户的对数据的业务需求。


一般在同城三机房的延时,会要求在0.5到两毫秒之间,能保证的是RPO等于零,RTO小于30秒,在金融级场景里面有一个非常严苛的要求,就是要支持内核级的两地三中心,甚至三地五中心的容灾部署。在这种情况下,提供的是基于两地三中心、五副本三地五中心五到七副本的内核级的存储能力,在一个节点宕机的情况下,不影响请求的延迟,同时在这种架构下面也能保证RPO等于零和RTO小于60秒,因为在三地五中心或者两地三中心的部署形态下,本地中心的延迟。一般会建议保证在5到30毫秒,在异地的话,由于跨越上百甚至上千公里的距离,这边的异地容灾是默认建议不参与事物的投票,所以在部署架构里面就研究出来另一套基于异地的灾备的能力,也就是上图左下角第三个状态,异地灾备基于集群对集群的复制,上面的两个形态主要是基于集群内部的能力。


下面形态基于DTS工具,或者是产品自带的复制能力来实现一个机房体容灾切换和异地的冷被恢复的能力,在配合着阿里云自带的MASA系统,可以实现流量的就近机房的访问切换,配合着DPS双向同步的能力,可以实现异地多活的能力输出。


3.典型业务场景~替换开源分库分表

图片10.png

 典型的第三个业务场景是在早期互联网发展的过程中,有很多分布分表的业务采用了开源的中间件产品,包括MyCAT、Sharding-JDBC、other等。


在这种情况下很多客户会为自己的运维以及批量的变更DDL扩收容等等带来复杂的运维操作,PolarDB-X基于的DTS工具,可以实现无缝的将线下的一个分工分表的架构迁移到PolarDB-X上,基于全局的binlog,可以打通回流到MYSQL能力,甚至配合刚才的DMS,开发DTS备份以及DTS传输,打通整个数据库的上下游,让数据库在整个阿里云的生态解决方案里面得到一个完整的流转。


3. 典型业务场景~HTAP混合负载

图片11.png

面向5G LT时代以及数字化转型,对于实时在线业务分析的需求,因为在绝大部分的中型以上规模的数据库业务需求里面,它除了实时的在线高并发、低延时这样的一个TP的核心业务处理能力之外,也想把这个热数据接入到PolarDB-X里面来做一些复杂的分析、聚合,以及跨分片的查询。


在这种业务需求情况下,早期的数据库产品无法满足整个客户的隔离性,一致性等等这样的需求,在PolarDB-X里面引入了全局时中的一个概念来保证数据的强一致性,同时基于多副本的技术,可以增加learner节点来保证物理的资源隔离性,在右边这张图的例子里面可以看到,比如先做了一个TP类的DML数据的变更。


同时又执行了一个较为复杂的查询,两个基于数据几乎都是同一个,获取的全局时间戳的,基于commit的CTS等得到的是35号,在获取到这个信息之后,应用访问是智能的路由,基于前置的CBO和全局时钟TSO能够实现自动的业务分发,比如识别到了TP的业务,就把它的流量打到了主实力上来实现一个更新。


同时面向复杂查询的情况,基于成本的优化,把它路由到了只读的节点上,只读节点上读取的事物,如果是正在刚刚提交的这个CPS等于35的情况下,会实现毫秒级的一致性的复制,将数据从主实力复制到的learner节点,这样满足AP副本的一致性只读,这样带来的一个好处看下面一个例子。


5.HTAP混合负载~指标测试(TPC-C/TPC-H)

图片12.png

在常规的混合负载的业务情况下,如果没有做好隔离的情况,会造成比如在第一个时间段,打入的是存量的TP型的TPC-C的一个流量,可以看到负载比较稳定的均匀的在运行。


在第二个阶段,突然间混入了一个复杂的分析,分析会很吃CPU和IO,在这种情况下,如果跑在同样的物理资源的实力上面,会极大的影响当前TP事物的稳定性。


在这种情况下,如果通过添加只读实例的方式,增加了混合负载的能力,可以基于CPU的智能路由和基于成本的优化器,将整个只读业务打到隔离的leaner节点上、只读节点上去,可以极大的保障稳定的TPC-C这个业务,以及TPC-H这种输仓类的分析业务,能够重新达到一个稳态,来进一步保障整个业务的稳定高效的运行。这个给客户带来的价值就非常大,所以在htap和负载场景下提供的强一致性和隔离性是大很程度上得到客户的认可。


6.基于PolarDB-X构建“新一代寄递平台”核心系统

图片13.png

由于PolarDB-X目前支持公共云,企业版和敏捷版等多种形态的输出,目前在中国邮政新一代的基地平台系统上面采用线下输出的形态。

中国邮政新一代寄递平台需要存储PB级业务数据以及抵御千万级并发规模,传统商业型数据库无法有效支撑。


当前该系统基于阿里云云原生分布式数据库PolarDB-X构建,2019年双十一订单业务峰值高达1亿以上;收寄量业务峰值超过7千万;投递业务峰值达3千万,有效支撑了此后历年“双十一”等业务高峰的生产作业处理。


在新—代寄递平台的成功实施的经验基础上,中国邮政着力提升对公众用户的线上服务能力,构建了在线业务平台,服务了5000万+线上用户。支撑在线业务平台的PolarDB-X数据库已累计上十亿条业务数据。


7.PolarDB-X助力城市公交系统智能化

图片14.png

PolarDB-X支撑了很多项目,以下案例是城市公交系统智能化,生活在北京的同学应该非常了解北京的公交是非常的拥堵,因为它目前即使保有了2万辆公交车,也无法满足千万级大都市人群同时出行的规模要求,但是启迪公交作为国内领先的智慧公交系统方案的提供商和服务运营商,它有效的承接了公交信息化和智慧化的项目建设,助力了互联网+城市公交的愿景,在有效的支撑北京两万多辆公交车,以及车载的这个GPS机具,传感器,It物联网数据的情况下。


同时,基于PolarDB-X的业务,是仅仅在不到一个月的时间就完成了上线开发。在实际的业务使用场景里面,PolarDB-X承载着对于刷卡乘车,扫码APP乘车,以及扫码支付和后端的票务管理,包括业务监控,实时的客流信息等等以及场站调度等等业务的场景,分布式数据库方案构建了全部的业务系统之后,非常有效的支撑了每日几千万笔的市民乘客相关数据,早晚高峰期可以达到每秒上千的并发量级,预计未来年平均会达到PPG以上的数据存储、计算、分析和查询的业务需求。


8. PolarDB-X全面涵盖阿里巴巴集团核心业务

图片15.png

最后简单介绍一下PolarDB-X目前在阿里巴巴集团核心内部,已经在诸多的场景下得到了广泛的应用。


比如在收购的业务里面,会提供全链路压测的产品能力,使得业务可以快速的介入到阿里巴巴的系统上来,并且提供多语言的支持,在主营的业务里面,保证稳定高效和低成本的运行,在内部业务里面,提供了统一的运维平台和能力,包括还提供了这个异地多活的高可用容灾能力和整个集团上云的能力。此外,还有一些新兴的业务,提供了包括多语言,包括的这个htap混合负载,以及国际化的这个产品能力。以上就是PolarDB-X产品的全部介绍。

相关实践学习
跟我学:如何一键安装部署 PolarDB-X
《PolarDB-X 动手实践》系列第一期,体验如何一键安装部署 PolarDB-X。
相关文章
|
7天前
|
Cloud Native 关系型数据库 分布式数据库
【PolarDB开源】PolarDB与云原生数据库比较:特点、优势与选型建议
【5月更文挑战第26天】PolarDB是阿里云的云原生数据库,以其计算存储分离、一写多读架构和数据一致性保障脱颖而出。与Amazon Aurora和Google Cloud Spanner相比,PolarDB在中国市场更具优势,适合读多写少的场景和需要严格数据一致性的应用。企业在选型时应考虑业务需求、地域、读写比例和兼容性。PolarDB作为优秀解决方案,将在云原生数据库领域持续发挥关键作用。
120 1
|
9天前
|
关系型数据库 分布式数据库 数据库
【阿里云云原生专栏】云原生时代的数据库选型:阿里云RDS与PolarDB对比分析
【5月更文挑战第24天】阿里云提供RDS和PolarDB两种数据库服务。RDS是高性能的在线关系型数据库,支持MySQL等引擎,适合中小规模需求;而PolarDB是分布式数据库,具备高扩展性和性能,适用于大规模数据和高并发场景。RDS与PolarDB在架构、性能、弹性伸缩、成本等方面存在差异,开发者应根据具体需求选择。示例代码展示了如何通过CLI创建RDS和PolarDB实例。
466 0
|
9月前
|
存储 Cloud Native 关系型数据库
云原生分布式数据库PolarDB-X(一)
云原生分布式数据库PolarDB-X(一)
134 0
|
9月前
|
弹性计算 关系型数据库 分布式数据库
体验云原生PolarDB
本场景带您体验如何基于PolarDB和ECS实现搭建门户网站。
191 0
|
9月前
|
关系型数据库 分布式数据库 数据库
PolarDB是一个由阿里巴巴开发的分布式数据库系统
PolarDB是一个由阿里巴巴开发的分布式数据库系统
84 1
|
SQL 负载均衡 Cloud Native
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(4)
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(4)
181 1
|
SQL Cloud Native 算法
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(3)
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(3)
210 1
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(3)
|
SQL 运维 监控
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(6)
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(6)
244 2
|
存储 Cloud Native 分布式数据库
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(5)
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(5)
179 1
|
SQL 存储 Cloud Native
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(1)
《云原生一站式数据库技术与实践》——一、云原生分布式数据库PolarDB-X技术架构(1)
285 1