MYSQL POLARDB 学习系列之 拆解 POLARDB 3 无服务与设计（翻译）和回答读者问题...

先说读者的问题

对于POLARDB 敢兴趣的同学应该不止这一位，而这位同学的问题，其实是很多对于POLARDB 敢兴趣的同学可能都想问的问题。

1  POLARDB 的性能需要进行测试

2  POLARDB 的性能实际上需要业务类的测试

3  如果单纯想把ORACLE  TO POLARDB ，我觉得您三思，语法和语句的复杂度以及语法解析器的问题，建议您测试后再说

4  如果仅仅是 MYSQL  TO  POLARDB  大表的问题，我个人觉得是一个好的思路，尤其对一些大表，需要更好的并行。

另外最近我们针对 POLARDB ， MYSQL RDS 阿里云的两款产品进行了压力测试，同时也对另外一款其他云的 MYSQL RDS 产品准备进行测试，至于测试结果，我们先看看 ，是否可以 share。

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

无服务架构的数据库是云原生数据库的衍生品，类似与aws Aurora 无服务架构和 Azure SQL 无服务架构。这里的主要的设计的目标是灵活的资源分配和将这些资源可以按付费获取资源的方式到产品的日常使用中。实际上就是在需要资源的时候进行资源的扩展，在不需要资源的时候进行资源的收缩。这里可以帮助到更多企业调整他们的为资源付费的预算。更具体的说，这样的方式可以在业务高峰期将资源拉出进行服务，在业务低峰将资源收缩。

现有的存在的无服务架构下的数据库的资源扩展被限制，主要还是要因为底层的存储结构将CPU 和内存都绑定的比较紧。一个资源包是一个灵活的CPU 和内存的组合在计算节点中（虚拟机或容器），一个Aurora 计算单元，包含2G的内存，并且与处理器进行关联。这样灵活的设计让可以在大多数的场景下，满足客户的需求。举例一个分析性的数据库客户有一个针对内存比较高的需求，对比他对CPU的需求，大量的数据应该被缓存到内存中被快速访问，对比事务性数据库客户需要更多的CPU资源来支持其业务高峰，其中较小的内存足以满足较高的缓存命中率。在分解架构下，由于CPU和内存是完全解耦的，因此资源提供对于自动伸缩来说更具成本效益。

相似的，AUTO-PAUSE的工作方式针对无服务架构的数据库是存在限制的。这样的结构绑定了CPU和内存资源，结果将导致在释放CPU和内存资源将需要很长的时间，而在分解化的结构中，CPU 和内存不在是绑定的关系，之间不在”同命运共呼吸”，因此内存可以在auto-pause 和 重启的数据库的情况下，内存始终是加载核心的数据，这就让上面的操作变得异常的快。

此外，可伸缩透明性是无服务器数据库的另一个设计目标。理想情况下，即使数据库跨计算节点扩展，迁移也不会中断客户的工作负载。使用这样的方式可以将数据库的状态，如脏页，事务的状态，逻辑锁，以及即席查询的结果都存储在共享内存中。通过这样的方式来提供更多灵活和对于客户的透明性。Polardb serverless 存储了脏页在共享内存中，并且还有更多的可能性留在后面的工作中。

3  设计

Polardb serverless 基于分解结构的云原生数据库，每一个PolarDB serverless 节点由多个代理节点组成, Polardb serverless 由polardb衍生而来，Polardb serverless 包含一个 rw节点，ro 节点，以及POLARFS 作为底层的存储池。这里polardb serverless 与 polardb的不同在于前者使用了远程内存池。

基于POLARDB 共享的内存最大的优势是，数据页面在RO 和 RW 节点是共享的，这改变了每个节点都需要进行内存的维护的问题，提升了内存利用率。这里的内存可以进行水平扩展，数据库有一个很大的内存池保证数据库可以完整的被加载进内存中。内存池的另一个好处是对比远程的数据的存储有更低的延迟。然而采用共享内存带来性能上的问题，远程的内存池的访问要对比本地的内存池访问要慢，这里就需要内存分层和预读技术的，而私有的内存页面变为的 RW RO 共享的内存页面，这就需要有一种互斥的机制。这里我们广泛的采用低延迟的RDMA verbs 和乐观锁避免全局的闩锁。最后一点是页面的传输给如刷写脏页给网络带来了负担，如 Aurora 和 Socrates， 我们写redo log 到存储和物力页面的方式是通过日志的同步的方式。

3.1  被分解的内存

上面提到的内存池的问题，那么如何访问这些内存池就成为一个问题，远程访问内存池是经过 librmem接口的，这里有5个重要的API 

这里通过代码来进行展示

3.1.2  远程内存管理中一个数据库的INSTANCE 中需要的内存被划分为多个内存节点，每个单元的内存被分配为一个slab , 每个slab 大小为1GB。

PA， 页面队列，每个slab中的数据存储结构为 page array(PA), PA 是一个连续的内存块，包含一个16KB 的页面，当一个内存节点被初始化时，所有的内存区域都会注册到RDMA NIC 网卡上。所以这些页面存储在PA 能够被直接通过 RDMA verbs 访问到。

为内存节点服务的slab 也被称为 slab 节点。一个slab 节点可以hold多个slabs。每个实例的内存资源被分配在多个 slab 节点上，当每个instance被创建，DBaas 将预留出预先定义好的buffer pool 的容量的slabs .

这些 slab 节点中的第一个将被定义为主节点与普通的slab节点相比，home节点包含一些额外的实例元数据。

Page Address Table (PAT), PAT 是一个hash 表，这里的slab节点的ID 和物力内存的地址被存储在这里，同时包含每一个页面的计数。在页面注册中，主节点通过查找PAT表来确定页面是否已经存在，如果不粗在，则会在页面被分配到内存池内后在PAT表里面进行注册。当一个页面被从远程内存吃中驱逐后，或者被清理后对应的PAT 中的记录也会被清理掉 。

PIB ，无效页面位图，PIB 是一个位图，对于在PAT表中的数据状态我们有一个无效的位图，值为0表示拷贝页面的最后的版本，当值为1时意味这RW节点已经在本地更新了，但还没有更新到远程的内存池。 这里也有一个本地的PIB，针对每一个RO 节点好嗨每一个在RO节点中的本地的缓冲是否过时。

PRD是另一个映射表。对于PAT表中的每个条目，都有一个PRD中跟踪的数据库节点列表，这意味着这些节点通过调用page_register获得了该页的引用。PIB和PRD一起使用来实现缓存一致性。

Page闩锁表(PLT)为PAT表中的每个条目管理一个Page闩锁(PL)。PL是一个全局物理锁，保护并同步不同数据库节点之间对页面的读写。特别是当多个数据库节点同时访问同一个索引时，它被用来保护B+树的结构完整性。

下面来描述一下，一个实例如何从remote memory中分配一个页面的过程。数据库的进程发送一个page_register 的需求给主节点，如果这个页面不存在，主节点扫描了所有的slabs ，去看看哪里有空闲的空间，如果没有空闲的空间内存空间可以被使用，将从计数的页面中去确认这个信息，并开始采用LRU算法来驱逐页面。
因为存储支持页面物理的清空的技术，脏页面将不在必须被刷新下到存储上就可以被清理了。同时主节点将页面的本地地址写入PAT。在页面分配过程中，主节点和slab节点之间不存在交互，以提高效率。与传统的数据库一样，有一个后台线程，它周期性地清除页面，并保持slab节点有空闲的页面，以避免清除前台的页面。

当用户动态扩展buffer pool size时，主节点将需求提交到DBaas去分配新的slabs，并且扩展buffer pool size时会同时扩展元数据如 PAT PIB 和 PD. 

反过来，当用户开始收缩buffer pool size时 ，系统会开始释放内存空间，这里通过LRU的逻辑将页面清出，页面会在后台被迁出，最终将这些释放后的slabs进行释放。