1. Citus是什么
是PostgreSQL的扩展，可以同PG一同安装，之后通过SQL命令加入到数据库中。
【相关操作】
|
1
2
|
#创建Citus扩展：
CREATE
EXTENSION citus;
|
2. 节点
2.1. 协调节点（coordinator node，简称CN）
存储所有的元数据，不存储实际数据。为应用系统提供服务，向各工作节点发送查询请求，并汇总结果。对于应用系统而言是服务端，对于工作节点而言有点像客户端。
2.2. 工作节点（worker node，简称WN）
不存储元数据，存储实际数据。执行协调节点发来的查询请求。原则上不直接为应用系统提供服务。但是直接操作工作节点上的表也是可以实现的。
【相关操作】
|
1
2
3
4
5
6
7
8
9
10
11
|
#在协调节点上增加工作节点：
SELECT
*
from
master_add_node(
'192.168.7.130'
, 5432);
SELECT
*
from
master_add_node(
'192.168.7.131'
, 5432);
SELECT
*
from
master_add_node(
'192.168.7.132'
, 5432);
#查看工作节点：
SELECT
*
FROM
master_get_active_worker_nodes();
node_name | node_port
---------------+-----------
192.168.7.130 | 5432
192.168.7.131 | 5432
192.168.7.132 | 5432
|
3. 分片（shards）与副本（placement）
将同一张逻辑表中的数据按照一定策略，分别存储到不同的物理表中去。物理表被称为分片。分片和工作节点是不同的概念，同一个工作节点上可以放置许多的分片，甚至可以将一张逻辑表分为两个分片，并将这两个分片都存储在同一个工作节点上。
分片原则
在设计分布式数据库的时候，设计者必须考虑数据如何分布在各个场地上，也就是全局数据应该如何进行逻辑划分和物理划分。哪些数据应该分布式存放，哪些不需要分布式存放，哪些数据需要复制。对系统惊醒全盘考虑，使系统性能最优。但是无论如何进行分片都应该遵循以下原则：
● 完备性：所有全局数据都要映射到某个片段上。
● 可重构性：所有片段必须可以重新构成全局数据。
● 不相交性：划分的个片段所包含的数据无交集。
副本，即分片的冗余。
【相关操作】
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
#配置分片策略（在CN上创建表之后）：
SELECT
master_create_distributed_table(
'test_table'
,
'id'
,
'hash'
);
#进行分片操作（将表分为3片，每个分片有2个副本）：
SELECT
master_create_worker_shards(
'test_table'
, 3, 2);
#查看分片：
SELECT
*
from
pg_dist_shard;
logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
--------------+---------+--------------+---------------+---------------
test_table | 102001 | t | -2147483648 | -1610612737
test_table | 102002 | t | -1610612736 | -1073741825
test_table | 102003 | t | -1073741824 | -536870913
#查看分片分布：
SELECT
*
from
pg_dist_shard_placement
order
by
shardid, placementid;
shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------
102001 | 1 | 0 | 192.168.7.130 | 5432 | 33
102001 | 1 | 0 | 192.168.7.131 | 5432 | 34
102002 | 1 | 0 | 192.168.7.131 | 5432 | 35
102002 | 1 | 0 | 192.168.7.132 | 5432 | 36
102003 | 1 | 0 | 192.168.7.132 | 5432 | 37
102003 | 1 | 0 | 192.168.7.130 | 5432 | 38
|
从上面的分析可以看出，表test_table被分成了3个分片（102001，102002，102003），每个分片有2个副本，分别存储在相邻的两个节点上。如下图所示。
分片分布表中shardstate为1时，表示当前副本的状态是有效（同步）的；shardstate为3时，表示当前副本的状态是有无效（失步）的。
4. 数据访问
通过CN对表test_table进行插入操作，根据先前定义的分片策略，citus会根据id的哈希值自动为插入的记录选择一个分片进行写入。
当WN3离线时，通过CN对表test_table进行查询操作，因为WN1和WN2上已经包含了所有的分片，所以查询能够正常返回应有的结果。此时查看分片分布，发现所有副本状态都仍然为有效。
当WN3离线时，通过CN对表test_table进行插入/更新/删除操作，如果受影响的记录属于201001分片，那么citus会修改WN1和WN2上test_table_102001表的数据，且不会对任何副本的状态产生影响；如果受影响的记录属于201002分片，（因为WN3离线），citus会修改WN2上test_table_102002表的数据，并在分布分片信息中将36号副本的状态置为“无效（失步）”，注意此时37号副本的状态仍然是“有效（同步）”。
之后让WN3重新上线，检查分布分片信息，可以看到36号副本的状态仍为“无效（失步）”，可见其不会自动修复。此时对201002分片的所有读写操作，都只对35号副本进行。
5. 分片修复
【相关操作】
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
#先查看分片分布：
SELECT
*
from
pg_dist_shard_placement
order
by
shardid, placementid;
shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------
102001 | 1 | 0 | 192.168.7.130 | 5432 | 33
102001 | 1 | 0 | 192.168.7.131 | 5432 | 34
102002 | 1 | 0 | 192.168.7.131 | 5432 | 35
102002 | 3 | 0 | 192.168.7.132 | 5432 | 36
102003 | 1 | 0 | 192.168.7.132 | 5432 | 37
102003 | 1 | 0 | 192.168.7.130 | 5432 | 38
#用35号副本的数据去覆盖36号副本：
SELECT
master_copy_shard_placement(102002,
'192.168.7.131'
, 5432,
'192.168.7.132'
, 5432);
#再次查看分片分布：
SELECT
*
from
pg_dist_shard_placement
order
by
shardid, placementid;
shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------
102001 | 1 | 0 | 192.168.7.130 | 5432 | 33
102001 | 1 | 0 | 192.168.7.131 | 5432 | 34
102002 | 1 | 0 | 192.168.7.131 | 5432 | 35
102002 | 1 | 0 | 192.168.7.132 | 5432 | 36
102003 | 1 | 0 | 192.168.7.132 | 5432 | 37
102003 | 1 | 0 | 192.168.7.130 | 5432 | 38
#可见36号副本已经修复。
|
当且仅当分片时设置了副本数量大于1，且该分片目前存在有效副本时，才可以进行修复。从目前已知的情况来看，citus不能自动修复。可以通过开发守护进程检测各个节点和副本的状态，当发现出现失效副本时，在服务程序中调用master_copy_shard_placement的方法实现自动修复。
6. 集群性能
通过搭建基于PostgreSQL10的1CN+2WN的Citus集群环境（两分片，单副本）和单节点传统PostgreSQL10进行对比的方法，采用PgBench测试工具的TPC-B模式，在记录数100万的情况下得出如下结果：TPS[Citus]=258，TPS[PG10]=688。即该配置下Citus集群的整体读写效率为传统单节点PG10的37.5%。
通过合理的分片，使得大多数操作可以直接在WN进行，能有有效的提高Citus集群的效率，但是在存在副本的情况下，需要应用程序人为的保证Citus系统同一分片的不同副本间的一致性。