《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍(1)

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍(1)

PolarDB-PG分布式整体架构


PolarDB-PG开源是一个分布式的数据库,第一期开源是单机和三节点高可用的部分,但是现在开源的单机的部分已经具备了支撑分布式的一些基本功能,包括基于时间戳的MVCC,以及事务可见性方面的一些特性。


image.png


本文会介绍单机如何支撑分布式事务,以及如何保证可见性、一致性等特性,这些在开源的代码里面也已经有了,我们在后期会把分布式协调节点的逻辑开源,就可以真正地跑起一个分布式的数据库,并且保证分布式事务全局一致性,提供ACID特性。


基于提交时间戳的MVCC的设计动机


我们基于提交时间戳的MVCC的设计动机有两个,一方面是改进单机的性能,就是消除基于快照的多核可拓展瓶颈,Postgre采用的是基于ID的快照来保证事务的隔离性,这样的话会有一些快照的生成,还有生成的瓶颈。


另一方面,我们在单机上支持基于时间戳的分布式事务协议。这样的话,我们既可以单机来跑,在部署成分布式以后,也可以去支持分布式事务。


消除基于快照的多核可扩展瓶颈


image.png


可以看到传统PG基于快照的一些瓶颈,MySQL也是一样的,都会从运行事务列表里获取一个快照来获知在事务或语句开始的时候,当前正在运行的事务。


这样的话会有一个问题,就是它会去加Proc Array的锁去遍历,虽然是共享锁,那么这在高并发下就有一个遍历的开销。另外一个就是共享锁的竞争,因为事务在结束的时候需要加互斥锁去清理,那么这个时候就会造成锁的竞争以及获取快照的开销,O(N)的开销,即要遍历N个Proc。


支持基于时间戳的分布式事务协议


image.png


我们在分布式场景下也是一样的,如果在分布式场景也采用XID Snapshot的话,也会造成生成全局快照的单点GTM瓶颈,每个节点也需要通过网络从GTM获取一个分布式的快照,当集群并发事务很高的时候,快照获取的开销也很大。


基于提交时间戳的MVCC


image.png


基于提交时间戳的MVCC的话,假如有任意的两个事务T1、T2,T1提交的修改对T2可见的条件就会很简单,就只要T1的提交时间戳小于或等于T2的开始时间戳。事务开始和提交的时候,我们都会给它分配时间戳,对于单机数据库,比如说现在开源的,我们就会采用一个原子变量来生成单调递增的64位时间戳。


我们以一个事例来看,图中有三个事务T1、T2、T3,我们可以看到T1、T2是串行的,相当于T2在T1结束以后才开始的,所以T1的修改对T2是可见的。T3和T2是并行的,这样的话T3对T2不可见,我们可以通过时间戳来确定它的开始及结束的绝对顺序,来保证可见性和隔离性。


提交时间戳存储和访问


image.png


在基于时间戳的MVCC中,为了做可见性判断,我们就要存储每个事务的提交时间戳。


存储的管理有空间分配、回收、持久化、故障恢复等。对于单机数据库可以采用非持久化的存储机制,就是PG社区里CSN(Commit Sequence Number)的方案,它维护了一个对全局所有事务都可见的最小的Transaction Xmin。


当XID小于Transaction Xmin的提交时间戳的空间就可以回收,因为它对所有的事务都可见了,只要它的XID小于这个,判断它可见性的时候就可以直接判定为可见,所以就不需要存储,它存储提交时间戳的空间就可以回收,用来存储其他务的时间戳。


XID小于Transaction Xmin可以通过CLOG去判断可见性,就是提交即可见。对于数据库重启,重启之前提交的事务对当前正在运行的事务均可见。


对于一个分布式数据库就不一样,它需要一个持久化的存储,为什么?一是我们的每个节点是去中心化的,每个节点都独立维护了自己的XID的分配,要去计算一个全局的Transaction Xmin不太可行。我们可能会有另外一种方法,就是用一个中心节点,比如说GTM,去维护全局唯一的XID,这样的话计算全局Transaction Xmin就会有开销。


同时分布式的逻辑就会很复杂,而且这样的话XID消耗也会比较快。当规模很大的时候,比如几百个节点的时候,XID消耗就会很快,因为32位的XID很快就会进入回卷的状态。


当没有全局XID分配的情况下,分布式数据库中一个节点重启,重启之前的事务不一定可见,所以需要恢复提交时间戳去判断可见性,所以一个理想的方案就是要把提交时间戳持久化存储。


提交时间戳存储设计与实现


可以看一下持久化存储的系统。


image.png


最底层是提交时间戳的一个存储,这是一个物理上的按页持久化存储,并且可故障恢复。上面Buffer层用来缓存访问过的物理页面。


我们同时用了Hash-Partitioned的方法,实现多分区的LRU Buffer,来提高它的可扩展性,减少锁竞争。


事务在提交的时候就会以XID为Key,以CTS为值,写入整个存储中。在做MVCC Scan可见性判断的时候,我们就会去存储里面去读XID的Timestamp。为了加速,我们在Tuple Header里也会缓存这些Timestamp ,这就跟缓存CLOG的提交状态一样,就是为了减少对CTS的访问。


《PolarDB for PostgreSQL源码与应用实战》——PolarDB-PostgreSQL开源核心Feature介绍(2) https://developer.aliyun.com/article/1232761?groupCode=polardbforpg

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
15天前
|
数据库
|
20天前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
80 4
|
1月前
|
存储 关系型数据库 分布式数据库
使用开源PolarDB和imgsmlr进行高效的图片存储和相似度搜索
使用开源PolarDB和imgsmlr进行高效的图片存储和相似度搜索
|
1月前
|
SQL JSON 关系型数据库
MySQL是一个广泛使用的开源关系型数据库管理系统,它有许多不同的版本
【10月更文挑战第3天】MySQL是一个广泛使用的开源关系型数据库管理系统,它有许多不同的版本
133 5
|
1月前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
1月前
|
关系型数据库 分布式数据库 数据库
PolarDB 开源:推动数据库技术新变革
在数字化时代,数据成为核心资产,数据库的性能和可靠性至关重要。阿里云的PolarDB作为新一代云原生数据库,凭借卓越性能和创新技术脱颖而出。其开源不仅让开发者深入了解内部架构,还促进了数据库生态共建,提升了稳定性与可靠性。PolarDB采用云原生架构,支持快速弹性扩展和高并发访问,具备强大的事务处理能力及数据一致性保证,并且与多种应用无缝兼容。开源PolarDB为国内数据库产业注入新活力,打破国外垄断,推动国产数据库崛起,降低企业成本与风险。未来,PolarDB将在生态建设中持续壮大,助力企业数字化转型。
84 2
|
2月前
惊世骇俗!开源 PolarDB-X 部署安装大冒险,全程心跳与惊喜不断!
【9月更文挑战第8天】作为技术爱好者的我,近期成功完成了开源 PolarDB-X 的部署安装。尽管过程中遇到不少挑战,但通过精心准备环境、下载安装包、配置参数及启动服务等步骤,最终顺利实现部署。本文将详细介绍部署全过程及可能遇到的问题,为您的 PolarDB-X 探索之旅提供参考与启发,希望能让大家在技术海洋里畅游得更加顺利!
147 2
|
2月前
|
Cloud Native 关系型数据库 分布式数据库
PolarDB开源项目未来展望:技术趋势与社区发展方向
【9月更文挑战第5天】随着云计算技术的发展,阿里云推出的云原生分布式数据库PolarDB受到广泛关注。本文探讨PolarDB的未来展望,包括云原生与容器化集成、HTAP及实时分析能力提升、智能化运维与自动化管理等技术趋势;并通过加强全球开源社区合作、拓展行业解决方案及完善开发者生态等措施推动社区发展,目标成为全球领先的云原生数据库之一,为企业提供高效、可靠的服务。
90 5
|
2月前
|
关系型数据库 MySQL 分布式数据库
PolarDB开源社区动态:最新版本功能亮点与更新解读
【9月更文挑战第6天】随着云计算技术的发展,分布式数据库系统成为企业数据处理的核心。阿里云的云原生数据库PolarDB自开源以来备受关注,近日发布的最新版本在内核稳定性、性能、分布式CDC架构及基于时间点的恢复等方面均有显著提升,并新增了MySQL一键导入功能。本文将解读这些新特性并提供示例代码,帮助企业更好地利用PolarDB处理实时数据同步和离线分析任务,提升数据安全性。未来,PolarDB将继续创新,为企业提供更高效的数据处理服务。
176 3
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
363 0

热门文章

最新文章

相关产品

  • 云原生数据库 PolarDB