Citus 14.2 介绍与选型指南

Citus 14.2 介绍与选型指南:微软开源的 PostgreSQL 水平分片分布式扩展(AGPL-3.0),本文基于官方一手来源联网溯源 2026-10-20 最新稳定版,覆盖核心架构、分布式表/引用表/同置组与列式存储等特性,并给出与原生分区、Postgres-XL、Vitess、Apache ShardingSphere 的量化选型对比与场景建议。

CitusPostgreSQL数据库Citus2026/10/20

Citus 14.2 介绍与选型指南

目标:基于官方一手来源联网溯源(查询日期 2026-10-20),说清 Citus 14.2 是什么、架构如何工作、有哪些核心特性与限制,并以量化维度与 PostgreSQL 原生分区、Postgres-XL、Vitess、Apache ShardingSphere 做同类选型对比,帮助读者判断「该不该用 Citus、什么场景用 Citus」。本篇为认知与选型篇,所有外部信息均标注来源与查询日期;安装与集群的实测过程见本专栏部署篇。

一、环境信息

本篇为认知/选型篇,不依赖本地实验环境;正文引用的版本、日期、社区数据均来自下列来源并标注查询日期(2026-10-20):

💡 说明:Citus 现为微软(Microsoft)开源项目(原 Citus Data 公司于 2019 年被微软收购),100% 开源,源码与发布件托管于 GitHub 组织 citusdata。来源:Citus 官网开源页,2026-10-20 查询。

二、软件概述

Citus 不是一套独立的数据库软件,而是 PostgreSQL 的开源扩展(extension):它把多个 PostgreSQL 实例组织成一个「Shared-Nothing(无共享)」的分布式数据库集群,由 PostgreSQL 内核在扩展层完成数据分片、分布式事务与分布式查询计划。对应用而言,连接的仍然是一个标准 PostgreSQL 端点,SQL 语法、驱动、连接池全部保持不变——这是 Citus 与「数据库中间件」类方案最本质的区别:分布式能力做在数据库内核(扩展)层,而不是代理层(来源:Citus 官网 Overview 与官方文档 Architecture 章节,2026-10-20 查询)。

基本信息一览(来源均于 2026-10-20 查询):

项目值来源
最新稳定版14.2(GitHub Releases 最新 tag v14.2.0)github.com/citusdata/citus/releases
许可证AGPL-3.0(GNU Affero 通用公共许可证 v3)仓库 main 分支 LICENSE 文件
维护方Microsoft(Citus Data 团队)citusdata.com
支持的 PostgreSQL 大版本PostgreSQL 16 / 17 / 18(14.0 起新增 PG 18 支持)14.0 发布公告(2026-02-17)
GitHub 星数13k(shields.io 徽章实测值)img.shields.io,2026-10-20
GitHub Fork 数802(shields.io 徽章实测值)img.shields.io,2026-10-20
Open Issues361(shields.io 徽章实测值)img.shields.io,2026-10-20
形态PostgreSQL 扩展(CREATE EXTENSION citus;)官方文档 Installation

💡 技术拓展:PostgreSQL 的分布式/分片生态不止 Citus 一种实现,按「分布式能力放在哪一层」可分为三类——

路线代表原理取舍
内核扩展CitusPG 内加载扩展,planner 层做分布式计划SQL 兼容性最高,无额外组件;换库需装扩展
中间件代理Vitess、ShardingSphere-Proxy独立代理进程解析并改写 SQL数据库可异构;多一层网络跳转与 SQL 兼容缺口
内核分叉Postgres-XL直接分叉 PG 源码改造能力深入;但脱离 PG 主线,版本滞后严重

本文介绍的 Citus 属「内核扩展」路线;本方案选用 Citus 的核心理由是其对 PG 语法/生态的兼容性与微软的持续维护节奏,详见第七章对比。

2.1 版本发布节奏(2026 年实查)

  • Citus 14.0:2026-02-17 发布,最大亮点是加入对 PostgreSQL 18 的支持(来源:官方博客《Distribute PostgreSQL 18 with Citus 14》,2026-02-17)。
  • Citus 14.1:2026-05-15 发布(来源:GitHub Releases 列表标注的发布日期)。
  • Citus 14.2:截至查询日期 2026-10-20,GitHub Releases 最新 tag 为 v14.2.0,变更以稳定性为主:重设计了存储过程 2PC 跳过机制(基于 PL/pgSQL 插件做静态分析)、修复协调器克隆(clone)场景的若干问题,以及 EXPLAIN、可写备库、COLLATE 类型转换等多处缺陷修复(来源:v14.2.0 Release 页变更清单)。

对使用者的含义:Citus 的 minor 版本(14.0 → 14.1 → 14.2)跟随 PostgreSQL 主版本节奏快速跟进,且 apt 包按「PostgreSQL 大版本 + Citus minor 版本」双维度命名(如 postgresql-18-citus-14.2),多版本可并存安装。

三、核心架构

Citus 的架构由三类角色与两张「账本」构成(来源:官方文档 Architecture / About Citus 章节,2026-10-20 查询)。

3.1 协调器(Coordinator)与工作节点(Worker)

  • 协调器(Coordinator):一个标准的 PostgreSQL 实例,加载 citus 扩展后成为集群入口。应用只连协调器;它持有集群元数据(分片布局、节点列表、同置组),负责把 SQL 改写成分布式的子任务并下发给工作节点,最后汇总结果。
  • 工作节点(Worker):同样加载 citus 扩展的普通 PostgreSQL 实例,存放分片数据并执行下推任务。自 Citus 11 起,集群元数据会同步到全部工作节点(metadata sync),任意节点都可成为「分布式查询入口」,协调器不再是查询的单点依赖(来源:Citus 11 发布说明与官方文档,2026-10-20 查询)。

💡 技术拓展:集群里每张业务表在 Citus 中有三种存放形态,选型时先想清楚每张表属于哪一类——

表类型分布方式典型用途
分布表(Distributed Table)按分片键哈希切成若干分片(shard),分散到各 Worker大数据量的主业务表
引用表(Reference Table)整表广播复制到每个 Worker小维表(地区、字典、配置),用于本地 JOIN
本地表(Local Table)不参与分布,留在当前节点协调器上的小工具表

Citus 集群主场景使用分布表 + 引用表组合:事实表按租户/用户 ID 哈希分布,维表广播,让 JOIN 尽量在单节点本地完成。

3.2 元数据与分片布局

协调器与(同步后的)工作节点上有一组 pg_dist_* 系统表记录集群状态:

元数据表记录内容
pg_dist_node集群节点列表(主机名、端口、角色、是否活跃)
pg_dist_partition每张分布表的分布方式与分片键
pg_dist_shard每张表的分片清单及各分片的哈希值域区间
pg_dist_placement每个分片落在哪个节点组(groupid)、副本状态

分片是「物理存在的真实 PG 表」:逻辑表 orders 会被切成 orders_102008、orders_102009… 这样的分片表分布在各 Worker 上;协调器收到查询后按分片键计算哈希值域,把涉及的分片任务并行下推。

3.3 分布式查询执行

Citus 内置自适应执行器(Adaptive Executor):协调器把查询拆分为若干 Task,按「能下推则下推」的原则发给 Worker 并行执行。命中单分片的查询(如 WHERE 分片键 = 常量)走 Router 路由,只发一个 Task、延迟近原生 PG;跨分片聚合/JOIN 则并行扫描相关分片后在协调器归并(来源:官方文档 Query Processing,2026-10-20 查询)。

同置(Co-location) 是 Citus 性能的关键:分片数、副本数、分片键类型相同的分布表共享一个 colocation group,相同值域的分片一定落在同一节点——JOIN/WHERE 都按同一分片键写时,整个 JOIN 可下推到单节点本地完成,避免跨节点数据搬运。

3.4 分布式事务

跨分片写入由 Citus 自动用 PostgreSQL 预备事务(two-phase commit,2PC)保证原子性(受 GUC citus.max_prepared_transactions 控制),失败可恢复;协调器与 Worker 之间的连接由扩展自动管理(来源:官方文档 Transactions,2026-10-20 查询)。

四、功能特性

以下特性清单均可在官方文档对应章节查到(2026-10-20 查询):

  1. 哈希分片与在线重平衡:create_distributed_table() 一句话建哈希分布表;扩容加节点后 rebalance_table_shards() 基于逻辑复制在线搬分片,业务不中断。
  2. 引用表广播:create_reference_table() 把小维表复制到所有节点,与分布表 JOIN 零跨节点搬运。
  3. 同置组(Co-location):多张分布表按同一分片键同置,支持本地 JOIN、外键与高效事务。
  4. 任意节点查询(Metadata Sync,Citus 11+):元数据全量同步至 Worker,任一节点都能当查询入口,协调器只承担「有本地分片数据」的职责。
  5. 列式存储(Citus Columnar):alter_table_set_access_method('表', 'columnar') 把分布表切换为列存访问方法,适合分析型大表(CREATE EXTENSION citus_columnar; 启用)。
  6. 租户隔离与在线分片分裂:isolate_tenant_to_new_shard() 把大租户拆到独立分片;citus_split_shard_by_split_points() 在线分裂大分片。
  7. 分布式监控:citus_stat_statements(分布式 SQL 统计)、citus_stat_activity(跨节点活动会话)、citus_lock_waits(跨节点锁等待)、citus_stat_counters 等视图内建,无需额外采集器。
  8. 集群运维 UDF 体系:节点增删/启停(citus_add_node/citus_remove_node/citus_disable_node)、健康检查(citus_check_cluster_node_health)、节点排水(citus_drain_node)等以 SQL 函数形态提供。
  9. PostgreSQL 18 兼容:14.0 起支持 PG 18(2026-02 起),同时保留 PG 16/17 支持。

五、快速开始(最小可用示例)

以下为官方文档给出的最短路径摘要(来源:docs.citusdata.com《Installation — Single Node Debian》《Multi-Node Debian》,2026-10-20 查询;命令在本专栏部署篇中均有逐条实测回显,此处仅作认知速览):

单机模式(Coordinator-Only,最快体验)——在 Ubuntu 22.04 服务器上添加 PostgreSQL 官方 PGDG 源与 Citus 官方源后安装扩展:

# 添加 PGDG 源后安装 PostgreSQL 18 与 Citus 14.2(命令摘自官方安装文档)
sudo apt-get install -y postgresql-18 postgresql-18-citus-14.2
# 配置 shared_preload_libraries = 'citus' 并重启 PostgreSQL(官方要求预加载)
sudo systemctl restart postgresql

进入 psql 后两步启用并验证(单机模式下扩展即建即用,数据保留在本机,无需任何 Worker):

CREATE EXTENSION citus;
SELECT citus_version();

多节点模式——在每个节点完成同样安装后,在协调器上把 Worker 注册进集群元数据:

SELECT * FROM citus_add_node('worker-node-1', 5432);
SELECT * FROM citus_add_node('worker-node-2', 5432);

随后建一张哈希分布表并查询(官方 Quick Start 形态):

CREATE TABLE orders (id bigint PRIMARY KEY, customer text, amount numeric);
SELECT create_distributed_table('orders', 'id');
INSERT INTO orders VALUES (1, 'alice', 100.00);
SELECT count(*) FROM orders;

💡 单机模式与多节点模式的取舍:单机适合开发验证与数据量可控的存量库平滑改造(先用 Citus 的元数据/统计能力,数据暂不外扩);多节点才是横向扩展的主形态。两者切换只需增删 Worker,无需重建表。

六、适用场景与限制

6.1 官方推荐场景(来源:官网 Overview/Use Cases,2026-10-20 查询)

  1. 多租户 SaaS(Real-Time Analytics 的第一场景):以 tenant_id 为分片键,所有租户查询路由到单分片,支撑海量并发;配合 isolate_tenant_to_new_shard 把超大租户独立放置,配合 Tenant Schema(租户级 schema 分片)处理超小租户。
  2. 实时分析报表:大表分片并行聚合,分钟级 BI 查询下推到各节点同时执行。
  3. HTAP 混合负载:OLTP 走路由查询,报表走列存访问方法(columnar)的分布表。
  4. 已有 PG 存量库的水平扩展改造:SQL 与驱动零改动,先建扩展后分布化存量表(create_distributed_table 会自动迁移本地数据进分片)。

6.2 官方文档列出的主要限制(来源:官方 Limitations 章节,2026-10-20 查询)

  • 分布表的主键/唯一约束必须包含分片键——全局唯一性只能落在分片键上。
  • 跨节点外键受限:分布表只能引用引用表或同置的分布表;不支持任意跨分片外键。
  • 部分 DDL 不能直接对分片执行(如修改分布键),需走 alter_distributed_table() 等 UDF;某些操作会要求短暂停写。
  • 无法下推的 SQL(如分片键不明的复杂窗口/递归查询)会退化为「拉全分片数据到协调器处理」,性能可能反而不如单机。
  • 扩缩容依赖逻辑复制搬分片:被搬迁的分片在搬迁期间对该分片的写入需等待(或用 shard_transfer_mode => 'block_writes' 显式阻塞)。

选型判断一句话:数据量/写入量超出单机、且 SQL 能按一个稳定分片键路由时,Citis 收益最大;数据量单机绰绰有余、或查询无法带分片键的,不必引入 Citus。

七、同类选型对比(含量化维度)

7.1 候选方案总览

方案形态面向数据库最新版本(2026-10-20 实查)GitHub 星数许可证
Citus 14.2PG 扩展PostgreSQL 16/17/18v14.2.0(Releases 最新 tag)13kAGPL-3.0
PG 原生分区内核功能PostgreSQL 10+随 PG 18.6 发布(内核自带,不适用)PostgreSQL License
Postgres-XLPG 内核分叉分叉版 PG 1010 R1.1 后停止维护,官方 GitHub 仓库已不存在(shields.io 返回 repo not found)取证失败(仓库缺失)类 BSD 变体
Vitess中间件(VTGate 代理 + VTTablet)仅 MySQL / Percona(官方文档 Supported Databases)文档线 25.021kApache-2.0
Apache ShardingSphereJDBC 库 + 独立 ProxyMySQL / PostgreSQL / openGauss5.x 系列21kApache-2.0

星数均取自 shields.io 仓库徽章(img.shields.io/github/stars/<org>/<repo>.svg),查询日期 2026-10-20;Vitess 数据库支持范围取自其官方文档(vitess.io/docs/25.0),Postgres-XL 仓库状态取自 shields.io 徽章返回值。

7.2 与 PostgreSQL 原生分区对比

维度原生分区(Partitioning)Citus
分布范围单实例内分区(同一台机器)跨机器分片(Shared-Nothing)
扩展上限单机磁盘/内存/CPU线性加节点
分区键路由planner 内建,无网络开销同样支持单分片路由(Router),有节点间网络
高并发写入受单机上限写入分散到各 Worker
运维复杂度零额外组件需管理多节点与元数据

结论:数据不超单机就先用原生分区;分区表规模继续增长后,Citus 可在分区表之上叠加(分布表的每个分片内部还可以再分区,两者是正交能力)。

7.3 与 Postgres-XL 对比

Postgres-XL 是「内核分叉」路线的代表(GTM 全局事务管理器 + Coordinator + Datanode 架构),但最后一次稳定发布停留在基于 PG 10 的版本(2019 年前后),且其官方 GitHub 仓库已从平台上消失(shields.io 徽章对 postgres-xl/postgres-xl 返回 repo not found,2026-10-20 取证)——社区已实质停更。而 Citus 保持 2026 年内 3 个 minor 版本的发布节奏并已跟进 PG 18。新项目不应再选 Postgres-XL;存量 Postgres-XL 用户迁移时,Citus 在「PG 兼容性」维度迁移成本最低。

7.4 与 Vitess 对比

维度VitessCitus
面向数据库仅 MySQL / Percona(官方文档明确)PostgreSQL 16/17/18
架构形态独立中间件集群(VTGate/VTTablet/etcd)PG 扩展,无新增进程类型
应用接入MySQL 协议PG 协议,驱动不变
分片策略Keyspace/分片 VSchema 声明SQL 内 create_distributed_table()
社区治理CNCF 毕业项目Microsoft 维护

结论:两者不是同一赛道的直接竞品——Vitess 服务 MySQL 生态,Citus 服务 PostgreSQL 生态;官方文档确认 Vitess 当前支持的数据库只有 MySQL 与 Percona Server for MySQL(vitess.io/docs/24.0/25.0,2026-10-20 查询),PG 应用无法把 Vitess 当作分片方案。

7.5 与 Apache ShardingSphere 对比

维度ShardingSphereCitus
形态Java SDK(JDBC)或独立 Proxy 进程PG 扩展(内核层)
支持方言MySQL/PostgreSQL/openGaussPostgreSQL
SQL 兼容由中间件解析改写,复杂 SQL 存在兼容缺口原生 PG planner,兼容性最高
跨库事务需额外事务模式(XA/BASE)内建 2PC
部署复杂度Proxy 需独立集群,JDBC 需改造应用每节点装扩展即可
适合人群Java 团队、需要多方言/异构数据源、做应用层分片治理PG 团队、追求 SQL 兼容与最小侵入

结论:若团队是 Java 技术栈且明确要走「应用侧分片治理」,ShardingSphere 合理;若坚持「数据库侧分片、SQL 零改动」,Citus 是 PG 生态内的首选。

7.6 选型建议(如果…则…)

  • 如果数据单机放得下 → 原生分区即可,不引入分布式。
  • 如果是 PostgreSQL 应用且单机已到瓶颈 → Citus(扩展 + 同置设计,迁移成本最低)。
  • 如果是 MySQL 应用 → Vitess(或 MySQL 生态其他方案),不要硬套 Citus。
  • 如果需要多方言、异构数据源、应用层灰度分片 → ShardingSphere。
  • 如果维护 Postgres-XL 存量集群 → 计划迁移到 Citus 或回归单机 PG 分区,不再投入 PGXL。

八、参考链接