现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

PolarDB和Aurora对比

2020-04-29 06:48 工业·编程 ⁄ 共 1515字 ⁄ 字号 暂无评论

首先要向AWS Aurora的创新性致敬!Aurora通过计算节点和存储节点分离,计算节点scale up,存储节点scale out的理念将公有云的关系数据库产品推向了一个新的高度。

在设计方法上,阿里云的PolarDB和Aurora走了不一样的路,归根结底是我们的出发点不同

AWS的RDS一开始就是架设在它的虚拟机产品EC2之上的,使用的存储是云盘EBS。EC2和EBS之间通过网络通讯,因此AWS的团队认为“网络成为数据库的瓶颈”,在Aurora的论文中,他们开篇就提出“Instead, the bottleneck moves to the network between the database tier requesting I/Os and the storage tier that performs these I/Os.” Aurora设计于12到13年之际,当时网络主流是万兆网络,确实容易成为瓶颈。

PolarDB是从15年开始研发的,我们见证了IDC从万兆到25Gb RDMA网络的飞跃。因此我们非常大胆的判断,未来几年主机通过高速网络互联,其传输速率会和本地PCIe总线存储设备带宽打平,网络无论在延迟还是带宽上都会接近总线,因此不再成为高性能服务器的瓶颈。而恰恰是软件,过去基于内核提供的syscall开发的软件代码,才是拖慢系统的一环。Bottleneck resides in the software.

在架构上Aurora和PolarDB各有特色。我认为PolarDB的架构和技术更胜一筹

1)现代云计算机型的演进和分化,计算机型向高主频,多CPU,大内存的方向演进;存储机型向高密度,低功耗方向发展。机型的分化可以大大提高机器资源的使用率,降低TCO。

因此PolarStore中大量采用OS-bypass和zero-copy的技术来节约CPU,降低处理单位I/O吞吐需要消耗的CPU资源,确保存储节点处理I/O请求的效率。而Aurora的存储节点需要大量CPU做redolog到innodb page的转换,存储节点的效率远不如PolarStore。

2)Aurora架构的最大亮点是,存储节点具有将redolog转换为innodb page的能力,这个改进看着很吸引眼球,事实上这个优化对关系数据库的性能提升很有限,性能瓶颈真的不在这里:),反而会拖慢关键路径redolog落地的性能。btw,在PolarDB架构下,redolog离线转换为innodb page的能力不难实现,但我们目前不认为这是高优先级要做的。

3)Aurora的存储多副本是通过quorum机制来实现的,Aurora是六副本,也就是说,需要计算节点向六个存储节点分别写六次,这里其实计算节点的网络开销又上去了,而且是发生在写redolog这种关键路径上。而PolarDB是采用基于RDMA实现的ParallelRaft技术来复制数据,计算节点只要写一次I/O请求到PolarStore的Leader节点,由Leader节点保证quorum写入其他节点,相当于多副本replication被offload到存储节点上。

此外,在最终一致性上Aurora是用gossip协议来兜底的,在完备程度上没有PolarDB使用的ParallelRaft算法有保证。

4)Aurora的改动手术切口太大,使得它很难后面持续跟进社区的新版本。这也是AWS几个数据库产品线的通病,例如Redshift,如何吸收PostgrelSQL 10的变更是他们的开发团队很头疼的问题。对新版本做到与时俱进是云数据库的一个朴素需求。怎么设计这个刀口,达到effect和cost之间的平衡,是对架构师的考验。

作者:鸣嵩

给我留言

留言无头像?