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

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

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

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

存储计算分离架构

PolarDB for PostgreSQL 内核解读:HTAP架构介绍_第1张图片

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

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

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

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

PolarDB for PostgreSQL 内核解读:HTAP架构介绍_第2张图片

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

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

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

你可能感兴趣的:(架构,postgresql,系统架构)