pg 分布式 green pg是分布式数据库吗

支持空间索引的分布式数据库调研

文章目录

• 支持空间索引的分布式数据库调研

• OLAP 分布式架构对比
• 一. Postgres-XL
• 二. clickhouse
• 三. Greenplum架构
• 四. Vertica
• 五. Amazon Redshift
• 六. CitusDB

OLAP 分布式架构对比

Product	OLAP	列式存储	Open Source	Base on postgre	Use MPP	Support postgis	Fail over
Postgres-XL	Y	N	Y	Y	Y	仅支持2.0，不支持2.4引入的ST_AsGeoBuf，	Week
Greenplum	Y	Y	Y	Y	Y	部分支持，不支持ST_AsGeoBuf，	Strong
Vertica	Y	Y	Y	N	Y	支持ST_Intersects，不支持ST_AsGeoBuf, 仅支持转为GeoJson	Strong
clickhouse	Y	Y	Y	兼容，几何类型需改造	Y	N	Strong
Amazon Redshift	Y	Y	N	基于，但是差别很大	Y	支持ST_Intersects，不支持ST_AsGeoBuf, 仅支持转为GeoJson	Strong
CitusDB	Y	Y	Y	Y	Y	部分sql不支持，支持ST_AsGeoBuf，但无法下推到worker，此函数在master执行，瓶颈取决于master节点性能	Strong

一. Postgres-XL

Postgres-XL是一款开源的PG集群软件，XL代表eXtensible Lattice，即可扩展的PG“格子”之意，以下简称PGXL。官方称其既适合写操作压力较大的OLTP应用，又适合读操作为主的大数据应用。它的前身是Postgres-XC（简称PGXC），PGXC是在PG的基础上加入了集群功能，主要适用于OLTP应用；PGXL是在PGXC的基础上的升级产品，加入了一些适用于OLAP应用的特性，如 Massively Parallel Processing (MPP) 特性。通俗的说PGXL的代码是包含PG代码的，使用PGXL安装PG集群并不需要单独安装PG。这样带来的一个问题是无法随意选择任意版本的PG，好在PGXL跟进PG较及时，目前最新版本Postgres-XL 9.5 R1.3，基于PG 9.5。

三者的关系大致如下图

总体感觉PGXL这款工具还是相当成熟的，有官方网站http://www.postgres-xl.org/，文档也比较完善，也有商业公司2ndQuadrant在支持。下图是PGXL和PG在OLAP方面的性能对比，来自2ndQuadrant官网：

集群架构

上面这张图就是PGXL集群的架构图，来自官方网站。所有节点中分为三种角色：GTM（全局事务管理器）、Coordinator（协调器）和Datanode（数据节点）。需要注意一点是图中的Load Balance组件并不属于PGXL集群本身，需要其他负载均衡工具实现。

这个架构和citus优点类似，也是分为协调节点和数据节点，数据也是通过hash分布到不同数据节点上，只是在集群中增添了全局事务管理组件，保证全局事务的一致性。

原文網址：https://kknews.cc/code/pbnq5ae.htmlGTM：
全局事务控制节点，保证集群数据的一致性，与Coordinator节点和Datanode节点不断通信，是整个集群的核心节点，只存在一个，可以存在一个GTM Standby节点，对GTM实时备份。GTM一旦故障，整个集群立刻无法访问，此时可以切换到GTM Standby节点上。如果部署了GTM Standby节点，就应该同时部署GTM Proxy，一般和Coordinator、Datanode部署在同一台服务器上。GTM Proxy的作用代理Coordinator和Datanode对GTM的访问，起到减轻GTM负载的作用，另外一个重要的作用是帮助完成GTM的故障切换，当GTM节点发生故障后，GTM Standby成为新的GTM，此时Coordinator和Datanode节点并不需要重新指定GTM地址，只需要GTM Proxy重新连接到新的GTM地址即可。
Coordinator：
接收数据访问请求的节点，本质上是由PG后台进程组成。接收的一条查询后，Coordinator节点执行查询计划，然后会根据查询数据涉及的数据节点将查询分发给相关的数据节点。写入数据时，也会根据不同的数据分布策略将数据写入相关的节点。可以说Coordinator节点上保存着集群的全局数据位置。Coordinator节点可以任意扩展，各个节点之间除了访问地址不同以外是完全对等的，通过一个节点更新的数据可以在另一个节点上立刻看到。每个Coordinator节点可以配置一个对应的standby节点，避免单点故障。
Datanode：
实际存取数据的节点，接收Coordinator的请求并执行SQL语句存取数据，节点之间也会互相通信。一般的，一个节点上的数据并不是全局的，数据节点不直接对外提供数据访问。一个表的数据在数据节点上的分布存在两种模式：复制模式和分片模式，复制模式下，一个表的数据在指定的节点上存在多个副本；分片模式下，一个表的数据按照一定的规则分布在多个数据节点上，这些节点共同保存一份完整的数据。这两种模式的选择是在创建表的时候执行CREATE TABLE语句指定的，具体语法如下：

CREATE TABLE table_name(...)
DISTRIBUTE BY 
HASH(col)|MODULO(col)|ROUNDROBIN|REPLICATION
TO NODE(nodename1,nodename2...)

可以看到，如果DISTRIBUTE BY 后面是REPLICATION，则是复制模式，其余则是分片模式，HASH指的是按照指定列的哈希值分布数据，MODULO指的是按照指定列的取摩运算分布数据，ROUNDROBIN指的是按照轮询的方式分布数据。TO NODE指定了数据分布的节点范围，如果没有指定则默认所有数据节点参与数据分布。如果没有指定分布模式，即使用普通的CREATE TABLE语句，PGXL会默认采用分片模式将数据分布到所有数据节点。

pgxc的架构特点如下：

①gtm保证全局读一致性，两阶段提交保证全局写一致性。

②gtm是整个系统的瓶颈点，在超过150并发的情况下，gtm的瓶颈就会显现，每一个事务开启都会去gtm取事务号和快照信息，造成gtm在网络压力和分配事务号速度上存在瓶颈。

③多个协调节点间需要同步元数据信息，如果协调节点失败，不仅会造成ddl hang住，也可能造成两阶段事务的阻塞。

④pgxc的出现主要是在pg在oltp应用场景上的优化，不管是新增gtm，还是数据一致性的保证上面都做得更加精细化。

⑤和citus类似，数据表也可以分为分布表和复制表，复制表在每一个数据节点都有一份全量数据。

二. clickhouse

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

优点:

1. 并行处理单个查询（利用多核）;
2. 在多个服务器上分布式处理;
3. 非常快的扫描，可用于实时查询;
4. 良好的压缩特性;
5. 一系列函数的支持，包括对近似计算的支持;
6. 不同的存储引擎的支持（磁盘存储格式）;

缺点:

1. 不支持实时的删除/更新操作，删除和更新需要全表重写；
2. 不支持事务；
3. 不支持二级索引；
4. 表关联只能等值关联；
5. 不支持merge等操作；
6. 不支持窗口函数；
7. 不支持自定义函数；
8. 不支持查看执行计划；

2) 列式存储与数据压缩

在传统的行式数据库系统中，数据按如下顺序存储：

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

在列式数据库系统中，数据按如下的顺序存储：

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

列式存储和数据压缩，对于一款高性能数据库来说是必不可少的特性。想让查询变得更快，最简单且有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储和数据压缩就可以帮助我们实现上述两点。由于Clickhouse是真正意义上的列式存储，每一列都在不同的文件下，所以该文件数据类型一致，可以更有效的压缩。

3) 向量化执行引擎

向量化执行以列存为前提，主要思想是每次从磁盘上读取一批列，这些列以数组形式组织。每次next都通过for循环处理列数组。这么做可以大幅减少next的调用次数。相应的CPU的利用率得到了提高，另外数据被组织在一起。

可以进一步利用CPU硬件的特性，如SIMD，将所有数据加载到CPU的缓存当中去，提高缓存命中率，提升效率。在列存储与向量化执行引擎的双重优化下，查询执行的速度会有一个非常巨大的飞跃。

4) 关系模型与SQL查询

ClickHouse是一个关系型数据库。它几乎可以支持近百分之九十的sql作为查询语句，比如group by，order by等。

5) 多样化的表引擎

ClickHouse和mysql一样，也将存储部分进行了抽象，把存储引擎作为一层独立的接口。所以说Clickhouse实现了很多种表引擎，比如mergetree，log，memory等类型的引擎，每一种表引擎都有着各自的特点，用户可以根据实际业务场景的要求，选择合适的表引擎使用。

6) 多线程与分布式
ClickHouse几乎具备现代化高性能数据库的所有典型特征，对于可以提升性能的手段可谓是一一用尽，对于多线程和分布式这类被广泛使用的技术，自然更是不在话下。

7) 多主架构

HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则由于它的集群架构和其他数据库不同，这种架构使得它是一个多主架构。

8) 在线查询

ClickHouse采用了LSM树结构，所以使得Clickhouse的插入量可以很大。同时，Clickhouse的内部优化，使得在复杂查询的场景下，它也能够做到极快响应，且无须对数据进行任何预处理加工。达到了实时数仓的效果

9) 数据分片与分布式查询

Clickhouse拥有分布式能力，自然支持数据分片，数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段。ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表 ( Local Table ) 与分布式表 ( Distributed Table ) 的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。

三. Greenplum架构

Greenplum主要由Master节点、Segment节点、interconnect三大部分组成。Greenplum master是Greenplum数据库系统的入口，接受客户端连接及提交的SQL语句，将工作负载分发给其它数据库实例（segment实例），由它们存储和处理数据。Greenplum interconnect负责不同PostgreSQL实例之间的通信。Greenplum segment是独立的PostgreSQL数据库，每个segment存储一部分数据。大部分查询处理都由segment完成。

Master节点不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据

Segment节点负责数据的存储，可以对分布键进行优化以充分利用Segment节点的io性能来扩展整集群的io性能

Greenplum架构特点如下：

①master节点可以做主备，segment节点也有镜像保证高可用，segment主备尽量混布到不同服务器上。

②支持行列混合存储引擎，同时支持外部表。

③在join时也涉及到数据跨节点重分布的问题，这也是share nothing数据库不可避免的问题。

④高速内部interconnect网络，实现数据join时的高速移动和汇总。

⑤高效的数据并行加载。

四. Vertica

Vertica是一款基于列存储的MPP（massively parallel processing）架构的数据库。它可以支持存放多至PB（Petabyte）

级别的结构化数据。

Vertica数据库属于无Master的MPP架构，所有节点均可访问使用，当然其也提供了负载均衡，以保障节点的合理使用

文档：https://www.vertica.com/docs/9.2.x/HTML/Content/Home.htm?tocpath=Welcome%20to%20the%20Vertica%209.2.x%20Documentation%7C_____0

五. Amazon Redshift

此部分介绍 Amazon Redshift 数据仓库架构的元素，如下图所示。

客户端应用程序

Amazon Redshift 与各种数据加载和 ETL（提取、转换和加载）工具以及商业智能 (BI) 报告、数据挖掘和分析工具集成。Amazon Redshift 基于行业标准 PostgreSQL，因此，大多数现有 SQL 客户端应用程序仅处理最少量的更改。有关 Amazon Redshift SQL 和 PostgreSQL 之间的重要差异的信息，请参阅。Amazon Redshift。

连接

Amazon Redshift 通过使用行业标准 PostgreSQL JDBC 和 ODBC 驱动程序与客户端应用程序进行通信。有关更多信息，请参阅 Amazon Redshift 和 PostgreSQL JDBC 以及 ODBC。

集群

Amazon Redshift 数据仓库的核心基础设施组件是集群。

集群包含一个或多个计算节点。如果集群预置有两个或更多计算节点，则一个额外的领导节点 将协调这些计算节点并处理外部通信。您的客户端应用程序仅直接与领导节点交互。计算节点对于外部应用程序是透明的。

领导节点

领导节点管理与客户端程序的通信以及与计算节点的所有通信。它分析和制定执行计划以实施数据库操作，特别是获得复杂查询的结果所需执行的一系列步骤。根据执行计划，领导节点编译节点、将编译后的节点分发给计算节点，并将部分数据分配给每个计算节点。

领导节点仅在查询引用计算节点上存储的表时，才将 SQL 语句分发给计算节点。所有其他查询仅在领导节点上运行。Amazon Redshift 仅在领导节点上实施特定 SQL 函数。如果使用这些函数中的任一函数的查询引用驻留在计算节点上的表，则此查询将返回一个错误。有关更多信息，请参阅 在领导节点上支持的 SQL 函数。

计算节点

领导节点为执行计划的单个元素编译代码并将代码分配给各个计算节点。计算节点执行编译后的代码，并将中间结果发送回领导节点以便最终聚合。

每个计算节点均拥有自己的专用 CPU、内存和连接的磁盘存储，这都由节点类型决定。当您的工作负载增加时，您可以通过增加节点数和/或升级节点类型来增加集群的计算容量和存储容量。

Amazon Redshift 提供了多种节点类型以满足您的计算和存储需求。有关每个节点类型的详细信息，请参阅。Amazon Redshift 群集中的Amazon Redshift 群集管理指南。

节点切片

一个计算节点分为多个切片。将为每个切片分配节点的内存和磁盘空间的一部分，从而处理分配给节点的工作负载的一部分。领导节点管理向切片分发数据的工作，并将任何查询或其他数据库操作的工作负载分配给切片。然后，切片将并行工作以完成操作。

每个节点的切片数由集群的节点大小决定。有关每个节点大小的切片数的更多信息，请转到关于集群和节点中的Amazon Redshift 群集管理指南。

在创建表时，您可以选择将一个列指定为分配键。在将表与数据一起加载时，会根据为表定义的分配键将行分配给节点切片。选择好的分配键使 Amazon Redshift 能够使用并行处理来加载数据和高效执行查询。有关选择分配键的信息，请参阅选择最佳的分配方式。

内部网络

Amazon Redshift 利用高带宽连接、紧邻和自定义通信协议来提供领导节点和计算节点之间的速度极快的私有网络通信。计算节点在客户端应用程序绝对无法直接访问的独立的、隔离网络上运行。

数据库

一个集群包含一个或多个数据库。用户数据存储在计算节点上。您的 SQL 客户端与领导节点进行通信，进而通过计算节点协调查询执行。

Amazon Redshift 是一个关系数据库管理系统 (RDBMS)，因此与其他 RDBMS 应用程序兼容。虽然提供了与典型 RDBMS 相同的功能（包括在线事务处理 (OLTP) 功能，例如，插入并删除数据），但 Amazon Redshift 已经过优化，可对大型数据集进行高性能的分析和报告。

Amazon Redshift 基于 PostgreSQL。Amazon Redshift 和 PostgreSQL 之间的差别非常大，您在设计和开发数据仓库应用程序时需要注意这一点。有关 Amazon Redshift SQL 与 PostgreSQL 之间的差异的信息，请参阅。Amazon Redshift。

不支持的PostgreSQL functions：

https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-functions.html

六. CitusDB

参考网站： https://kknews.cc/code/pbnq5ae.html

CitusDB 是一个基于最新 PostgreSQL 构建的分布式数据库。CitusDB 可对 PostgreSQL 数据库进行伸缩以适合大数据的处理。可在集群中进行自动分片和碎片复制，运行在云端或者混合系统中。数据库的查询可在集群中进行分布式处理，充分利用集群中每个节点的计算能力。CitusDB 可提升 PostgreSQL 的高并发性和 JSON 支持，可用作事务以及分析数据库场景。

CitusDB 将你的数据库在集群中进行分布，对你的应用来说 CitusDB 就像是一个单一节点的 PostgreSQL 服务，对应用来说是透明的。集群中可轻松添加节点。

CitusDB 可将查询分布到集群中的每个节点，可用于快速处理查询以及并行处理。这比单一节点的 PG 数据库速度要快很多，理论上在20个节点的集群里运行速度是单一节点的 20 倍。

CitusDB 基于最新版本的 PG 数据库构建，是一个PostgreSQL 的扩展，因此应用可以无缝的切换到 CitusDB 上。

CitusDB 支持多租户，可以通过租户id把对应租户的数据放在同一个node上，避免跨库事务。

CitusDB 架构：

Ciitus的主要架构特点如下：

①有两种表类型：参考表和分布表，参考表每个协调节点和worker节点都有一份完整的副本，分布表则会打散分布到不同worker中。

②可以进行读写分离，如上图cn1为写节点，可以通过再增加多个cn读节点增加集群读的能力，写cn和读cn之间使用流复制进行元数据同步。

③支持MX模式，可以将元数据也存在某些worker节点中，这样使得该worker节点能够直接提供写的能力，以此增加集群写的能力。

④底层worker节点可以通过流复制搭建副本，保证数据高可用。

⑤做join时最好的结果是能够将计算下推到worker节点，但是只有在参考表和其他表做join以及两个表的分布方式相同的情况下才能下推到worker计算，否则需要将数据拉到协调节点进行计算。

⑥整体架构类似mycat的中间件，因为没有全局事务管理，故不能保证数据的实时读一致性，但是性能上相比要好。数据写一致性使用2pc来保证。

citus限制：

1. 子查询支持非常有限
   Correlated subqueries are supported only when the correlation is on the Distribution Column and the subqueries conform to subquery pushdown rules (e.g., grouping by the distribution column, with no LIMIT or LIMIT OFFSET clause).
2. 视图支持非常有限
   Postgresql用视图的实际定义替换查询中的视图引用。由于Citus对子查询有部分支持，因此视图支持也很有限。
3. 支持ST_AsGeoBuf(),但是无法下推到worker去执行，瓶颈还是在master节点的cpu配置上
4. 指定进行hash分片的参考字段必须是某个唯一索引的一部分
   Currently Citus imposes primary key constraint only if the distribution column is a part of the primary key. To elaborate if only a single column constitutes the primary key then the distribution key has to be that column and if more than one column constitute the primary key, the distribution key should be any one of those columns.This assures that the constraint needs to be checked only on one shard(the shard where the insert happens) to ensure uniqueness.
5. 如果定义表为参考表，则在执行sql查询此表时不会进行优化，直接选择某个worker执行。参考表的作用是对于小表或者常用join表提高worker上join的性能，避免所有数据给到master进行join操作
6. SQL限制—查询
   Citus最大的缺陷在于有着SQL限制，并不是所有SQL都支持。最典型的就是对Join的限制，它不支持2个非亲和分片表的outer join，仅task-tracker执行器支持2个非亲和分片表的inner join，对分片表和参考表的outer join，参考表只能出现在left join的右边或right join的左边。对子查询也有着限制，子查询不能参与join，不能出现order by，limit和offset。一些SQL特性Citus同样不支持，比如CTE、Window函数、集合操作、非分片列的count(distinct)。最后还有一点需要注意，即本地表不能和分片表(参考表)混用。
   这些限制其实都可以使用某些方法绕过，比如通过Hll(HyperLogLog)插件支持count(distinct)，对于其他的一些操作也可以通过临时表或dblink中转。不过临时表的问题在于会将一个SQL拆成多个SQL。
7. SQL限制—更新
   在更新上也存在一些限制，它不支持跨分片的更新SQL和事务，‘insert into … select … from …’的支持存在部分限制，插入源表和目的表必须是具有亲和性的分片表，不允许出现Stable and volatile函数，不支持LIMIT，OFFSET，窗口函数，集合操作，Grouping sets，DISTINCT。
   当然这些限制也存在对应的回避方法，首先是使用copy代替insert，其次是用SELECT master_modify_multiple_shards(‘…’)实现扩分片更新。
8. SQL限制—DDL

上图展示的是对DDL的支持情况，这里面大部分都是支持的，对于不支持的可以通过创建对等的唯一索引代替变更主键，或者使用run_command_on_placements函数，直接在所有分片位置上执行DDL的方式来进行回避。