PolarDB PostgreSQL版（以下简称 PolarDB-PG）是一款阿里云自主研发的企业级数据库产品，采用计算存储分离架构，兼容 PostgreSQL 与 Oracle。PolarDB-PG 的存储与计算能力均可横向扩展，具有高可靠、高可用、弹性扩展等企业级数据库特性。同时，PolarDB-PG 具有大规模并行计算能力，可以应对 OLTP 与 OLAP 混合负载；还具有时空、向量、搜索、图谱等多模创新特性，可以满足企业对数据处理日新月异的新需求。
消除数据倾斜问题
倾斜是传统 MPP 固有的问题：
- 在 PolarDB-PG 中，大对象的是通过 heap 表关联 TOAST 表，无论对哪个表切分都无法达到均衡。
- 另外，不同只读节点的事务、buffer、网络、IO 负载抖动。
以上两点会导致分布执行时存在长尾进程。
- 协调节点内部分成 DataThread 和 ControlThread。
- DataThread 负责收集汇总元组。
- ControlThread 负责控制每个扫描算子的扫描进度。
- 扫描快的工作进程能多扫描逻辑的数据切片。
- 过程中需要考虑 Buffer 的亲和性。
需要注意的是：尽管是动态分配，尽量维护 buffer 的亲和性；另外，每个算子的上下文存储在 worker 的私有内存中，Coordinator 不存储具体表的信息；
下面表格中，当出现大对象时，静态切分出现数据倾斜，而动态扫描仍然能够线性提升。
SQL 级别弹性扩展
那我们利用数据共享的特点，还可以支持云原生下极致弹性的要求：把 Coordinator 全链路上各个模块所需要的外部依赖存在共享存储上，同时 worker 全链路上需要的运行时参数通过控制链路从 Coordinator 同步过来，使 Coordinator 和 worker 无状态化。
因此：
- SQL 连接的任意只读节点都可以成为 Coordinator 节点，这解决了 Coordinator 单点问题。
- 一个 SQL 能在任意节点上启动任意 worker 数目，达到算力能 SQL 级别弹性扩展，也允许业务有更多的调度策略：不同业务域同时跑在不同的节点集合上。
事务一致性
多个计算节点数据一致性通过等待回放和 globalsnapshot 机制来完成。等待回放保证所有 worker 能看到所需要的数据版本，而 globalsnapshot 保证了选出一个统一的版本。
TPC-H 性能：加速比
我们使用 1TB 的 TPC-H 进行了测试，首先对比了 PolarDB-PG 新的分布式并行和单机并行的性能：有 3 个 SQL 提速 60 倍，19 个 SQL 提速 10 倍以上；
另外，使用分布式执行引擎测，试增加 CPU 时的性能，可以看到，从 16 核和 128 核时性能线性提升；单看 22 条 SQL，通过该增加 CPU，每个条 SQL 性能线性提升。
TPC-H 性能：和传统 MPP 数据库的对比
与传统 MPP 数据库相比，同样使用 16 个节点，PolarDB-PG 的性能是传统 MPP 数据库的 90%。
前面讲到我们给 PolarDB-PG 的分布式引擎做到了弹性扩展，数据不需要充分重分布，当 dop = 8 时，性能是传统 MPP 数据库的 5.6 倍。
分布式执行加速索引创建
OLTP 业务中会建大量的索引，经分析建索引过程中：80%是在排序和构建索引页，20%在写索引页。通过使用分布式并行来加速排序过程，同时流水化批量写入。
上述优化能够使得创建索引有 4~5 倍的提升。
分布式并行执行加速多模：时空数据库
PolarDB-PG 是对多模数据库，支持时空数据。时空数据库是计算密集型和 IO 密集型，可以借助分布式执行来加速。我们针对共享存储开发了扫描共享 RTREE 索引的功能。
- 数据量：40000 万，500 GB
- 规格：5 个只读节点，每个节点规格为 16 核 CPU、128 GB 内存
- 性能：
- 随 CPU 数目线性提升
- 共 80 核 CPU 时，提升71 倍
总结
本文从架构层面分析了 PolarDB-PG 的技术要点：
- 存储计算分离架构。
- HTAP 架构。
后续文章将具体讨论更多的技术细节，比如：如何基于 Shared-Storage 的查询优化器，LogIndex 如何做到高性能，如何闪回到任意时间点，如何在 Shared-Storage 上支持 MPP，如何和 X-Paxos 结合构建高可用等等，敬请期待。
