《PolarDB-SCC: A Cloud-Native Database Ensuring Low Latency for Strongly Consistent Reads》

很多数据库系统通过类似于binlog复制或者redo复制的方式提供RO节点来提升整个系统的读吞吐，RW节点上产生更新，同步到RO节点apply变更。但只读请求发到RO节点上可能会读到陈旧的数据。如果想读到最新的数据（例如read-after-write一致性）呢？

首先读到最新数据或者强一致性读，指的是RO上启动的只读请求，应该能看到所有在它启动前已经commit的写事务的变更。

常见的解决方法是commit-wait和read-wait两类：

• commit-wait: RW节点等待RO节点apply完之后再返回客户端事务提交成功
• read-wait: 只读请求在RO上执行时，先获取RW上的时间戳并等待RO上变更apply到至少这个时间戳为止

commit-wait会引入提交延迟，read-wait会引入RO上的只读查询的延迟。

PolarDB-SCC大幅优化了RO节点的一致性读性能。

 

 

第一个优化是时间戳获取优化。

强一致性读问题的关键是在RO上当前读事务开启时，需要知晓此刻RW节点上最新的提交时间戳（可以偏大，不能偏小）。因此概念上RO上每个读请求都要从RW上fetch一次，但是如图的场景，实际上可以在满足条件的情况下，让一个读请求直接使用另一个读请求fetch的结果。图中r1就可以直接使用r2 fetch的结果。

 

第二个优化是避免不必要的等待。

 

如果RO上的一个事务要读取的页面或者表在最近一段时间内未被更新，则显然这个事务并不需要等待所有的redo变更apply到最新。但要得知这个事实就要维护每个页面的最新变更LSN。因为PolarDB自身已经使用了CTS提交序事务系统，因此LSN跟commit-timestamp是等价的。文中使用了称之为modification tracking table(MTT)的数据结构维护了三层timestamp值：

• Global Level: 整个db最新的提交时间戳
• Table Level: 表级别的最新提交时间戳，每个表维护一个
• Page Level: 页面级别的最新提交时间戳，每个页面维护一个

 

第三个方法是使用RMDA优化RW到RO的log shipment。

略。