Citus集群拓扑架构介绍

2022-04-13 00:00:00 数据 支持 节点 复制 副本

作者:杨杰

简介

Citus是Postgres的开源扩展,将Postgres转换成一个分布式数据库,在集群的多个节点上分发数据和查询,具有像分片、分布式SQL引擎、复制表和分布式表等特性。

因为Citus是Postgres的扩展(而不是一个独立的代码分支),所以当你使用Citus时,你也在使用Postgres,可以利用新的Postgres特性、工具和生态系统。

架构节点

每个集群都有一个称为协调节点(Coordinator Node,CN)的特殊节点,其他节点称为工作节点(Worker Node,WN/DN)。

CN只存储和数据分布相关的元数据,实际的表数据被分成M个分片,打散到N个DN上。

应用程序将它们的查询发送到协调器节点,该节点将查询转发给相关的数据节点并收集结果。

注:以上以分布式表为例

集群拓扑

首先介绍原生Citus支持的几种集群拓扑

statement-based replication

为了提高可用性,协调节点通过PG原生流复制实现多副本,数据节点通过基于语句复制实现表级别的副本,副本数由参数shard_replication_factor = 2控制。

基于语句复制存在的问题就是,如果子表非常多,SQL数量成比例增长,压力增加,同时,当子表出现问题时,会标记为非活跃状态,涉及与协调节点通信变更元数据,如果出问题的子表很多,性能自然不会好,相应还会带来副本修复的问题。

用Raft来做数据复制,每个数据变更都会落地为一条Raft日志,通过Raft的日志复制功能,将数据安全可靠地同步到复制组的每一个节点中。不过在实际写入中,根据Raft的协议,只需要同步复制到多数节点,即可安全地认为数据写入成功。

相比PG本身的主从副本,开发成本比较大,目前Citus已经建议从基于语句的复制切换到流式复制,参数replication_model = 'streaming'

streaming replication

协调节点及数据节点都通过流复制实现多副本,保证可用性。

数据节点副本同步使用PG流复制,提高分片上的写入速度。

协调节点属于Master-Standby架构,仅CN节点支持数据写入,势必会有单点可入瓶颈。

另外,默认CN-Stanby的查询发往DN-Primary节点,协调节点虽然做了读写分离,但底层请求都发给了DN-Primary,DN-Standby仅仅充当了备份副本。

对此,Citus还提供了两个参数以支持写入能力扩展及数据节点读写分离。

use_secondary_node

开启use_secondary_node = always,读请求可以发往数据节点备节点。

writable_standby_coordinator

开启writable_standby_coordinator = on

Enables simple DML via a streaming replica of the coordinator

这个参数的作用就是使CN-Standby也支持DML,比如Insert、Copy等操作。

除了通过writable_standby_coordinator参数支持多节点DML,Citus还提供了MX架构。

Citus MX

通过MX架构,数据节点同时存储用户数据及元数据,数据读写能力得到了水平扩展。

对于MX架构,数据节点支持存储元数据以支持读写请求,同时也增加了数据节点的压力,对此可以考虑计算存储分离架构。

Citus支持通过函数master_set_node_property设置节点的shouldhaveshards属性,控制DN节点不放分片,专门用于分担CN负载。

至此,便是目前Citus原生支持的几种集群拓扑。

计算存储分离+读写分离

原生Citus仅支持在CN-Master执行DDL操作,通过实现保障数据一致性的多点DDL方案,CN节点不在区分节点角色,可在任一CN节点执行DDL+RW。

除此之外,不再通过参数控制决定读写分离,直接根据Query类型做读写分离,将读请求发送到DN-Standby。

相关文章