1. 【PolarDB for PostgreSQL】-简介

喂你袋盐啊
496 阅读6分钟

开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 2 天，点击查看活动详情

以前做过postgreSQL的国产化数据库平台，最近看到阿里有个PolarDB for PostgreSQL，抱着学习的态度，临时起意，简单了解一下PolarDB for PostgreSQL

官方文档

文档 | PolarDB for PostgreSQL (apsaradb.github.io)

码云地址

PolarDB-for-PostgreSQL: PolarDB是阿里云自研的云原生关系型数据库，采用的是分布式共享存储（存储与计算分离）架构 (gitee.com)

什么是 PolarDB for PostgreSQL

PolarDB for PostgreSQL（下文简称为 PolarDB）是一款阿里云自主研发的云原生数据库产品，100% 兼容 PostgreSQL，采用基于 Shared-Storage 的存储计算分离架构，具有极致弹性、毫秒级延迟、HTAP 的能力。

  1. 极致弹性：存储与计算能力均可独立地横向扩展。

    • 当计算能力不够时，可以单独扩展计算集群，数据无需复制。
    • 当存储容量或 I/O 不够时，可以单独扩展存储集群，而不中断业务。

  2. 毫秒级延迟：

    • WAL 日志存储在共享存储上，RW 到所有 RO 之间仅复制 WAL 的元数据。
    • 独创的 LogIndex 技术，实现了 Lazy 回放和 Parallel 回放，理论上最大程度地缩小了 RW 和 RO 节点间的延迟。

  3. HTAP 能力：基于 Shared-Storage 的分布式并行执行框架，加速在 OLTP 场景下的 OLAP 查询。一套 OLTP 型的数据，可支持 2 套计算引擎：

    • 单机执行引擎：处理高并发的 TP 型负载。
    • 分布式执行引擎：处理大查询的 AP 型负载。

PolarDB 还支持时空、GIS、图像、向量、搜索、图谱等多模创新特性，应对企业对数据处理日新月异的需求。

image.png

架构

计算和存储分离

PolarDB for PostgreSQL 采用了基于 Shared-Storage 的存储计算分离架构。数据库由传统的 Share-Nothing 架构，转变成了 Shared-Storage 架构——由原来的N 份计算 + N 份存储，转变成了 N 份计算 + 1 份存储；而 PostgreSQL 使用了传统的单体数据库架构，存储和计算耦合在一起。

software-level

为保证所有计算节点能够以相同的可见性视角访问分布式块存储设备，PolarDB 需要使用分布式文件系统 PolarDB File System（PFS）open in new window 来访问块设备，其实现原理可参考发表在 2018 年 VLDB 上的论文[1]；如果所有计算节点都可以本地访问同一个块存储设备，那么也可以不使用 PFS，直接使用本地的单机文件系统（如 ext4）。这是与 PostgreSQL 的不同点之一

传统数据库的问题

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

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

PolarDB 云原生数据库的优势

  1. 扩展性：存储和计算分离，极致弹性
  2. 成本：共享一份数据，存储成本低
  3. 易用性：具备分布式的优势和单机体感
  4. 可靠性：三副本、秒级备份

Shared-Storage 带来的挑战

基于 Shared-Storage 之后，数据库由传统的 share nothing，转变成了 shared storage 架构。需要解决如下问题：

  • 数据一致性：由原来的 N 份计算+N 份存储，转变成了 N 份计算+1 份存储。
  • 读写分离：如何基于新架构做到低延迟的复制。
  • 高可用：如何 Recovery 和 Failover。
  • IO 模型：如何从 Buffer-IO 向 Direct-IO 优化。

架构原理

image.png

基于 Shared-Storage 的 PolarDB 的架构原理。

  • 主节点为可读可写节点（RW），只读节点为只读（RO）。
  • Shared-Storage 层，只有主节点能写入，因此主节点和只读节点能看到一致的落盘的数据。
  • 只读节点的内存状态是通过回放 WAL 保持和主节点同步的。
  • 主节点的 WAL 日志写到 Shared-Storage，仅复制 WAL 的 meta 给只读节点。
  • 只读节点从 Shared-Storage 上读取 WAL 并回放。

Shared-Storage 带来的挑战及如何解决的

上面又说到Shared-Storage带来的挑战，下面一个一个学习polarDB for postgreSQL是如何解决的的？

问题1：数据一致性？数据包括只读节点元数据如何保证一致性？

由于架构从shard_nothing 变成了Shared-Storage,数据共享一份，但是Storage层做高可用的时候数据副本是如何保证一致性的？以及wal日志的meta元数据会同步到只读节点，多个只读节点之间如何保证元数据一致？新加入的只读节点如何同步元数据？只读节点wal日志回放有没有可能因为同一时刻同步的meta数据不一样，而导致回放时数据不一致？

学习中，未完待定....

问题2：读写分离：如何基于新架构做到低延迟的复制？

智能代理 image.png 数据共享一份的同时,polarDB for postgreSQL 加入了一层智能代理层。作用如下 读写分离：只能饭呢西SQL的读写操作，并根据SQL自动做读写分离 负载均衡：自动在多个节点做负载均衡并支持业务自定义负载

问题3：高可用：如何 Recovery 和 Failover。

机器网络故障如何切换读写和只读节点?切换过程中数据是否只读状态？ 只读节点如何转换为读写节点？升级为读写节点的标准是什么？

问题4：IO 模型：如何从 Buffer-IO 向 Direct-IO 优化？

学习中，未完待定....

个人理解

与pg的区别 官方文档给的版本，是基于pg11开发的。

简单学习过程中，发现其与pg11有个很大的区别，是计算和存储做了分离。采用基于 Shared-Storage 的存储计算分离架构,有点类似于oracle的RAC。数据可以存在本地，也可以通过ceph,CurveBS，NDB等分布式存储系统做数据动态扩展。

PolarDB 底层存储在不同节点上是共享的，传统的MPP节点会根据一定的规则，将数据分散到不同的worker节点，上层有个协调节点同步分片规则，维护路由及元数据（类似于postgreSQL原生有个citus插件）。因此不能直接像传统 MPP一样去扫描表 ，polarDB for postgreSQL在执行引擎上做了优化，

学习中，未完待定....

avatar
文章
阅读
粉丝