初识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集群自己，须要其余负载均衡工具实现。
GTM：
全局事务控制节点，保证集群数据的一致性，与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会默认采用分片模式将数据分布到全部数据节点。

这篇就先写到这里，下一篇写一下安装与配置。

参考资料：
http://www.postgres-xl.org/
https://2ndquadrant.com/en/re...
http://www.slideshare.net/mas...