PostgreSQL 数据库在分布式场景下的架构

能否给张PostgreSQL数据库在分布式场景下的架构？

问题来自社区会员@邓毓 某农信 系统工程师，回答来自社区交流，供同行参考

@priest 系统架构师：

目前，主要流行的就3种：Citus 、 Pgxc/Pgxl 、 Greenplum

@zhuqibs Mcd 软件开发工程师：

以下引用自公众号“数据库架构之美”文章：(1) Citus

以插件的方式扩展到postgresql中，独立于postgresql内核，所以能很快的跟上pg主版本的更新，部署也比较简单，是现在非常流行的分布式方案。Citus在苏宁有大规模应用，微软也提供citus的商业支持。下面是citus的架构

(2) pgxc && pgxl

是经典的分布式数据库架构，是真正的企业级HTAP，我们看到市面上很多分布式数据库产品都是基于pgxc架构扩展而来。pgxc是和pg内核紧耦合的，是嵌入到pg内核中，最初pgxc的核心开发者将pgxc商业化，创建了stormdb，进行了一些并行算子优化，后来TransLattice公司将stormdb收购，并且将项目开源，就是现在的pgxl，所以pgxc和pgxl是一脉相承的，大部分代码是直接移植过来的。下面是pgxc的架构

(3) Greenplum

是pivotal公司推出的一款开源olap的mpp数据库，greenplum的用户在某种程度上甚至超越了pg，很多人可能是通过greenplum才认识的pg，可见greenplum的风靡。下面是greenplum架构

@weibo 北京象前行信息科技有限公司 副总：

来张比较流行的GP架构：

在分布式数据库中，无论是share-disk，share-memory，还是share-nothing的结构，数据库高可用性能主要实现方案都是通过节点冗余的方式，greenplum是采用share-nothing的MPP架构，其高可用也是通过给每个节点（master节点和所有的segment节点）设置一个冗余节点来实现的。

目前GP版本基于PG 9.6

Master 主节点冗余通过物理流复制实现。

每个segment都有一个热备份（hot standby）称为segment mirror。

Master节点能够检测到primary segment的状态，当primary segment不能继续提供服务时，会主动激活mirror segment成为新的primary。正常情况下primary segment处于active状态，primary segment和mirror segment之间的数据同步是通过两种方式：

（1） 数据同步复制

primary segment上，在事务commit之前，把事务的commit log同步到mirror segment上，同步结束以后，primary segment才做真正的commit。这样当mirror segment被提升成primary后，能够保证事务的一致性。

（2） 物理文件复制

堆表使用物理文件复制。GP中表数据是由元组组成的一个固定大小的块文件存储在磁盘上，为了优化磁盘I/O，块文件会被存储到缓冲区，当缓冲区满了之后会被新更新的块文件替换，被替换出来的块文件被写到primary segment的磁盘上，同时通过网络复制到mirror segment上，Mirror segment只更新其文件副本中的相应块。当块保存在缓存中时，primary segment和mirror segment具有不同的块镜像，但是数据库仍然是一致的，因为事务日志已经被复制了。

@Amygo 分布式事务数据库 数据库管理员：

PG的分布式基本上都是pgxl、pgxc的架构模式，可以看下开源产品AntDB。我正在写一篇文章关于PG VS MySQL为何PG不适合OLTP业务场景的原因，核心是没有真正的 MVCC，在做UPDATE/DELETE的时候很吃亏。

另外，使用OLTP分布式数据库产品后，则数据库端没有业务计算的包、自定义函数、存储过程、视图，甚至连复杂子查询都没有，则PG的内部机制就会显得更加笨重，不如MySQL走的轻量型路线高效和处理快。

欢迎点击文末阅读原文到社区讨论交流，发表您的观点

觉得本文有用，请转发或点击“在看”，让更多同行看到

 资料/文章推荐：

欢迎关注社区以下  “PostgreSQL”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/112101

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场