Citus架构介绍既实验总结

1. Citus是什么

是PostgreSQL的扩展,可以同PG一同安装,之后通过SQL命令加入到数据库中。
【相关操作】

#创建Citus扩展:
CREATE EXTENSION citus;

2. 节点

2.1. 协调节点(coordinator node,简称CN)

存储所有的元数据,不存储实际数据。为应用系统提供服务,向各工作节点发送查询请求,并汇总结果。对于应用系统而言是服务端,对于工作节点而言有点像客户端。

2.2. 工作节点(worker node,简称WN)

不存储元数据,存储实际数据。执行协调节点发来的查询请求。原则上不直接为应用系统提供服务。但是直接操作工作节点上的表也是可以实现的。
【相关操作】

#在协调节点上增加工作节点:
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)

将同一张逻辑表中的数据按照一定策略,分别存储到不同的物理表中去。物理表被称为分片。分片和工作节点是不同的概念,同一个工作节点上可以放置许多的分片,甚至可以将一张逻辑表分为两个分片,并将这两个分片都存储在同一个工作节点上。
分片原则
在设计分布式数据库的时候,设计者必须考虑数据如何分布在各个场地上,也就是全局数据应该如何进行逻辑划分和物理划分。哪些数据应该分布式存放,哪些不需要分布式存放,哪些数据需要复制。对系统惊醒全盘考虑,使系统性能最优。但是无论如何进行分片都应该遵循以下原则:
● 完备性:所有全局数据都要映射到某个片段上。
● 可重构性:所有片段必须可以重新构成全局数据。
● 不相交性:划分的个片段所包含的数据无交集。
副本,即分片的冗余。
【相关操作】

#配置分片策略(在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. 分片修复

【相关操作】

#先查看分片分布:
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系统同一分片的不同副本间的一致性。

7.参考文献

分布式数据库的分片方法
在CentOS7.2上部署基于PostgreSQL10的citus分布式数据库
Citus初步测试
Citus性能测试
Citus数据分片分布研究(一 在工作节点直接操作表)
Citus数据分片分布研究(二 副本与故障)
Citus数据分片分布研究(三 节点故障的手动修复)

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

皓月如我

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值