当前调研基于citus7.5

开源协议
citus的开源协议是GPL v3， 意味着修改和使用其代码都需要开源，但是这是建立在软件分发的基础上，如果使用代码作为服务提供，而不分发软件，则不需要开源。

功能优势
只是PostgreSQL的一个extension；基本兼容PostgreSQL的sql处理能力、管理工具、性能优化和功能扩展等
支持分布式事务；citus使用2pc保证数据的终一致性
支持两种执行器；real-time(默认)和task-tracker执行器，可根据实际应用场景选择执行器
横向扩展方便；citus增加worker节点非常方便，只需要简单的几步操作即可完成扩展
分片表管理简单；分片表删改与普通表差别不大，且citus提供了大量的函数查看分片表的状态，管理分片
支持并行查询；citus在接收到分布式请求之后，会生成分布式执行计划，并将各个子任务下发到相应的worker节点执行
支持聚合下推； citus执行聚合时先在涉及到的worker节点进行初步处理，再在coordinator节点汇总计算。
成功案例较多；苏宁、cisco等
支持批量数据加载；
支持实时增删改查；
支持常用DDL；
real-time执行器是coordinator节点直接与worker节点交互，容易造成并发大，可能导致资源瞬间增长

task-tracker执行器是coordinator节点与worker节点上的task-tracker进程交互，由task-tracker进程负责worker上的任务调度，支持数据重分布，并发数可控



功能限制
不能保证全局的一致性读；2pc的后一步，一部分子事务还未提交时，读取数据库可能会得到不正确的结果
社区版不支持平滑扩容；citus添加新的worker节点后，现有的分片表和参考表却不会自动分布到新加的worker上。
社区版CN可能成为性能瓶颈；社区版只支持一个coordinator
本地表不能与分片表、参考表混用；
分片列不支持更新；
SQL限制；
【平滑扩容问题】

如果要手工处理，需要以下几步：

添加节点；
复制分片；将原有的worker上的分片移动一部分到新节点上（逻辑复制）
切换元数据；分片数据同步完成后，锁表，修改元数据中的分片信息
清理原有worker上已被复制的分片和publication，清理新节点上的subscription
注意：citus的分片表之间存在亲和性关系，具有亲和性的所有分片表的同一范围的分片其所在位置必须相同。因此移动某个分片时，必须将这些亲和分片捆绑移动。

企业版可以利用master_move_shard_placement()函数迁移分片，我们可以也实现一个接口类似的函数（未进行严格测试，且不支持多CN架构）来实现分片迁移

【CN性能瓶颈问题】

citus的架构中正常只有1个CN节点，有时候CN会成为性能瓶颈。在citus的具体实现中，CN和worker的区别就在于是否存储了相关的元数据，如果把CN的元数据拷贝一份到worker上，那么worker也可以向CN一样工作，这个多CN的模式早期被称做masterless。当前的citus版本，有一个开关，打开后，会自动拷贝CN的元数据到Worker上，让worker也可以当CN用。 这个功能官方称做Citus MX，社区版虽然没有公开说支持，但也没有从代码上限制这个功能，也可以用（已验证）



SQL限制
查询
Join限制（已验证）
不支持2个非亲和分片表的outer join
仅task-tracker执行器只是2个非亲和分片表的inner join
分片表和参考表outer join时，参考表只能再left join的右边或者right join的左边
子查询限制
不能出现order by ,limit,offset
不支持的特性
CTE
窗口函数
集合操作，比如union
非分片列的count(distinct)
更新
不支持跨分片的更新SQL (有疑问）
不支持跨分片的事务(有疑问)
insert into ... select from ...的支持有限制
源和目标表必须是亲和分片表
不允许出现Stable and volatile函数
不支持LIMIT,OFFSET,窗口函数，集合操作，Grouping sets, DISTINCT
DDL

ALTER TABLE只支持以下子命令 Only ADD|DROP COLUMN, SET|NOT NULL, DEFAULT, CONSTRAINT Only ADD|DROP COLUMN, SET|NOT NULL, DEFAULT, CONSTRAINT FOREIGN KEY and TYPE subcommands are supported.

性能
官方数据
citus与原生PostgreSQL性能对比：

citus PostgreSQL(9.6.4)
测试数据 114万行（表结构未知）
测试环境
coordinator(4 vcpus/7.5G/1T) (+1HA)

worker(8 vcpus/61G/1T)*4 (+4HA)

未知
copy写入 94秒/88秒 454秒/109秒
创建索引 109秒 8秒
查询性能 941毫秒 68毫秒
查询延时 2毫秒 37毫秒

第三方数据
citus与原生PostgreSQL性能对比

数据来源：《citus OLTP(TPC-B)测试》

环境配置：（ECS 32核，128G内存，2TB 云盘) * 9

环境 test case TPS coordinator 节点CPU资源消耗 worker节点CPU资源消耗
citus(1+8) shard=8 1亿 tpc-b 只读 16.3万 (0% IDLE) (92% IDLE)
citus(1+8) shard=128 1亿 tpc-b 只读 16.4万 (0% IDLE) (91% IDLE)
local PG 1亿 tpc-b 只读 49万 - (0% IDLE)
citus(1+8) shard=8 1亿 tpc-b 读写 1.28万 (45% IDLE) (91% IDLE)
citus(1+8) shard=128 1亿 tpc-b 读写 1.11万 (36% IDLE) (91% IDLE)
local PG 1亿 tpc-b 读写 3.98万 - (0% IDLE)


citus与原生PostgreSQL随机更新性能对比

数据来源：《苏宁citus应用实践》

环境配置：未知，citus 8 worker

部署方式 TPS 备注
单机PostgreSQL 134030
citus 55717 coordinator是性能瓶颈
citus(不解析SQL） 75973 改citus代码
citus(masterless) 20W+
注：把coordinator的元数据拷贝一份到worker上，那么worker也可以向CN一样工作，这个多CN的模式早期被称做masterless。上述测试数据中masterless场景CN的个数未知。



citus与Deepgreen性能对比

数据来源 ：《Deepgreen TPC-H 测试》 《citus OLTP(TPC-B)测试》

环境配置：（ECS 32核，128G内存，2TB 云盘) * 9

【TPC-B】

citus DeepGeen
TPC-B(只读) 16.4万 tps 187 tps
TPC-B(读写) 1.11万 tps 17 tps
【TPC-H】

query序号 citus（秒 ） DeepGreen（秒 ）
1 12 3
3 77 4
4 2 7
5 234 2
6 1 0
7 465 23
8 415 5
9 837 12
10 116 4
14 67 5
15 232 6
19 76 3
————————————————
版权声明：本文为CSDN博主「Siven_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/suzy1030/article/details/83893829