A-A+

PolarDB Serverless论文

2024年02月25日数据库暂无评论阅读 27 次

《PolarDB Serverless： A Cloud Native Database for Disaggregated Data Centers》

PolarDB架构

PolarDB是存储计算分离的架构。底层是定制的PolarFS层，它是一个分布式的、支持一写多读的文件系统层。上层是MySQL(InnoDB)计算层，支持一个RW节点和若干RO节点，计算层包含事务、BufferPool等，RW节点写事务产生redo并推送到RO节点，RW上的脏页被淘汰时刷入PolarFS，RO节点读取页面时，如果BufferPool未命中则从PolarFS中读取。

PolarDB的架构跟Aurora架构都是存储计算分离的架构，但有较大的区别。Aurora不需要RW计算层将脏页下刷存储层，存储层接收redo日志并进行回放成页面，支持多版本Page读取。

内存组件分离设计

存储计算分离之后，内存是不是也可以分离呢？

内存分离的好处是内存组件独自扩展，按需使用，支持高可用。计算、内存、存储三层池化，更好地支持serverless。

内存分离的坏处一是页面放到远端内存，因此读写延迟增加；二是分离后的页面对象在一个RW和多个RO节点间共享，需要解决全局BufferPool中页面并发读写问题。

分离后的内存池整体上是一大块足够大的BufferPool，具体组织为 MemoryNode - Slab - Page三层。Slab为连续的一块1GB大小的内存资源，其中存放一组16KB的页面，也叫Page Array (PA)。

PA是一个RW节点和多个RO节点之间共享的数据。因为它存放于远端内存，因此为了加速访问，节点local memory可能会缓存该页面。注意到页面可能会被RW节点更新，因此需要一套类似于CPU Cache Coherency的机制来保证节点间读写页面过程的一致性。在内存池中，有一个名为home slab记录用于Cache Coherency的元数据信息，其中包含：

每个页面需要增加ref_cnt来维护页面在内存池中load/evict/access，不再需要的页面可以从PA中移除。文中称之为Page Address Table(PAT)。
每个页面需要一个标记来表示这个页面是否已经被RW节点更新，文中称之为Page Invalidation Bitmap(PIB)，每个RO节点也维护一个PIB，用于记录本RO节点的local memory的页面是否outdated。
每个页面需要维护当前哪些RO节点已经持有了该页面的local copy，结合RO节点的PIB，共同保持RO节点上local memory中的页面维持最新。
既然B+Tree页面在多个节点间并发，那么用于B+Tree读写并发的latch也要变成全局共享的结构，文中称之为Page Latch Table(PLT)。

有了这些基本信息，节点之间的Cache Coherency就可以实现了，具体原理与MESI协议类似。发生SMO过程中的并发读写过程也可以通过PLT来控制。

另外的两个设计跟disaggregation没有直接关系，一个是CTS提交序，一个是增加新的page server免刷脏页面。