2018做网站开发一个月工资多少,wordpress默认登录页修改,今天福州发生的重大新闻,dw制作网站教程简介#xff1a;在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力#xff0c;对一套 TP的数据支持两套执行引擎#xff1a;单机执行引擎用于处理高并发的 OLTP#xff1b;MPP跨机分布式执行引擎用于复杂的 OLAP 查询#xff0c;发…简介在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力对一套 TP的数据支持两套执行引擎单机执行引擎用于处理高并发的 OLTPMPP跨机分布式执行引擎用于复杂的 OLAP 查询发挥集群多个 RO 节点的算力和IO吞吐能力。 作者北侠阿里云高级技术专家阿里云PolarDB PostgreSQL云原生数据库HTAP业务和技术负责人。 在 PolarDB 存储计算分离的架构基础上我们研发了基于共享存储的MPP架构步具备了 HTAP 的能力对一套 TP的数据支持两套执行引擎 单机执行引擎用于处理高并发的 OLTPMPP跨机分布式执行引擎用于复杂的 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是无法发挥出整个存储池大带宽的优势。 因为分布式存储底层是有多个盘每个盘都具有读写的能力。如果计算节点成为瓶颈那么底层共享存储池每个盘的能力是无法发挥的 。另外一个问题当只用一个节点来处理复杂 SQL 时其他节点有可能是空闲的因为通常AP的并发是很低的有可能只是几个节点在跑一些固定的报表SQL而其他的节点是处于空闲的状态它的CPU内存还有网络也是没有办法利用起来的。 HTAP 架构 - 基于共享存储的MPP PolarDB 的解决方案是将多个只读节点连在一起实现了基于共享存储的分布式的并行执行引擎用户可以比较灵活地来使用整个系统。比如用某些节点来跑 TP 查询代码路径就走到了单机查询。单机查询的好处是处理点查点写比较快因为它不涉及到分布式事务单机可以很快处理完成。当需要对复杂 SQL 来做计算时可以利用多个只读节点并行执行一个 SQL即分布式的并行执行引擎 MPP 方案。 PolarDB 的 MPP 和传统数据库比如 Greenplum 这类基于分片的 MPP 是有本质区别。比如在某个时间点发现分计算能力不足了PolarDB 可以很快地增加只读节点的个数而且此时整个底层的共享存储数据不需要去做重分布。用过 Greenplum 传统的 share nothing MPP 会知道扩容或缩容是非常大的运维动作。 PolarDB 是存储计算分离的计算节点是无状态的可以通过迅速增加节点让计算能力变得更强大。另外的好处是TP 和 AP 可以做到物理隔离状态保证用户在执行 TP 时不影响AP AP 也不影响 TP。 这套方案实际上是具有一套数据像传统的一些方案支持两套比如将TP的数据导出到另外一套 AP 的系统里面它的数据要拷贝一份同步出过程数据的延迟也是比较大的。而且对资源是一种浪费比如白天跑TP晚上跑AP实际上两个集群只有一个集群在发挥作用。PolarDB 是提供一体化解决方案——在共享存储上用一套数据支持两套计算引擎一个是单机引擎一个是分布式并行的执行引擎。通过共享存储的特性以及在读写节点之间的延迟可以做到毫秒级。相比于传统的通过 TP 数据导到 AP 的系统里面数据新鲜度可以做到毫秒级的延迟。 HTAP 架构原理 如何实现一个并行数据库其核心思想是计划树中引入 Shuffle 算子通过它可以屏蔽掉底层数据分布特性实际上也是 MPP 的工作原理。 那么基于 PolarDB 共享存储会有什么变化因为底层的数据是一个共享的状态比如计划树实际是通过A join B并且对结果做 connt(*)。如果直接把 Greenplum 并行的模式直接在PolarDB 实现一套传统的MPP两个节点同时去执行 AB 的 join 由于A和B对于两个节点来说是共享的都能看到所有数据这两个节点分别 join A 和 B 然后做统计记数最终得到的记数是真实值的两倍。同时 A、B 处理的数据量并没有减少对整个过程没有起到加速的效果。 因此就要去解决怎么样对任何一个表做动态拆分的问题。需要做出并行算子的并行化将原来PG数据库里面所有的 Scan 算子以及 index Scan算子都做并行化。并行化是指可以按照一些固定的策略逻辑上将任何一个表进行切分。切分之后对于整个计划数的上层算子来说是无法感知底层是共享存储的。类似通过Shuffle算子来屏蔽数据分布特征PolarDB通过一系列PXScan并行化扫表算子来屏蔽底层数据的共享特征。这就是HTAP架构上的原理。 从数据库的模块上来看基于共享存储实现MPP需要做什么 第一分布式执行器。因为需要对所有的扫描算子做并行化。接着引入网络因为数据要做交互要做Shuffle还要引入计划管理。第二事务一致性。因为之前 PG数据库的查询是局限于单机的单机查询要通过 MVCC 的多版本的快照来做到事务的一致性。而现在则是把 SQL 分散到不同的阶段去执行不同的节点在回放主库数据的时候是有快有慢的需要去做一次性的控制才能让所有的节点的数据都能集中于统一。第三分布式优化器。分布式优化器是基于社区的GPORCA做二次的架构扩展。GPORCA优化器是模块化的设计。因为现在的底层数据没有分片需要在优化器里面增加一些规则 以此来告诉优化器底层的数据是共享的特性。第四SQL 全兼容。如果要支持一种全新的执行模式那么在SQL的标准里面各个方面都要去做兼容。比如 Left join在单机和分布式下方法是不一样的。如果直接将原生的PG社区的算子放到分布式是有问题的而且有些行为不符合SQL标准。 HTAP - 执行器 HTAP 执行器就是通用 MPP的做法了整体上分成控制链路和数据链路。其中有两种角色PX Coordinato和 PX Worker。PX coordinator去执行优化器的部分然后产生一个分布式的计划数再将计划进行切片分发出去。有可能分发到了 Polar DB集群中其他 RO 节点这些节点拥有一个子计划数通过数据链路汇总到 PX Coordinator最终将数据返回给客户。 HTAP - 弹性扩展 基于共享存储来做MPP有什么样的优势 第一与传统基于share nothing的MPP相比PolarDB 具有更好的弹性。在上图右侧部分把整个MPP的执行路径上所依赖的状态比如元数据的状态以及每个 Worker 运行期的状态都存在了共享存储上。将分布式计算的每个 worker变成 Stateless。它的状态一方面从共享存储上的读取另外一方面来自协调者通过网络发送。这样可以做到无状态化的分布式的执行。就PolarDB 而言数据存到共享存储上原数据存到共享存储的表里面。 运行时的信息比如 worker 被某个SQL 连到 RO1上需要启动8个 worker 来工作8个 worker 分布到RO2和RO3上4个 worker 刚开始启动的时候是不知道任何信息的RO1 将这条 SQL 的相关信息通过网络发送给8个worker这8个worker就可以去执行了。这就是做完全弹性化MPP分布式引擎的思路。此时 Coordinator 节点就变成了无状态化。既可以把 RO1 当作中心化的协调节点也可以把 RO2 当做协调节点这就消除了传统 Greenplum 架构下的单点问题。 第二算力弹性扩展在上图中有四个节点它的业务里面涉及到一些SQL。这些SQL是复杂的查询可以到RO1 和 RO2 上去查。另外一个业务域可以把它的业务拆分成两部分一部分业务可以跑到 RO3 和 RO4 上是可以动态调整的。 PolarDB 性能表现 上图为 Polar DB 分布式并行性能和单机并行的性能的对比第一张图显示了 TPCH 22条 SQL 加速比其中有三条 SQL 的加速比是超过60倍的大部分 SQL 都是超过十倍以上的提升。第二个测试将共享存储上 1TB 的TPCH的数据16个计算节点通过增加 CPU 看性能表现如何。在第二张测试图中从16 core到 256 core基本上是线性提升的表现但是到 256core 就到达瓶颈。这是因为受限于存储带宽如果增加带宽整体的性能还会提升。最下方的图里面显示了22 条 SQL 在16core 到 256core 的性能的表现可以看到在 16core 到 128core 时是线性提升的。 还有一组是 PolarDB 和 Greenplum 的对比。测试环境为相同的硬件16个计算节点1TB TPCH 。从上图中可以看到 Greenplum 有 16core和 16个 CPU 在做 SQL 处理。在采用相同并行度时PolarO 的性能是 Greenplum 的89%。为什么在单核时 Polar 会达不到 Greenplum 的性能表现这是因为数据在共享存储上是没有数据特征的 Greenplum 在建表的时候数据默认做哈希分区在两个表 join 时 join Key 和分布 Key 是一样的不需要做数据的 Shuffle。而 Polar 只有一张表这张表没有数据特征是一个随机分布的数据格式。此时任何两个表去 join 的时候都需要做一个shuffle由于网络因素Polar 单核性能表现只能达到 Greenplum 的89%。针对这个问题我们将通过 PG 的分区表的方式进行优化。 虽然 Polar DB 底层的数据是共享的但仍然可以以哈希的方式建一个分区表。这个时候可以将Polar DB的HTAP MPB的方式和Greenplum的方式对齐一致这个功能实现之后Polar 的单核性能和Greenplum就是一样的。图中红框部分我们又进行了四组测试Polar DB 支持计算能力弹性扩展此时数据是不需要重新分布的。这是数据随机分布的好处在做分布式执行引擎的时候第一优先级考虑的不是极致的性能而是是系统的扩展性即当你的计算能力不足的时候可以快速增加节点来加速计算。 像 Greenplum 这类传统的 MPP 数据库它的节点是固定而Polar是无状态的可以随时去做调整计算CPU数的。这组测试里面只需要调整一个GUC参数就能将Polar从16core变成256core算力线性扩展。 当 Polar DB 支持了MPP之后还能做哪些事情新上线的业务导入了大量的数据之后需要做一些索引。其原理是先将数据进行排序之后在内存里组织成一个索引页面然后将这些页面直接写到盘上。如果Polar DB 支持并行之后玩法就不一样了从上图中可以看到通过节点 RO1、RO2 和 RO3可以并行地到共享存储上去扫描数据然后并行地在本地进行排序。排完序之后将数据通过网络传给RW节点。RW节点经过归并排序将排序的数据在内存里面组织成一个索引页交给btbuild进程。在内存里面通过索引页去更新索引页之间的指向关系来构建索引树的指令关系然后开始写盘。 这个方案借助了多个节点的计算能力以及 RO 能力在排序的阶段进行了加速。同时通过网络传给MPP 的一个QC节点即中心节点。这个节点再通过共享内存发给 btbuild 进程。经测试使用500G的数据来建索引性能可以提升到五倍左右。 加速时空数据库 时空数据库是一个计算密集型的、用 RTree 索引的粗过滤。先通过RTree然后通过空间踩点定位到一个区域在这个区域里面再进一步精确的过滤。共享存储的 index scan 的过程RTree 扫描只能用NestLoopIndex Join因为是没有办法做哈希join的这是因为 RTree 的二维空间没有办法做完整的切分。对于时空的业务都是通过 NestLoopIndex Join从一个表里面拿到一个数据然后到另外一个表里面的 RTree上扫描这在 Greenplum上是无法做到的因为它的索引树是被拆分的。但是在 PolarDB 里面RTree的索引树是共享状态那么无论 worker 是在节点1还是在节点2上在共享里存储理念里索引树都是完整的。这个时候两个worker就可以直接用外表做协调的切分。由于它是计算密集型的那么它的加速效果会更加的好。经过测试在80 CPU 的环境下整体的提升能达到71倍。 以上就是关于 HTAP 架构的介绍后续将会有更多实现上的细节分享比如优化器、执行器、分布式一致性等敬请期待。 原文链接 本文为阿里云原创内容未经允许不得转载。