PolarDB for PostgreSQL架构介绍

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: 在数据库开源的趋势下,阿里去PolarDB架构也从1.0演进到了2.0。

分享人:北侠   阿⾥云PolarDB内核


正文:本文从四方面来介绍PolarDB for PostgreSQL的架构。

Ÿ 数据库架构对比

Ÿ . PolarDB 1.0 存储计算分离架构

Ÿ PolarDB 2.0 HTAP架构

Ÿ 参与PolarDB开源社区


一、数据库架构对比


image.png

目前所有数据库可以分成三个架构:

Ÿ 左侧这张图是单机的数据库,也叫存储,存储计算是一体化的PG数据库,它的CPU、内存和磁盘都是在一台机器上的,也就是传统的数据库。

Ÿ 中间的架构是采用PolarDB的方案,基于共享存储的存储计算分离的数据库。我们将数据库的CPU内存放到一台机器上,把存储放到远端的共享存储池里,这样是多个节点共享一份存储,实际上它就是一个存储设备,也有可能在存储设备里又分成了多个副本,为了存储的高可用。存储计算分离的优势是:每个节点都能看到所有的数据,任何一个节点可以通过共享存储来得到所有的数据。在执行事务时,事务跨了多个分区,不像分布式数据库一个一个提交的算法过程,很容易完成在单机上事务的一致性,劣势是说扩展性不像分布式数据库那么好。

Ÿ 右图架构是开源的数据库,采用的方案是分布式的数据库,比如像典型的TIDB,整体的方案是将数据的表进行拆分,分布在不同的存储节点上,存储节点为了做高可用,就对每个表的分片做了多副本,可能会采用分布式的算法。优势是可以将整个集群做的非常大,比如可以做到1000个节点。劣势是在执行跨分区的事务时要做分布式事务的控制。


二、PolarDB 1.0存储计算分离架构


1)传统数据库痛点


image.png

这是PolarDB的架构。阿里云在处理数据库时,它早期是托管传统的标准数据库。那么它有什么问题呢?上图左侧是master的节点配置,右侧是两个Standby节点,数据通过redo日志做复制。传统的数据库储备模式的架构的问题:

Ÿ 扩展性差,当用户在这套架构下做扩容时,比如希望将3个节点扩展到16个节点,16个节点做读写分离来提高堵的能力,这时需要将3份数据复制到16份数据,这个过程是非常漫长的。

Ÿ 可靠性差,由于为了保证性能,主备之间的复制是异步复制,不能保证数据不丢失。

Ÿ 可用性差,当主节点宕机的时候,要通过故障发现再做故障切换,从其他备节点里选出可服务的一个机器,这个过程是很漫长的。

Ÿ 成本高,将3个节点扩展到16个节点的时候,计算和存储量成本是线性增加的。在一个集群里面,为了预防业务的高峰期需要去预占资源。


2)PolarDB云原⽣架构 - 存储计算分离架构


image.png

PolarDB的解决方案是存储计算一体化,在上图最左侧是传统的数据库,最右侧是PolarDB一个整体的架构,底层是共享存储。上面的计算节点,计算节点里面只有CPU和内存,没有本地存储,它的存储是通过RDMI高速网络和后端的存储池做交互,整体上数据只存在于远端的共享存储里,计算节点和存储节点之间是通过用户态的文件系统和后端的存储做交互,在这个过程中用的就是DirectIO。那这样做的话有什么好处呢?

Ÿ 弹性好,当存储计算分离的时候,业务的数据量会变得非常大,将存储池里面拖几个磁盘过来就可以了,在整个过程中3个计算节点是不需要动的,用户的业务是无感知的。如果业务高峰期来了,我的数据量没有变多,但是我的计算量的要求变高了,这时可以将3个节点迅速扩展到16个节点,只需要找到16台机器,把共享存储的路径挂载上去就可以了,这个过程理论上来说是分钟级别的,可以迅速的从3个节点扩展到16个节点。同理,当发现业务高峰期不需要这么多机器的时候,就将16个节点迅速的缩容到3个节点。

Ÿ 成本低,底层的存储是有一份,不管扩展到多个计算节点,存储是不需要再扩容的,整个存储的成本就降低了。

Ÿ 易用性,PolarDB在前端有一个透明代理,它可以做透明的读写分离。在事物里它的写可以路由到它的主节点,事物后续的堵的可以路由到其它的只读节点,可以做一个整体的负载均衡。由于每个节点能看到所有的数据,对于用户来说,相当于是在使用一个单机的数据库,但实际上架构是一个分布式的架构,底层存储是一个分布式的存储方案,单机数据库大家比较熟悉,使用起来用户体验也是比较好的。它是一个单机体验,我们可以做到对社区的100%的一个兼容。

Ÿ 可靠性。底层的共享存储池是PolarDB自研的分布式的共享存储,我们改进成三副本的复制算法。在存储上又做了秒级快照,如果对业务做快照的话,快照的时间是非常短的,底层使用了引用技术。

架构遇到的挑战:一致性的问题。这个架构是1份存储加N份计算,其它的三个架构挑战也可以说是架构的优深度优化,比如像低延时的复制以及快速的恢复和DirectIO的一些优化。


3)PolarDB云原⽣架构 - 存储计算分离原理

image.png

这张图是PolarDB在整个数据库的模块站里面做的事情,从上往下看,

Ÿ 第一层就是最上层也就是事务层,事务层支持了CSN快照,因为原生的数据库在做事物隔离的时候要去拿一个快照,这个快照要到一个大的数组里面去拿快照,拿快照的过程是很漫长的,它需要一个枷锁,这个临界区域是很庞大的,我们就借助社区的CSN快照,只需要做一些整数的原子操作就可以了。

Ÿ 第二层就是日志层,在日志层做了日志的复制优化和 layz的回放,并行回放和Log Index,在缓存层优化的是常驻的buffer pool,把DirectIO实现后,就不需要把内存给buffer了,那内存都可以作为buffer来用了, buffer会变得非常大。

Ÿ buffer大了的好处是缓存命中率会变高,风险点是之前所在buffer里面的所积累的一些页面也就消失。我们进程、主进程和buffer是解耦的,主进程宕机了buffer pool还在。

Ÿ 存储层的话,我们做了DirectIO、数据预读、预扩展和PolarVFS。数据文件系统的抽象不仅能对接到PolarDB的分布式文件系统,还可以对接到其它的自己实现的文件系统。


4)PolarDB存储计算分离架构 - 数据⼀致性

image.png

PolarDB的挑战是数据一致性的问题。见上图下方就是共享存储,共享存储里面有Data,Data里面配置的是200的页面,另一部分是redo日志也叫WAL日志。WAL日志里面有两条WAL日志100和500,往上面左上角看的话,是Master节点,内存页面是200,经过事物的运转后,产生了两条redo日志,日志是100和500,要将这两条日志落盘到共享存储上面。右上角是Replica节点,要做日志的回放,在共享存储下的好处是什么呢?我们发现redo日志不需要通过流复制发送过去,因为redo日志已经存在于共享存储上了。

Replica节点理论上是可以直接从共享存储上读到这个redo日志的,我们就不需要做真正的复制了, WAL Meta信息就是直接告诉redo日志在共享存储的位置就。这个信息可能就几个字节,真正复制是不需要的。这个架构不用复制redo日志的内容,只需要复制redo日志的原信息。


5)PolarDB存储计算分离架构 - 数据⼀致性问题1 - “过去⻚⾯

image.png

第一个问题是过去页面。它的产生是因为备库在内存中回放得到的新页面被丢弃。在这个图里RW节点有页面P1,加上它的日志200,就得到一个新内容叫日志页面,P1内容变成了600,也就在T1时刻所发生的事情,T1时刻在这个整个虚线的左侧主节点里面是500加日志200得到了内容600。在另外的节点上面,其它节点上的数据的内容是比较老旧的,因为它的日志没有复制过去。这个时候它的内容只有页面内容P1是500。横向看的话,T2时刻主节点将日志200发送给RO节点,也只能知道发送日志200是的位置,没有真的去发送。T3时刻在RO节点,页面500加上日志200,也得到一个最新的页面内容是600,日志200也是从共享存储上直接读的,得到页面的内容是600。T4时刻下一时刻P1的内存满了不够用了,他要将600给淘汰掉,淘汰掉之后内存里面就没有了,这时候T5时刻再次去发现又读到了一个P1页面,这个时候因为内存没有了,需要从共享存储上读。共享存储内容是老旧的500,就是因为主库没有将页面600刷新,这时就读到过去页面了。


6)PolarDB存储计算分离架构 - 数据⼀致性问题1 - “过去⻚⾯” 的解法

image.png

这个解决方案是按需回馈的,在每个节点上去记录每个页面应该回报到的地方。比如页面P1上面有日志200,400和800三条日志,将事件记录下来,其它节点需要回放的时候它就知道要读日志,需要用老旧的页面500加上日志200,就得到它所需要的页面。


7)PolarDB存储计算分离架构 -“过去⻚⾯” 的解法 - LogIndex数据结构

image.png

过去页面需要维护这个因素关系,对内存放不下的问题,我们研发了Logo Index的数据结构,专门用来记录每个页面上发生的事件,这是一致性问题。


8)PolarDB存储计算分离架构 - 数据⼀致性问题2 - “未来⻚⾯”

image.png

image.png


今天就不详细讲解未来页面了。


三、PolarDB2.0 HTAP架构


1)PolarDB2.0云原⽣架构 - HTAP架构

image.png

前面讲了PolarDB1.0,是在做存储计算分离时要做的事情。PolarDB2.0就是HTAP的一个架构,存储计算分离后通过读写分离将高并发的事物打散到不同的节点上。它没办法去解决什么问题呢?比如你去电信营业厅办业务,白天处理TB型的业务,像去营业厅办卡或者去办宽带,这时你对于电信就是TB型业务。因为你操作的是自己的账号,给自己账号里面充500块钱。对于后端的数据库来说,你只是操作自己的数据,它按照user ID做了一个索引,就可以快速定位到数据的位置,这是 TB型的业务,也叫做点查和点写,PolarDB1.0是解决这种问题的。这种业务晚上要对账,比如一个杭州市,我要去看每一个营业点的营收。这种查询实际上不是点查点写,不涉及去查某个用户发生的事情,只需要知道整个营业厅下午发生的事情,这是IP的一个应用。在存储、计算分离的架构下,这条SQL不管发给哪条节点,都可以快速的扩容到很多节点。

image.png

如果SQL落到一个节点上,这个节点的硬件资源又是有限的,在TP下面又有一部分IP的需求,那么就叫做TIP,实现了一套基于共享存储的MPP方案。有人就会知道解决方案是将SQL进行优化,经过分布式优化器将SQL产生计划数,拆分成很多个指数,指数分发到不同的计算节点上,这些计算节点做计算,将 结果进行汇总,汇总后再次打散再次汇总那么,这是MPP原理。不同的节点看到的数据是一样的,比如节点一发现表一有1万条数据,由于节点二底层的共享存储也能看到1万条数据,我们将SQL进行拆分,分发给不同的节点去做计算,每个节点都能看到1万条数据,这样的话得到的结果重复了是不对的。

扫描的数据量是原来的那种单机数据量,没有起到加速的效果,MPP共享存储要解决问题是说如何将表进行拆分,比如用户表有1万条数据,希望两个节点做加速,节点一扫5000条数据节点,节点二扫另外5000条数据,节点一和节点二扫的结果再做一个合并,那么得到1万条数据。我发动了两个节点,每个节点只处理1/2的数据,整体的资源和运行效率都提升了。我们做到了共享存储的MPP,有四大好处:

Ÿ 第一个好处是提升 ScaleOut的能力,就是横向扩展的能力。用户需要IP的分析需求时,可以增加节点,选择一部分节点来跑分析型查询,另外一部分节点来跑TP型,也就是点查点写的这种查询。

Ÿ 第二个好处是一体化的解决方案,可以对应到像TIDB,会发现TIDB是的事务型的集群,跟IP型的的集群是分开的。PolarDB的数据底层还是原来的那套数据,只是在内核里面做了两套计算引擎,一个是点查点写,另一个是分布式型的。

Ÿ 第三个好处是Serverless,可以SQL级别的弹性的扩展。存储计算分离之后,比如某个业务的第一条SQL跑在节点一和节点二上,那么第三条SQL可以跑在节点五和金的六上都可以做到。

Ÿ 第四个好处是可以做到TP和AP在物理上是隔离互相不干扰的。


2)PolarDB云原⽣架构 - HTAP架构 - 基于共享存储的MPP

image.png

左侧这个图是个比较有意思的示例,了解oracle就会发现,它可以让某个业务跑在节点一、节点二上,另外一个业务跑在节点三和节点四上。如何做到Serverless这种无状态化呢?那么如果说我们对齐到像社区的方案,就是他在做MPP的时候会将它的所有的信息放到共享存储上,其它的worker是没有状态的,它的状态来自共享存储,它是无状态就可以迅速做扩容。基于共享存储的MPP,把数据清洗的问题给彻底解决了,即使选择很好的分布策略,在业务运行的时候,后续也会造成数据清洗。

即使没有数据清洗,也可能有计算清洗。比如我查询关注某些特征的用户,那这些特征的用户可能集中落到某两台或者某几台机器上,一条SQL下去之后,只有这几台计算节点在做SQL的执行,其他节点实际上是空闲的,整体的资源利用率是比较低的,那么我们怎么样去做这个数据清洗呢?利用了共享存储的特性叫能者多劳,在做数据扫描时,将整个任务切分成了多个小段,就是task切分成了多个小task,每个节点先处理自己的task,先去扫描4M的数据再去做处理,这个处理就走火山模型,处理完4M的时候再处理下一个4M。因为共享存储的数据是共享的。当某些节点处理的比较慢,其它的节点处理比较快的时候,那处理快的节点可以消费更多的数据,整个的计算过程会把慢节点给补偿回来。


四、PolarDB开源社区


image.png

大家可以搜到PolarDB的主页,项目主页里面有整个的架构的详细介绍,有中文版和英文版,我们工程师花了很长时间来编写的,设计的要点都写在了这里面,也欢迎大家去做开源的贡献,流程是先要去folk主仓库,把代码克隆到自己的本地,比如说你们可以去帮忙去从一些简单的事情做起,可以去下载的设计文档,可能里面中文和英文是不对齐的,可以把一些小问题给挑出来,走一下这个流程。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
30天前
|
Cloud Native 关系型数据库 分布式数据库
让PolarDB更了解您--PolarDB云原生数据库核心功能体验馆
让PolarDB更了解您——PolarDB云原生数据库核心功能体验馆,由阿里云数据库产品事业部负责人宋震分享。内容涵盖PolarDB技术布局、开源进展及体验馆三大部分。技术布局包括云计算加速数据库演进、数据处理需求带来的变革、软硬协同优化等;开源部分介绍了兼容MySQL和PostgreSQL的两款产品;体验馆则通过实际操作让用户直观感受Serverless、无感切换、SQL2Map等功能。
101 7
|
2天前
|
存储 关系型数据库 分布式数据库
PolarDB 开源基础教程系列 1 架构解读
PolarDB 是阿里云研发的云原生分布式数据库,基于 PostgreSQL 开源版本,旨在解决传统数据库在大规模数据和高并发场景下的性能和扩展性问题。其主要特点包括: 1. **存储计算分离架构**:通过将计算与存储分离,实现极致弹性、共享一份数据以降低成本、透明读写分离。 2. **HTAP 架构**:支持混合事务处理和分析处理(HTAP),能够在同一系统中高效执行 OLTP 和 OLAP 查询。 3. **优化的日志复制机制**:采用只复制元数据的方式减少网络传输量,优化页面回放和 DDL 锁回放过程。 4. **并行查询与索引创建**:引入 MPP 分布式执行引擎。
24 7
|
6天前
|
关系型数据库 分布式数据库 PolarDB
通过 PolarDB for PostgreSQL 实现一体化的 HTAP 能力
阿里云 PolarDB for PostgreSQL作为一款领先的云原生关系型数据库,利用向量化引擎+列存索引等技术实现了 OLTP 和 OLAP 的一体化。本方案为您展示如何通过 PolarDB for PostgreSQL 来实现一体化的 HTAP 能力。
|
5月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
26天前
|
运维 关系型数据库 分布式数据库
阿里云PolarDB:引领云原生数据库创新发展
阿里云PolarDB引领云原生数据库创新,2024云栖大会将分享其最新发展及在游戏行业的应用。PolarDB凭借弹性、高可用性、多写技术等优势,支持全球80多个站点,服务1万多家企业。特别是针对游戏行业,PolarDB助力Funplus等公司实现高效运维、成本优化和业务扩展。通过云原生能力,PolarDB推动游戏业务的全球化部署与快速响应,提升用户体验并保障数据安全。未来,PolarDB将继续探索AI、多云管理等前沿技术,为用户提供更智能的数据基础设施。
|
29天前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
3月前
|
数据库
|
5月前
|
存储 关系型数据库 分布式数据库
揭秘PolarDB:中国云原生数据库的超级英雄,如何颠覆传统数据存储?
在数字化时代,数据成为企业的核心资产,而云原生数据库则是推动企业转型的关键。PolarDB凭借其先进的存储计算分离架构,在性能、可靠性和易用性方面脱颖而出,成为国内领先的选择。它支持多种数据库引擎,提供多副本存储机制,并采用按量付费模式,有效降低管理和成本压力,助力企业实现高效、可靠的数字化转型。
96 1
|
2月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
77 3