背景
《PolarDB PostgreSQL 开源训练营回放》 有介绍为什么高并发读写的性能会下降?
其中一个较大的原因是快照获取.
tuple是否可见, 需要依赖 当前数据库未结束的事务快照 来进行判断.
例如我们读到某条tuple, 这个tuple是什么事务更新或写入的, 如果在tuple head或clog中都无法找到当前事务是否已提交的标记, 那么就需要到事务快照中获取.
这个快照是一个数组结构, 判断时需要遍历. 未结束的事务越多, 遍历的代价越大. 是O(n)的开销.
另一方面, 遍历时需要对快照内的数组元素加共享锁, 但是, 如果另一个会话要对这个事务进行提交或回滚, 那么需要加排他锁, 那么它们就会产生锁冲突.
在高并发、小事务的场景中, 并发越多, 冲突的代价、遍历的代价都会增多, 导致性能下降.
Polardb使用CTS解决了O(n)的问题, 不需要通过事务快照即可判断tuple可见性, 详见polardb训练营-核心feature介绍章节.
polardb HLC 逻辑物理混合分布式时钟, 解决中心时钟的性能瓶颈问题
参考论文: Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases
https://cse.buffalo.edu/tech-reports/2014-04.pdf
在PolarDB for PG开源版本中的实现: 有一个非常详细的讲解
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
