一文详解PolarDB披荆斩棘的“秘密武器”

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 阿里巴巴自主研发的下一代关系型分布式云原生数据库PolarDB,在兼容传统数据库生态的同时,突破了传统单机硬件的限制,为用户提供大容量,高性能,极致弹性的数据库服务。

一、背景


传统的关系型数据库有着悠久的历史,从上世纪60年代开始就已经在航空领域发挥作用。因为其严谨的强一致保证以及通用的关系型数据模型接口,获得了越来越多的应用,大有一统天下的气势。


2000年以后,随着互联网应用的出现,很多场景下,并不需要传统关系型数据库提供的强一致性以及关系型数据模型。相反,由于快速膨胀和变化的业务场景,对可扩展性(Scalability)以及可靠性(Reliable)更加需要,而这个又正是传统关系型数据库的弱点。


自然地,新的适合这种业务特点的数据库出现,就是我们常说的NoSQL。但是由于缺乏强一致性及事务支持,很多业务场景被NoSQL拒之门外。同时,缺乏统一的高级的数据模型,访问接口,又让业务代码承担了更多的负担。数据库的历史就这样经历了否定之否定,又螺旋上升的过程。而这一次,鱼和熊掌我们都要


PolarDB就是在这种背景下出现的,由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时,突破了传统单机硬件的限制,为用户提供大容量,高性能,极致弹性的数据库服务。


二、核心技术之共享存储


1-1.png


PolarDB采用了Share Storage的整体架构。采用RDMA高速网络互连的众多Chunk Server一起向上层计算节点提供块设备服务。一个集群可以支持一个Primary和多个Secondary节点,分别以读写和只读的挂载模式通过RDMA挂载在Chunk Server上。PolarDB的计算节点通过libpfs挂载在PolarStores上,数据按照Chunk为单位拆分,再通过本机的PolarSwritch分发到对应的ChunkServer。每个ChunkServer维护一组Chunk副本,并通过ParallelRaft保证副本间的一致性。PolarCtl则负责维护和更新整个集群的元信息。


  • Bypass Kernel


PolarDB诞生于2015年,由于RDMA高速网络的出现,使得网络带宽接近于总线带宽。PoalrDB作出大胆的假设,那就是未来数据库的瓶颈将由网络转向软件栈自己。因此PolarStore中采用了大量的Bypass Kernel的设计。首先是新硬件的使用,NVME和RDMA的使用,摆脱了IO访问过程中的用户态内核态交互。


1-2.png


软件设计中,在绑定CPU,非阻塞IO的模式下, 通过状态机代替操作系统的线程调度,达到Bypass Kernel的目的。


  • ParallelRaft


PolarStore中采用三副本的方式来保证数据的高可用,需要保证副本间的一致性。工业界有成熟的Raft协议及实现,但Raft由于对可理解的追求,要求顺序确认以及顺序提交。而副本的确认提交速度会直接影响整个PolarStore的性能。为了获得更好的访问速度,PolarStore提出了ParallelRaft协议,在Raft协议的框架下,利用块设备访问模式中方便判定访问冲突的特点,允许一定程度的乱序确认和乱序提交,如下图所示:在所有已经确认提案中,那些对前序访问有访问Range冲突的提案会被暂时Block,而没有冲突的提案会进入Ready状态并commit,commit以后的提案会继续反馈给当前的Scheduler,之前被Block的提案有可能会进入Ready状态,进而继续被提交。


1-3.png



三、核心技术之物理复制


采用了共享存储的模式之后,Secondary上依然需要从Primary来的复制逻辑来刷新内存结构,如果Buffer Pool以及各种Cache。但是,由于读写节点和只读节点访问的是同一份数据,传统的基于binlog的逻辑复制方式不再可用,这时由于逻辑复制由于最终执行顺序的变化,导致主从之间不同的物理数据结构。因此DB层基于Redo Log的物理复制的支持是必不可少的:


1-4.png


不同于逻辑复制自上而下的复制方式,物理复制的复制方式是自下而上的,从共享存储中读取并重放REDO,重放过程会直接修改Buffer Pool中的Page,同步B+Tree及事务信息,更新Secondary上的各种内存Cache。除了支持共享存储外,物理复制还可以减少一份日志写。同时,由于整个复制过程不需要等到事务提交才能开始,显著地减少了复制延迟:


1-5.png


四、交易场景优化


针对双十一峰值交易场景,PolarDB也做了大量优化。


  • Blink Tree


在峰值交易场景中,会有大量涉及热点page的更新及访问,会导致大量关于这些热点Page的SMO操作,


之前PolarDB在SMO场景下由于B+Tree实现有如下的加锁限制:


  • 同一时刻整个B+Tree 有且只能有一个SMO在进行;
  • 正在做SMO的B+Tree分支上的读取操作会被阻塞直到整个smo完成。


针对这个问题PolarDB做了如下优化:


  • 通过优化加锁,支持同一时刻有多个SMO同时进行,这样原本等待在其他分支做SMO的插入操作就无需等待,从而提高写入性能;
  • 引入Blink Tree来替换B+Tree并通过缩小SMO的加锁粒度,将原本需要将所有涉及SMO的各层Page加锁直到整个SMO完成后才释放的逻辑,优化成Ladder Latch,即逐层加锁,修改完一层即可放锁然后去加上一层Page锁继续修改。这样原本被SMO阻塞的读操作会有机会在SMO中间进来:通过对每个节点增加一个后继链接的方式,使得在Page Split的中间状态也可以完成对Page安全的访问,如下图所示,传统的B+ Tree必须通过一把锁来Block整个Page Split过程中对所影响的Page的访问。而Blink Tree则不需要,即使Split还在进行中,父节点到子节点的链接还没有完成建立,依然可以通过前一个节点的后继链接找到正确的子节点。并且通过特殊处理确保访问到正确的Page,从而提高读取性能。


1-6.png


通过这些对B+ Tree的优化,可以实现交易场景PolarDB读写性能提升20%。


  • Simulated AIO


InnoDB中有simulated AIO的逻辑,用于支持运行在不包含AIO的系统下,PolarDB下的共享存储文件系统就是没有AIO的,所以采用的是simulated AIO的逻辑。


但是原版中的simulated AIO是基于本地存储设计的,与分布式存储的特性并不适配。为了进行IO合并,原版的simulated IO设计,将所有异步IO请求按照目标地址进行组织,存放在同一个IO数组中,方便将目标地址连续的小IO合并成大IO来操作,以提升IO的吞吐。


但是这个设计与分布式存储是不相适配的,连续的大IO操作,会使得同一时刻,只有一个或少量存储节点处在服务状态,浪费了其他存储节点的作用;另外,分布式存储的网络延迟较大,高负载下,网络中的Inflight IO会较多,IO组中的IO请求数量也会很多,而这种组织方式下,IO数组中的槽位状态都无序的,往数组中添加IO请求和移除IO请求的开销都很大。


所以,PolarDB在高负载下的性能比较差且不稳定,为此PolarDB专门对simulated AIO进行了重新的设计,主要包括:

a.合理地选择IO合并和拆解,充分利分布式存储的多节点优势;

b.建立状态有序的IO服务队列,减少高负载下的IO服务开销。


1-7.png


重新设计下,性能提升了很多

1-8.png1-9.png

稳定性也有了很大的提升


1-10.png1-11.png


  • Partitioned Lock System


PolarDB采用的是2PL + MVCC的并发控制方式。也就是用多版本数据构建Snapshot来服务读请求,从而避免读写之间的访问冲突。而读写之间的冲突需要通过两阶段锁来保证,包括表锁,记录锁,谓词锁等。每当需要加锁的时候,之前的做法都需要去log_sys中先获得一把全局的mutex保护。在峰值的交易场景中,大量的写入会导致这个地方的mutex成为瓶颈。因此PolarDB采取了Partition Lock System的方式,将log_sys改造成由多个LockSysShard组成,每个Shard中都有自己局部的mutex,从而将这个瓶颈打散。尤其是在这种大压力的写入场景下明显的提升写入性能。


1-12.png


  • Lockless Transaction System


PolarDB中支持Snapshot Isolation的隔离级别,通过保留使用的Undo版本信息来支持对不同版本的记录的访问,即MVCC。而实现MVCC需要事务系统有能力跟踪当前Active及已经Commit的事务信息。在之前的实现中每当有写事务开始时,需要分配一个事务ID,并将这个ID添加到Transaction System中的一个活跃事务列表中。当有读请求需要访问数据时,会首先分配一个ReadView,其中包括当前已分配最大的事务ID,以及当前这个活跃事务列表的一个备份。每当读请求访问数据时,会通过从Index开始的Roll ptr访问到这个记录所有的历史版本,通过对比某个历史版本的事务ID和自己ReadView中的活跃事务列表,可以判断是不是需要的版本。


1-13.png


然而,这就导致每当有读事务开始时,都需要在整个拷贝过程对这个活跃事务列表加锁,从而阻塞了新的写事务将自己的ID加入。同样写事务和写事务之间也有访问活跃事务列表的冲突。从而活跃事务列表在这里变成一个明显的性能瓶颈,在双十一这种大压力的读写场景下尤为明显。


对此,我们将Tansaction System中的这个活跃事务列表改造成无锁Hash实现,写事务添加ID以及读事务拷贝到ReadView都可以并发进行。大大提升了性能。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
|
4月前
|
存储 SQL 运维
“震撼发布!PolarDB-X:云原生分布式数据库巨擘,超高并发、海量存储、复杂查询,一网打尽!错过等哭!”
【8月更文挑战第7天】PolarDB-X 是面向超高并发、海量存储和复杂查询场景设计的云原生分布式数据库系统
112 1
|
7月前
|
关系型数据库 分布式数据库 PolarDB
稳健前行:PolarDB开源社区调研开始啦!
PolarDB开源社区调研持续进行中!我们会重视每一位开发者的反馈,对提供建设性建议的开发者将会提供精美周边礼品!欢迎大家参与!
|
人工智能 运维 Cloud Native
【活动回顾】PolarDB开源数据库技术沙龙(南京站)圆满落幕!
7月29日,PolarDB开源数据库技术沙龙(南京站)圆满落幕!本次活动PolarDB开源社区携手众兴华易、PostgreSQL中文社区、阿里云创新中心以及PolarDB的生态伙伴相约南京,汇聚业内专家,共同探讨开源数据库与AI在企业数字化转型中的应用与实践。
|
存储 SQL 分布式计算
以“升舱”之名,谈谈AnalyticDB PostgreSQL的核心技术
本文从升舱背景,数仓技术演进,业务需求出发,首先介绍了阿里云云原生数仓ADB PG的整体架构,使用场景与生态集成,产品形态与硬件平台支持,然后逐一介绍了自研向量化执行引擎,多态化存储引擎,自适应优化器,多租户资源隔离和云原生架构升级等升舱中用到的核心技术。在自研技术层面,按单机PostgreSQL本身对应能力,Greenplum在PostgreSQL上改造后的对应能力,以及业界主流产品相关能力和技术,到ADB PG对应能力构建和具体技术设计实现路线进行技术讲解。最后总结了具体升舱四步流程。希望通过本文能让读者对ADB PG从产品架构和核心技术能有全面了解,同时可用于评估业务升舱可行性。
568 0
|
运维 架构师 数据管理
OceanBase Meetup第五期 复杂业务场景下的数据库应用需求及挑战
“OceanBase Meetup”是由OceanBase发起和举办的技术交流活动,每期会邀请对数据库技术感兴趣的技术专家在开放自由的氛围下,分享业界前沿的新兴技术趋势和话题,同时会围绕热点话题进行互动讨论。希望通过线下聚会的形式,让更多的技术人员结识更多行业伙伴,分享和交流技术观点,碰撞出精彩火花。
OceanBase Meetup第五期 复杂业务场景下的数据库应用需求及挑战
|
Serverless 数据库 开发者
三位高颜值专家与你畅谈数据库领域的Serverless
《数据库风向标》是阿里云数据库与阿里云开发者社区共同打造的一档聚焦于数据库领域新趋势、新技术的视频栏目,每两周推出一期,与大家共话数据库热点话题。
254 0
三位高颜值专家与你畅谈数据库领域的Serverless
|
人工智能 Cloud Native 关系型数据库
当开源奔向物流,阿里云 PolarDB-X 数据库与韵达携手的背后
(转CSDN)作为阿里云原生分布式数据库PolarDB-X全功能开源后,在政企领域落地的首个公开大型案例,韵达与阿里云数据库合作开启了数字技术服务实体经济的新样本。
418 0
当开源奔向物流,阿里云 PolarDB-X 数据库与韵达携手的背后
|
运维 关系型数据库 MySQL
开源实践 | 六棱镜基于 OceanBase 选型探索与实践
本文将介绍六棱镜关于企业分布式数据库的选型实践,希望帮助有相似应用场景的企业用户高效的进行数据库选型。
341 0
开源实践 | 六棱镜基于 OceanBase 选型探索与实践
|
存储 Cloud Native NoSQL
一文详解PolarDB披荆斩棘的“秘密武器”
PolarDB由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时,突破了传统单机硬件的限制,为用户提供大容量,高性能,极致弹性的数据库服务。
679 0
一文详解PolarDB披荆斩棘的“秘密武器”

相关产品

  • 云原生数据库 PolarDB