polarDB关注点

Overview

数据库也要走向云原生(cloud native)了,

即, 技术体系和方法论往micro services, DevOps, continuous delivery, containers方向靠

随着用户业务数据量越来越大, 业务越来越复杂, 传统数据库系统面临巨大挑战²,

存储空间无法超过单机上限
通过只读实例进行读扩展, 每个只读实例独享一份存储, 成本增加
随着数据量增加, 创建只读实例的耗时增加
主备延迟高

云原生数据库的核心是存储与计算分离, 同时还必须具备高性能/高可扩展/一致性/符合标准/容错/易于管理和多云支持等特性

why polardb fast

PolarDB采用了共享存储一写多读架构, 唯一读写节点RW(主节点)和多个只读节点RO(从节点)共享同一份存储(ploarstore)
RW可以读写共享存储中的数据
RO仅能各自通过回放WAL日志, 从共享存储中读取数据, 而不能写入, RO通过内存同步来维护数据的一致性
RW与RO之间不再传输完整的WAL日志, 仅传输WAL meta. 减少网络数据传输量, 降低RO与RW的延迟
通过LogIndex实现WAL日志的延迟回放 + 并行回放以加速RO的回放速度
RW的WALSender进程从内存中的WAL Meta queue中获取WAL Meta信息
RO的WALReceiver进程接收到WAL Meta后也同样将其保存至其内存的WAL Meta queue中
双方都在mem中操作, 减少了disk IO, 从而降低RW与RO之间的延迟

architecture

RO内存同步架构

RO backend process lazy replay(XLog=WAL)

how polardb keep consistency

传统数据库

RW复制(sync)WAL日志到RO, RO依次回放WAL(复制状态机)

shared-storage数据库

RO通过从shared-storage上读取最新的WAL来回放
从shared-storage上读取到了过去页面, 即bufferPool release
- RO通过WAL receiver接收从RW过来的WAL meta信息
- WAL meta记录着该条日志修改了哪些page
- 将该条WAL meta插入到LogIndex中, key是PageID, value是log sequence number(LSN)
  - LogIndex<[PageID, LSN list]>
- 一条WAL日志可能更新了多个page(索引分裂), 对应logIndex中有多条记录
- 同时在bufferPool中给该page打上outdate标记, 以便下次读取的时候从logIndex再回放对应的日志
- 当内存达到一定阈值时, logIndex异步地flushed disk
从shared-storage上读取到了未来页面, 即another bufferPool release
- 限制RW的写入速度
- 加速RO的回放
  - 只复制WAL meta, 不需要传playload, 因为shared-storage(rw的playload已经被apply)
  - 在RO上, 通过WAL的元数据直接读取shared-storage上完整的WAL文件
    - server/回放进程端
      - 如果对应page不在内存中, 仅仅记录LogIndex
      - 如果对应的page在内存中, 则标记page为outdate, 并记录LogIndex
    - client/后台进程端
      - 用户session进程在读取page时, 读取正确的page到bufferPool中, 并通过logIndex来回放
      - io操作从原本的单个回放进程offload到了多个用户进程(多版本回放)
- DDL锁回放
  - DDL锁也可以offload到后台进程

传统数据库

shared-storage数据库

WAL = meta + blockdata, WAL record是由header, pageID, payload组成

multi-RW

看到roadmap的version 5.0 有写到将会支持多写特性, 那么这个multi-RW该如何继续保持consistency?

You can increase the read capability of a PolarDB cluster by creating more read-only nodes.

However, you cannot increase the writing capability because each PolarDB cluster consists of only one primary node.

Version 5.0 uses the shared-nothing architecture together with the shared-everything architecture.

This allows multiple compute nodes to process write requests.

Reference

PREVIOUS2021年跑步总结

NEXTqq collection