A-A+

PolarDB Serverless论文

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

《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免刷脏页面。

 

性能优化

因为访问页面和页面锁变成了远端内存访问,虽然使用了RDMA,但是相比local memory访问显然还是会带来比较高的延迟。文中介绍了两个优化。

优化一:RO节点访问B+Tree要通过PLT加S锁,优化为不加PLT锁而是采用乐观方式,读取的页面上会记录SMO counter,如果RO节点读取到的SMO counter跟查询一开始拿到的SMO counter不一致,则表示读取过程发生了新的SMO,重试读取。

优化二:index-aware prefetching。

 

Reliability

因为home slab维护了整个存储池的关键元数据,因此它的可靠性要求比价高,这就要求它有多个热备,对home slab的写操作需要同步到这些热备上,这会进一步加剧性能损失。

其他的内容都比较好理解。

 

 

给我留言