Álvaro Hernández：无限扩展 Citus：StackGres 推出查询路由器
内容提要
StackGres 1.19 为 Citus 引入查询路由器，突破单协调器瓶颈。查询路由器不存分片数据，仅保存元数据并规划路由查询，可水平扩展，由 Kubernetes Service 负载均衡。基准测试显示，单协调器约 55 万 TPS 即达上限，加三个查询路由器后升至 143 万 TPS，延迟仍低，实现近线性扩展。
延伸解读
查询路由器如何突破单协调器瓶颈
Citus 单协调器架构中，所有查询都需经过一个协调器节点进行解析、规划和结果聚合，这使其成为性能天花板。StackGres 1.19 引入的查询路由器通过增加多个入口点来分担查询路由工作，每个路由器仅保存元数据、不存储分片数据，并由 Kubernetes Service 负载均衡。这样，协调器可专注于 DDL 操作，而查询负载被分散到多个路由器，从而消除单点瓶颈。
基准测试揭示的近线性扩展能力
在 pgbench 基准测试中，单协调器在约 55 万 TPS 时达到上限，增加三个查询路由器后性能提升至 143 万 TPS，且 p50 延迟为 1 毫秒、p99 为 4 毫秒。这表明查询路由器能带来接近线性的扩展，同时保持低延迟。测试中工作节点未饱和，暗示继续增加路由器可能进一步提升吞吐量。
部署查询路由器的注意事项
查询路由器通过 SGShardedCluster 的 queryRouterClusters 属性声明式添加，默认继承协调器配置。它们注册为无分片节点，并持有参考表以优化本地查询。但自动复制参考表可能阻塞写入，因此默认关闭。此外，协调器仍负责 DDL 和元数据变更，查询路由器不处理这些操作。
Q&A
Citus 单协调器架构有什么瓶颈？
在标准 Citus 集群中，所有客户端连接都经过唯一的协调器。协调器负责解析、规划查询、路由到工作节点并聚合结果，所有工作都在一个节点上完成。因此协调器可能成为性能瓶颈，限制整个集群的扩展能力。
StackGres 1.19 中引入的查询路由器是什么？
查询路由器是 Citus 的额外入口点，它们持有 Citus 元数据，负责规划和路由查询，但不存储分片数据。它们由 Kubernetes Service 负载均衡，可以水平扩展，从而突破单协调器的限制。
查询路由器如何实现水平扩展？
查询路由器本身不存储分片数据，只保存元数据并规划路由查询。它们作为独立的单实例集群运行，由 Kubernetes Service 前端进行负载均衡。通过添加更多查询路由器，可以线性提升查询吞吐量。
使用查询路由器后，Citus 集群的性能提升如何？
基准测试显示，单协调器在约 55 万 TPS 时达到上限。添加三个查询路由器后，性能提升至 143 万 TPS，p50 延迟为 1 毫秒，p99 延迟为 4 毫秒，实现了近线性扩展。
如何在 StackGres 中配置查询路由器？
在 SGShardedCluster 的 spec 中添加 queryRouterClusters 属性即可指定查询路由器的数量。例如，设置 queryRouterClusters: 2 会创建两个查询路由器。默认情况下，查询路由器继承协调器的配置，但可以通过覆盖进行自定义。
查询路由器与协调器在职责上有何区别？
协调器仍然负责 DDL 操作和元数据变更，如创建分布式表、引用表、再平衡等。查询路由器则专注于查询路由，不执行 DDL。这样协调器可以保持较小规模，而查询负载由查询路由器分担。
