PostgreSQL Replication之第十二章与Postgres-XC一起工作（4）

12.4 性能优化

Postgres-XC不是一个奇特的PostgreSQL版本，而是一个真正的分布式系统。这意味这，您不能只存储数据，希望事情超出服务器之外的快速，高效。如果您想优化速度，思考数据是如何在幕后存储的，以及查询是如何执行的是非常有益的。

当然，您可以只加载数据，事情也会工作，但，如果性能真的是一个问题，您真的应该去想想如何利用您的数据。请记住，如果您的负载较低的话，使用一个分布式数据库系统是没有意义的。因此，如果您是一个Postgres-XC使用者，我们希望您的负载和您的要求非常高。

12.4.1 调度表

最重要的一个问题是数据存储在哪里。Postgres-XC不会知道您打算用您的数据做什么，以及您真正计划执行什么类型的访问模式。要确保，用户获得在哪里存储数据的控制权，CREATE TABLE 提供了一些语法：

[ DISTRIBUTE BY { REPLICATION | ROUND ROBIN

| { [HASH | MODULO ] ( column_name ) } } ]

[ TO { GROUP groupname | NODE nodename [, ... ] } ]

DISTRIBUTE BY 子句允许您指定在那里存储一张表，如果您想告诉Postgres-XC，一张表必须在集群中的每个节点上，我们推荐使用REPLICATION。如果您在创建一个小的查找表或者一些在查询中频繁使用的表，这尤其有用。

如果目标是向外扩展，建议散布一个表到一系列的节点。为什么会有人想拆分表？原因其实很简单。如果您把一个表复制到所有的数据节点上，它实际上意味着您将在每个节点上都有一个写操作。显然，与单节点相比，这不是扩展，因为每个节点都必须承担所有的负载。对于面临严重写的大表来说，把表分裂到多个节点可以说是有益的。Postgres-XC提供了多种方法以做到这一点。

ROUND ROBIN只是或多或少随机地分布，HASH会基于一个哈希键调度数据，MODULO将根据一个特定的键简单均匀地分布数据。

为了使管理变得更轻松，Postgres-XC允许您将节点分成所谓的节点组。如果一个表不应该驻留在集群中所有的节点上，而是只驻留在其中一半的节点上，这就会很方便。

要对节点进行分组，您可以调用 CREATE NODE GROUP：

test=# \h CREATE NODE GROUP

Command: CREATE NODE GROUP

Description: create a group of cluster nodes

Syntax:

CREATE NODE GROUP groupname

WITH nodename [, ... ]

请记住，一个节点组是静态的；您不能在以后往节点组里添加节点。因此，如果您开始整理您的集群，您必须事先考虑您的集群将有哪些区域。

除此之外，一旦数据已经被调度，重组数据是相当困难的。如果一个表分布在四个节点上，您不能只是轻松地添加第五个节点来处理该表。首先，添加第五个节点将需要重新平衡，其次，这些大部分功能仍然在建设当中，对终端用户来说尚不完全可用。

12.4.2 优化连接

如果您想连接数据，巧妙地调度数据是必须的。让我们假设一个包括三个表的简单场景：

• t_person: 此表有我们系统中的一些人组成。

• t_person_payment: 此表由一个人支付的所有款项组成。

• t_postal_code: 此表由您所在区域的邮政编码组成。

让我们假设，我们要经常连接这些数据。在这种情况下，强烈建议由同样的连接键对t_person 和 t_person_payment 进行分区。这样做将使Postgres-XC连接并合并一些数据节点上的本地数据，而不必传输集群内的数据。当然，我们也可以创建t_person表的完整副本，如果该表读的如此频繁，以至于这样做有意义。

t_postal_code 是一个可能被复制到所有节点的一个表的典型的例子。我们可以预期邮政编码是静态的。在现实生活中，邮政编码基本上不会变(至少，每秒1000个邮政编码)，该表也将是非常小的，而且它也将会被许多其它的连接所需要。这里，一个完整的副本会非常有意义。

当进行适当的逻辑划分是，我们只是想提醒您一个简单的规则：尝试本地计算，尝试避免带有任何代价的数据移动。

12.4.3 优化仓库

如果您的目标是使用Postgres-XC做商业智能和数据仓库，您必须确保您有很高的扫描速度。这可以通过同时使用尽可能多的硬件来实现。在这里，向外扩展您的实际表到多个主机将会非常有意义。

我们也建议完全复制小的查找表，以便可以在这些节点上执行尽可能多的工作。小在这里意味着什么？让我们想象一下，您正在存储世界各地上百万人的信息。您可能要拆分数据到多个节点上。但是，如果您把潜在的国家的名单分开，这显然是不合理的。这个星球上的国家的数目是有限的，所以，有这些数据的副本在所有的节点上是更加简单可行的。

12.4.4 创建一个 GTM Proxy

来自GTM请求的事务ID是一个相当昂贵的过程。如果您正在运行一个大型的Postgres-XC设置应该处理在线事务处理(OLTP)工作的负载，实际上GMT才是瓶颈所在之处。我们需要的全局事务ID越多，GTM的性能将会越重要。

要解决这个问题，我们可以引入一个GTM Proxy。这个思想是，事务ID被大量地请求。其核心思想是，我们要避免网络通信，尤其是延迟。这个概念和如何在PostgreSQL的工作中分组提交非常类似。

如何设置一个简单的 GTM Proxy ？首先，我们必须创建一个目录，该目录用于存放配置文件。然后，我们可以做如下调用：

initgtm -D /path_to_gtm_proxy/ -Z gtm_proxy

这将创建一个配置文件样本，我们可以简单轻松地改写它。定义一个节点名之后，我们应该设置gtm_host 和 gtm_port 指向活跃的GTM。然后，我们可以调整工作线程的数量到一个合理的数量，以确保我们可以处理更多的负载。通常，我们用一种 worker_threads 的数量和系统中的节点的数量相匹配的方法来配置GTM Proxy。这已经被证明是一个健壮的配置。

最后，我们可以启动代理基础设施：

gtm_ctl -D /path_to_gtm_proxy/ -Z gtm_proxy start

对我们的系统来说，GTM Proxy 现在是可用的。