炼数成金 门户 大数据 Nosql 查看内容

从架构深度解析阿里云自研数据库 POLARDB

2018-5-23 11:00| 发布者: 炼数成金_小数| 查看: 15842| 评论: 0|原作者: 覃里|来自: ITPUB

摘要: 全用户态架构,我们有用户态的分布式文件系统(libpfs),我们有自己的polarswitch,这是一个类似本地的网关。我们有用户态的IO栈,用的是开源的SPDK,还有一个用户态的网络RDMA。全用户态带来收益非常大,POLARDB性能 ...

数据库 存储 架构 分布式 硬件

蔡松露 阿里云云数据库资深技术专家、架构师
阿里云云数据库架构师,主要负责阿里云POLARDB、NoSQL技术以及阿里云数据库整体架构等工作。在搜索引擎、NoSQL数据库、分布式系统、操作系统内核等领域有深厚积累与丰富的经验。

POLARDB架构图
今天主要给大家介绍一下POLARDB。POLARDB是什么?是一个云原生数据库,前一段时间,我们在巴黎的ICDE 2018大会上,对云原生这个标准做了一些阐述,今天将从架构和产品设计方面,给大家讲一下POLARDB的具体实现。

上面这个是POLARDB的架构图,蓝色的线是数据流,红色的线是控制流,控制流是主要负责POLARDB里各个进程生命周期的管理,数据流顾名思义就是一个请求进来,数据在整个系统里的一个流转过程。

我们在设计POLARDB时,遵循四个原则:
1、 存储计算分离
2、 全用户态,0拷贝
3、 ParellelRaft,支持乱序提交
4、 大量使用新硬件

大家可以看到,我们上层是计算层,下层是存储层,存储和计算分离,中间通过RDMA高速网络相连接,

在计算层,有一个主节点,这个主节点负责读写请求,其余是备节点,备节点也是只读节点,只负责接收读请求。存储计算分离的好处,第一;存储计算分离了之后,相当于将原来一体化的架构做了水平的切分,切成了两层。这两层,以前,你必须要用相同的硬件,现在,你可以根据这两层不同的特点定制不同的硬件和策略。

例如,在计算层更关注的是什么? CPU+内存。在存储层更关注什么?可能并不是很CPU和内存,而是IO的响应时间和成本。所以,这两层差别很大。而这种差别会带来新的技术红利,我们可以把这个红利释放给用户。

另外,存储计算分离之后,计算层不持有数据,所以能很方便的做各种迁移。在存储层,POLARDB的存储是一个分布式的文件系统,这个分布式文件系统可以有自己的复制策略。但在以前,大一统的架构下,这件事是没有办法做的。因为,你在存储做策略,可能会干扰计算,你为计算制定策略,就可能干扰到存储。而现在,存储分离之后,存储可以做池化,池化的一个好处就是它没有碎片,也不会有不均衡的情况存在。如果有一些不均衡或热点,存储层也能自主地做一些迁移工作。你想象一下,在传统的方案中,以现在的RDS为例,有的机器上面可能有个大实例,有的机器上可能是小实例,很可能会出现一种情况,就是大实例把磁盘都快用光了,小实例所在的机器磁盘用的还不到1%,过去,你没办法去解决这种问题。但存储池化之后,这些问题完全都烟消云散了。

而且,存储计算分离之后,可以很方便地去做Serverless。这在存储计算没有分离之前,Serverless是没法做的。计算层怎么做一个临时的容器,那不可能的,因为数据都在一起。

全用户态架构,我们有用户态的分布式文件系统(libpfs),我们有自己的polarswitch,这是一个类似本地的网关。我们有用户态的IO栈,用的是开源的SPDK,还有一个用户态的网络RDMA。

全用户态带来收益非常大,POLARDB性能的提升,高于某些友商,一个很重要的原因,就是来自于这种全用户态架构和对新硬件的利用。

我们之前做过一个测试,在Linux上一次进程切换,成本大概是在20-30微秒左右,但是在一个RDMA网络里面,一次RDMA请求可能7-10微秒,所以一次进程切换,其实都够访问三次RDMA了。所以,这个差别是非常大的。POLARDB在存储层写三副本通过RDMA,三副本写完之后,可能就20-30微秒,这20-30微秒和一次进程切换的成本其实是相当的。所以通过消除这种进程切换,还有内存拷贝带来的收益是非常巨大的。


上图是POALRDB文件系统-PFS的一个详细介绍。这里,我就不详细地说了,大家如果关注,我们有两篇论文,有一篇是讲这个分布式文件系统,会在今年的VLDB 2018上会对外公开,这个文件系统的特点是什么,它是POSIX的一个API,对DB层的侵入很小。

回到存储层,POLARDB用的是三副本,采用ParellelRaft来同步三份数据,ParellelRaft是Raft的变种,比Raft更高效。Raft不允许乱序提交和日志空洞,这些限制让Raft性能比较低、吞吐比较小,ParellelRaft允许乱序提交,而乱序的好处就是它带来吞吐量几乎会翻番。

大家可能会问,底层存储这么做,上层事务的语义怎么去保证?我们事务的语义主要是靠DB层自己来保证的。比如说,DB层有一个事务有很多IO,这些IO可能在底层完全是乱序执行的,但是当你事务提交时,DB层要保证这些IO都是已经成功了。

对于空洞,我们有一整套完整的catch-up机制,这是一个非常复杂的过程,在VLDB 2018的论文中,我们有详细论述,这篇论文刚被接收。

我们也用到了大量的新硬件,刚才提到了RDMA还有3D X Point,我们现在也正在研究那个Open-Channel SSD,虽然是工业化很多年了,现在应该主流的存储机上都是SSD,但是对SSD应用,目前还是有蛮多问题的。因为SSD软件和硬件并不是是非常匹配,导致我们对SSD的使用是浪费的,这种浪费一个是来自性能,还有一个是来自寿命。

通常Open-Channel SSD的方式,就是IO性能还有寿命最终反映到我们的成本上,都会比以前有一个较大的提升。


这是我们自家POLARDB和RDS的对比压测结果,通过这张图可以看出,POLARDB的平均读性能是RDS的6倍左右,平均写性能是RDS的3倍左右,当然我们这个性能还在持续提升。我们的一个版本应该比这个还要再涨个30—40%。

POLARDB产品设计的五个维度

接下来,讲一下产品设计的特点。我们主要从五个维度去设计我们的产品。

第一个是性能,性能上可以很方便的扩展到上百万的QPS,而且RT很低,我们是小于等于2毫秒。存储很方便的扩展到100TB,也可以很方便的去缩回来。

第二个是弹性,在版本升级、规格升降配的时候,尽量做到零宕机。在存储层还有计算层很方便的做这种Scale up Scale out。

第三个是兼容性,目前我们是100%兼容MySQL 5.6的

第四个是可用性,目前我们承诺可用性是99.95%,

第五个是可靠性,目前承诺的是5个9。

在POLARDB中,可用性方面,读和写被分离到不同的节点上,只有一个写节点,写节点可以处理读写请求,其他的节点都是只读节点,只读节点可以很方便的去做Scale out,写节点也可以很方便的做Scale up,写QPS最多可达13W,读QPS可以很方便地扩展到几百万。

对于扩展性,所有节点都可以做纵向扩展,只读节点可以做横向扩展,实例的存储可以做纵向扩展,存储集群可以做横向扩展,当读写节点和只读节点之间做failover时可以做到0宕机。

数据迁移,POLARDB数据是怎么迁移,假设你是一个RDS的用户,你可以先备份到OSS,然后在POLARDB实例里面加载OSS上的备份数据,新生成一个POLARDB的实例。

你也可以通过DTS(data transfer service数据传输服务)做数据的实时迁移。未来我们还能提供一个方式,将POLARDB做成一个slave,直接挂到RDS的节点,实时复制数据。

如果你是用的第三方的商用的数据库,这种情况我建议你走DTS。因为DTS支持的数据库类型还是非常全的。

对于数据可靠性,我们可以做到1个region内可用区内多个可用区之间的failover,你可以在其他可用区启动一个standby实例并且使用redolog来进行复制,也可以在多个region之间failover,我们通常使用binlog进行复制,对于备份,我们可以秒级打出一个snapshot然后上传到OSS上。

下面是POLARDB的一些未来工作,在引擎层,目前大家看到的可能只有一个单点写入节点,未来我们将会支持多写,其次,我们还会引入一些新的组件。比如:Cache Fusion,通过Cache Fusion较大提升计算层的性能。未来,我们会支持更多的数据库类型,比如,MySQL 5.7,PostgreSQL、DocumentDB等。这些工作现在已经开始在做了。

在存储层,我们会使用3D XPoint技术来提升IO性能,我们也会通过open-channel技术在提升SSD性能,将来我们也会将更多引擎层的逻辑进行下推,尽量减少更多的IO,让计算层更加简单。

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2018-11-16 12:10 , Processed in 0.354547 second(s), 24 queries .