阿里云自研新一代企业云数据库POLARDB背后的技术

摘要： 从2008年到2018年，阿里巴巴的数据库技术已经发展了10年的时间，10年的时间从AliSQL到RDS，再到自研POLARDB，阿里巴巴数据库技术获得了极大的提高。那么在阿里云自研新一代企业云数据库POLARDB背后有哪些技术呢？本文中，阿里云数据库事业部总经理鸣嵩就为你们进行分享。

从2008年到2018年，阿里巴巴的数据库技术已经发展了10年的时间，10年的时间从AliSQL到RDS，再到自研POLARDB，阿里巴巴数据库技术获得了极大的提高。那么在阿里云自研新一代企业云数据库POLARDB背后有哪些技术呢？本文中，阿里云数据库事业部总经理鸣嵩就为你们进行分享。

阿里巴巴数据库发展的十年历程
首先介绍一下阿里巴巴数据库发展的十年历程。阿里巴巴数据库技术发展源于2008年所作的去“IOE“这件事情。以前阿里巴巴所使用的是商用数据库好比Oracle，阿里巴巴之因此要作“去O”是由于马老师看了财务报表以后发现若是继续使用Oracle等商用数据库，阿里巴巴的盈利就会补不上数据库的费用。因而，从2008年开始进行“去O”，当时使用的是MySQL开源分支上自建的一个分支——AliSQL，在其上放了电商场景中的像秒杀之类的各类补丁。基于AliSQL数据库内核，阿里巴巴在2011年开始研发云RDS产品，最开始只有MySQL服务，后来增长了SQL Server等数据库服务。在2018年，阿里云数据库团队推出了自研的POLARDB数据库产品，POLARDB在2014年开始研发，2017年在北京宣布开始公测，在2018年4月份正式商业化。与此同时RDS数据库实例数正式突破20万，占国内云数据库市场份额的50%。

由于阿里云RDS具备20万数据库实例，在服务这个20万实例以及背后的8万客户的过程当中，阿里云也发现了用户使用数据库过程当中的痛点和需求。所以，阿里云设计了POLARDB下一代数据库产品来解决用户的这些痛点和需求。用户的痛点一部分和数据库的能力和容量有关，好比数据库在单机上最大规模是3T，这仍是由于一台机器所能插下的SSD盘有限，当用户的数据存储量超过3T，那么用户就须要本身作分布式以及分库分表这些事情，这使得用户开发的要求大大提升。过去的MySQL写性能大概是2万TPS，而这样的性能对于不少用户而言是不够的，那么如何使一台数据库拥有更多的写入吞吐和读吞吐成为了须要解决的问题。此外还有并发的问题，由于用户在云上可能有几百个ECS客户端共同访问一个数据库，那么如何解决这种几百个并发之下的数据库性能也是一个问题。此外，主从复制也是一个问题，在云上须要两个实例作主从复制，可是基于Binlog的主从复制却带来了不少问题，好比DDL同步时间过长，主从复制中断会形成数据不一致。第三大类问题与备份相关，当数据库的容量达到必定程度，备份就成为一个难题，由于对于块进行备份须要进行上锁而后拷贝出来，这样的过程很是慢。复杂SQL，用户数据量增大以后，一些报表的需求就会须要执行很长时间，而但愿这样的复杂SQL变成分钟级的操做。

而今天，阿里云是带着用户对于数据库的需求来设计下一代数据库POLARDB的。POLARDB是阿里云新一代企业级云原生关系型数据库，100%兼容MySQL协议，最大容量能够达到100T。其弹性扩展能力很是强，能够从10G扩展到100T，能够从4核扩展到60核，能够从1个节点扩展到16个节点，是一个扩展性很是强的数据库集群。

POLARDB的架构设计
POLARDB总体架构能够分为四层，第一层是POLAR Proxy层，这一层解决的问题就是POLARDB是一写多读的数据库，最多能够达到16个节点，可是让用户去管理16个节点就变得很是复杂了。POLAR Proxy层就是让用户只看到一个endpoint，只看到一个VIP去访问数据库。读写分离等均可以在这一层实现。第二层就是关系数据库引擎层，第三层和第四层就是存储层，第三层是文件系统，第四层是存储扩展能力。

接下来将会自底向上介绍POLARDB的设计，最底下是分布式存储和文件系统层，这一层是为了解决容量问题。由于单机容量有限，可是若是想要实现100T的数据库就必须将数据存储到多台机器上面，这就是为何须要分布式存储层的缘由。数据库不只仅使用存储，还须要使用文件，所以在存储层之上还须要构建一层文件系统。在存储层里面，数据使用了三副本，提高了数据的可靠性和可用性。在存储层仍是用了新的硬件，这使得优点更加明显，使得数据库性能可以实现数量级上的提高。软件方面也作了操做系统、用户态文件系统以及用户态网络协议栈等优化。分布式存储层使得容量最高能够扩展到100TB，可使数据库文件分布在几十台机器里面，能够用这些机器的SSD来存储数据和提升I/O吞吐。其次，共享存储实现了Serverless计费。以前购买数据库时就须要预约存储容量，可是在POLARDB上，由于存储时分布式的，所以能够作到存储按照使用付费，帮助用户节省了存储开销。实现了无锁备份，以前的数据库备份是逻辑备份，有可能锁表也有可能锁页，因此性能很慢。而POLARDB是在存储层实现快照备份，在决定备份的时候直接生成一个只读快照，一分钟以内就实现了百T数据库的备份。

数据库引擎层所实现的核心功能是基于一份存储实现多节点挂载的，一写多读能力。这里介绍一下“一写多读”，你们都知道读写分离技术，其是说数据库主实例负责写，为了线性扩展读能力只能在主实例上挂载多个只读实例，经过将读逻辑复制到只读实例中，在只读实例中提高写性能，只读实例越多，整个集群的读能力就越强，其缺点是每一个只读实例都须要一个存储副本，实例之间经过Binlog复制实现数据拷贝。而在POLARDB中实现了突破，在主实例和多个读实例之间共享一份存储，这就意味着存储成本大大下降，而且只读实例越多，节省的成本就越多。此外，还使得只读实例的节点扩充变得更快，由于在生成只读实例的时候不须要进行数据拷贝，也就是经过技术带来了极速的弹性扩展能力。

接下来介绍如何实现多个节点共享一份数据库存储，其实相似的技术在全球也没有几家公司拥有。首先回顾一下数据库原理，假设本来有5个事务在执行，他们是T1~T5，他们在提交的时候会同步地写，表明事务的提交。可是以后更新到内存中后并不会马上刷新到磁盘文件中，也就是说数据文件的更新是异步的。在POLARDB中，因为刷新数据文件是异步的，所以在共享存储中仅刷新了T1的状态，其余的事务仍然存在于主实例的Buffer Pool里面。只读实例会不断地从磁盘中拉取RedoLog，将状态不停地拉到内存当中去，将事务保存到内存的Hash表中去，这时候若是有请求下来，若是命中Buffer Pool就读取，不然会到磁盘中读取较老的数据文件中的版本号，而后与内存表中的状态合并以后放到Buffer Pool并返回给用户。简单而言，只读实例经过读取共享存储中的Redo文件在内存中维护一个数据库，这个内存数据库只维护近期的更新，而又会从存储中读取老数据，在内存中完成实时合并，并最终返回给用户。

前面的过程较为通用，有些边缘状况是数据库系统所必须考虑的。所谓边缘状况就是过去5分钟内缓存了RedoLog，这些会占据内存空间，因此须要按期删除数据。那么这就出现了一个问题，若是只读节点删除数据的频率太高，就有可能致使部分RedoLog的丢失。为了不以上状况的发生，就须要主实例按期将本身Checkpoint的LSN发送给全部的只读实例，只读实例就会注意不可以删除Checkpoint后的任何RedoLog，避免产生数据空隙。第二个问题就是主库写数据文件也不能过于频繁，由于主库写数据过于频繁，也会致使只读库快照隔离出现问题。为此，从库须要按期将本身Snapshot的状态发送给主库，主库将全部只读节点的Snapshot版本取最小做为本身刷脏的阈值，若是某一个只读实例的Snapshot版本太老了就能够将其踢掉。

基于共享存储实现“一写多读”不只带来了只读实例的横向扩展能力，此外还大大地减小了在主实例上执行DDL，只读实例上执行DDL的时间间隔。今天，POLARDB能够作到仅须要极短的时间就能够将DDL同步到全部只读实例上，主库在执行DDL的同时，共享存储中的数据文件也在不断地进行修改，当主库执行完DDL以后，只须要将本身库的元信息进行修改，从库就当即可见，能达到低于10毫秒的延迟。

在“一写多读”之上就是智能的接入层，也就是Proxy层。由于POLARDB能够有多个节点，可是只但愿用户看到一个端口进行访问，这时候就须要Proxy层发挥做用了。Proxy层将负责负载均衡、链接管理以及安全管理。经过Proxy层实现了统一的集群入口，一个endpoint访问全部的数据节点，而且能够在其上实现白名单的安全机制。

POLARDB产品进展最后为你们释放三个重磅信息。首先，从POLARDB 2017年在北京发布到2018年宣布正式商业化，通过一年的发展时间，POLARDB的写入时间已经比AWS速度快2倍，在各个数量内核的状况下写入的TPS都是AWS的2倍。其次，在Proxy层实现了会话单调一致性读写分离，这个功能使得用户感觉不到读写分离所带来的主库和从库之间的延迟，使得用户就像使用一个数据库同样地使用POLARDB。第三个亮点就是SQL加速，这是POLARDB团队在过去一年的时间内服务了200多家企业用户后获得的需求。由于用户的数据库容量变大了，数据表和数据量都变大了，也须要查询变得更快。在这样的需求的启发下，POLARDB就实现了SQL加速。其原理就是在多个POLARDB只读实例中并发地加载同一个Snapshot数据，在中间层完成MPP运算。目前的效果是对于TPC-H和TPC-DS能够完美地支持，对于SQL查询速度提高了8到14倍，而将来将会进一步加快SQL查询速度。