PolarDB for PostgreSQL 内核解读：HTAP架构介绍

在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力，对一套 TP的数据支持两套执行引擎：

• 单机执行引擎用于处理高并发的 OLTP
• MPP跨机分布式执行引擎用于复杂的 OLAP 查询，发挥集群多个 RO 节点的算力和IO吞吐能力

本文整理自《开源学堂：PolarDB for PostgreSQL 内核解读 —— HTAP架构介绍》直播分享。

存储计算分离架构

首先我们先来了解一下 PolarDB 的架构，从上图中可以看到，左侧是计算存储一体化，传统的数据库的存储是存在本地的。右侧是 PolarDB 存储计算分离架构，底层是共享存储，可以挂任意多个计算节点。计算节点是无状态的，可以很好地做一个扩展，另外可以降低成本，比如用户可以扩展到16个节点，但底层存储还是一份存储（3副本）。

分布式存储是比较成熟的存储解决方案，自带存储的高可用，秒级备份，像 Ceph、PolarStorage，都是比较成熟的存储解决方案。把社区单机的 PostgreSQL 数据库，直接跑在一个共享存储设备上，是不是可以认为是PolarDB 呢？答案是不可以直接这么做，根本原因是在这套架构下有一份存储，但是计算节点有N个，计算节点之间需要协调。

存储计算分离的架构需要解决的问题，首先是一致性问题，1份存储+N份计算。第二，读写分离，在这个架构上做低延迟的复制。第三，高可用，解决怎么样去做快速的恢复。第四，IO 模型发生了变化，分布式文件系统是没有实现cache，可以把省下来的内存直接给数据库的 BufferPool 使用。

HTAP 架构 - 存储计算分离处理AP查询的挑战

在这个架构下，如果用户需要跑一些分析型的查询，可以举个实际例子，比如像电信计费系统，白天处理用户的充值、各种积分的结算，像这样的请求，都会带有 UserID，通过索引可以精确地定位到修改的页面。在晚上会跑一些批量的分析，比如做对账，在不同的维度去统计省、市，统计整体的销售情况。存储计算分离的架构在处理大查询上，把 SQL 通过读写分离，将 SQL 动态地负载到负载较低的节点上。

这个节点在处理复杂 SQL 时，PG 数据库具备单机并行的能力，虽然单机并行处理复杂 SQL 比单机的串行有很大的提升，但在单机并行下内存和 CPU 还是有一定局限性，在这种架构下处理复杂 SQL 只能通过 Scale Up 的方式来加速。也就是说如果发现 SQL 处理得比较慢，就只能增加 CPU，增加内存，找一个配置更高的机器来当只读节点。而且单一节点来处理一个复杂SQL，是无法发挥出整个存储池大带宽的优势。

因为分布式存储底层是有多个盘，每个盘都具有读写的能力。如果计算节点成为瓶颈，那么底层共享存储池，每个盘的能力是无法发挥的 。另外一个问题