从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查询速度。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
