MYSQL POLARDB 学习系列之 拆解 POLARDB （翻译） 起源与解决问题 1

POLARDB 是一个具有国际性质的数据库产品，虽是一个“国产数据库” ，可最专业的资料还要看 E 文。以下为翻译

PolarDB Serverless ：A Could Native database for disaggregated Data Centers 的部分节选。原文将以截图的方式在文字的最下方

——————————————————————————————

传统的数据库迁移到云数据库的主要诉求是，具有更多的弹性，高可用的提高以及更低的成本。传统的数据库结构很难去面对这些需求，而面对与更高速的网络和新型的内存技术，下一代的云数据库应该被设计成分层性质的数据库产品。

在这个白皮书中，针对POLARDB serverless CPU 节点的资源与内存和存储之间分离的结构，每个资源池的伸缩都是独立的，并且按需供应，提高了无法的稳定性和安全性。同时我们还针对分离可能产生的问题，引入了乐观锁和预提取索引的放方式来解决问题。对比传统的结构，POLARDB Serverless 结构提供了更好的动态资源供应能力和更快的接近5.3倍的故障恢复速度，更好的性能。

1  介绍

作为企业将他的应用程序迁移到云的同时，数据库也要迁移到云上。这里有三点是让企业更愿意迁移到云上，首先云的供应商提供了按需付费的模式，为客户提供了一种避免为不必要的资源付费的服务，减少客户的费用支出，同时云供应商还为客户在类似 "618" , 双11 等爆炸需求的日子，为客户提供应对突如其来的数据库计算资源的需求膨胀的扩展的解决方案。在这些基础上，云供应商还需要通过高可用技术的基础来无感的修复现有数据库的缺陷和维护数据库产品。客户希望在节点失败，尤其是在节点维护或者软件升级时，对其的业务影响最小化。

云供应商如 AWS ,Azure , GCP, 阿里巴巴，作为DBaas提供的关系型数据库服务。这里有三个云数据库的典型的结构组成，

1 单片机

2 具有可挂载的远程磁盘的虚拟机

3  共享存储

后面两个部分，组成了我们现在称之为，计算和存储单元分离的云计算架构。通过这些架构的广泛使用，来应对一些传统方式的对云厂商数据库的挑战。

基于单片机的架构，CPU,内存，存储等这些资源，紧密的结合，而这里需要解决的问题就是如何将数据库与这些主机进行打包。

这里困难的地方是，如何让资源有效的利用这些硬件，使这些硬件有很高的利用率，在此基础上困难的是如何让客户根据需求在不同的时间对于资源的使用进行灵活的调整。

除此以外更大的难题是，当一个紧密耦合的系统在使用一个共享资源的系统时，面对其中一个资源失效后的连锁反应。与之对应的就是恢复这个系统的时间会更困难，并且需要更长的时间。

通过计算和存储单元分离的模式，DBaas 可以不依赖原有的模式，更加有效的使用现有的存储池，共享存储的方式减少存储的消耗 ---- 主从节点可以挂载同一个共享存储中，基于这样方式有助于减少存储的消耗成本，同时还可以将查询分析的业务迁移到从库运行。

同时也存在CPU 和内存被绑定在一起，缺乏灵活性和内存的可伸缩扩展性的问题，造成读节点依然冗余很高的内存，没有降低这一部分的成本。

在本文中我们提供一个新的云原生的数据库的架构设计方式，这个架构就是为了解决我们刚才提到的问题，在这个结构中，CPU 和内存不在互不可分，资源位于不同的节点，通过高速的网络连接，提高了各个资源的利用率并且彼此变得更加的独立。

通过这样的架构的设计，让每个资源都能独立，并且在出现故障的情况下可以很快的从故障中恢复过来，同时数据页面在远程的内存池中可以共享给多个数据库进程，类似于共享存储架构中共享的存储池。添加一个读副本不再增加内存资源的成本，除了消耗一小块本地内存。

最近这几年云原生得数据库提供商主推的是无服务的结构，无服务的数据库的主要功能是按需分配资源，采用自动伸缩，和自动暂停的方式，这些对于客户是透明的，不会影响客户正常的工作负载。

大多数云本地数据库都是基于共享存储架构实现的，其中CPU和内存资源是耦合的，必须同时进行扩展。同时自动暂停必须释放CPU 和 内存的资源，导致恢复起来时间很长，以上是我们提出的传统方式的一些限制。

POLARDB 无服务是遵循云原生的架构体系的，与主要的云原生数据库Aurora ，Hyperscale 的结构类似，Polardb 本身有一个主节点，同时可以有很多的读节点在数据库节点层。在这里我们不讨论多个主节点在POLARDB上的应用模式。

在PolarDB Serverless中引入了一个多租户的横向扩展内存池方式的设计，这里面包括页面分配以及生命周期管理。其中第一个挑战是在向系统添加远程内存之后，确保系统正确地执行事务。例如，在写操作后去读不应丢失任何UPDATE 的数据，即使是在不同的节点中，这里我们通过了缓存失效的方式来实现这个功能。

当读写节点正在操作B+树的索引进行拆分或合并，其他的读节点不应该看到操作中的中间状态，我们通过全局页闩锁来完成这个状态不被其他节点读取到，当读节点操作制度事务的情况下，会避免读取到未被提交的事务。为此我们通过在不同节点通过读取同步过来的视图来达到这个目的。

这样的分离式的结构也会产生一些负面的数据库性能的问题，如数据从远程获取，这就增加了数据获取的网络延迟的成本。第二个挑战是执行事务的有效性的问题，通过大规模利用RDMA （Remote Direct Memory Access ）尤其是 （这段硬件的问题不明白是什么东西，所以不翻译）one-sided RDMA verbs， 包含了使用 RDMA CAS，去优化了全局闩锁的问题。此外还提高了并发性的问题，在RW RO 节点通过优化了锁的技术避免了不必要的全局的闩锁的问题。在存储方面，页面的物化允许脏页从内存中被消掉但不需要刷新到存储中，另一面索引的预读的方式提高了查询的性能。

第一部分结束。