分布式 PostgreSQL 集群(Citus)，分布式表中的分布列选择最佳实践

确定应用程序类型

在 Citus 集群上运行高效查询要求数据在机器之间正确分布。这因应用程序类型及其查询模式而异。

大致上有两种应用程序在 Citus 上运行良好。数据建模的第一步是确定哪些应用程序类型更接近您的应用程序。

概览

多租户应用	实时应用
有时 schema 中有几十个或数百个表	表数量少
一次与一个租户(公司/商店)相关的查询	具有聚合的相对简单的分析查询
用于服务 Web 客户端的 OLTP 工作负载	摄取大量几乎不可变的数据
为每个租户分析查询提供服务的 OLAP 工作负载	通常围绕着一个大的事件表

示例和特征

多租户应用

这些通常是为其他公司、帐户或组织服务的 SaaS 应用程序。大多数 SaaS 应用程序本质上是关系型的。它们具有跨节点分布数据的自然维度：只需按 tenant_id 分片。

Citus 使您能够将数据库扩展到数百万租户，而无需重新构建应用程序。 您可以保留所需的关系语义，例如 联接、外键约束、事务、ACID 和一致性。

• 示例：为其他企业托管店面的网站，例如数字营销解决方案或销售自动化工具。
• 特征：与单个租户相关的查询，而不是跨租户加入信息。这包括为 Web 客户端提供服务的 OLTP 工作负载，以及为每个租户提供分析查询的 OLAP 工作负载。 在您的数据库模式中拥有数十或数百个表也是多租户数据模型的一个指标。

使用 Citus 扩展多租户应用程序还需要对应用程序代码进行最少的更改。我们支持流行的框架，如 Ruby on Rails 和 Django。

实时分析应用

需要大规模并行性、协调数百个内核以快速获得数值、统计或计数查询结果的应用程序。 通过跨多个节点对 SQL 查询进行分片和并行化，Citus 可以在一秒钟内对数十亿条记录执行实时查询。

• 示例: 需要亚秒级响应时间的面向客户的分析仪表板。
• 特征: 几张表，通常以设备、站点或用户事件的大表为中心，并且需要大量摄取大部分不可变的数据。涉及多个聚合和 GROUP BY 的相对简单(但计算量大)的分析查询。

如果您的情况类似于上述任何一种情况，那么下一步就是决定如何在 Citus 集群中对数据进行分片。 如概念部分所述，Citus 根据表分布列的哈希值将表行分配给分片。 数据库管理员对分布列的选择需要与典型查询的访问模式相匹配，以确保性能。

选择分布列

Citus 使用分布式表中的分布列将表行分配给分片。为每个表选择分布列是最重要的建模决策之一，因为它决定了数据如何跨节点分布。

如果正确选择了分布列，那么相关数据将在相同的物理节点上组合在一起，从而使查询快速并添加对所有 SQL 功能的支持。如果列选择不正确，系统将不必要地缓慢运行，并且无法支持跨节点的所有 SQL 功能。

本节提供两种最常见的 Citus 方案的分布列提示。 最后，它深入探讨了 共置(co-location)，即节点上理想的数据分组。

多租户应用

多租户架构使用一种分层数据库建模形式在分布式集群中的节点之间分布查询。 数据层次结构的顶部称为 tenant id，需要存储在每个表的列中。Citus 检查查询以查看它们涉及的 tenant id，并将查询路由到单个 worker 节点进行处理，特别是保存与 tenant id 关联的数据分片的节点。 运行将所有相关数据放置在同一节点上的查询称为 Table Co-Location。

下图说明了多租户数据模型中的共置(co-location)。它包含两个表，Accounts 和 Ca