选择分配列

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

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

多租户应用

多租户架构使用一种分层数据库建模形式在分布式集群中的节点之间分发查询。数据层次结构的顶部称为租户ID，需要存储在每个表的列中。Citus检查查询语句以查看它们涉及哪个租户ID，并将查询路由到单个工作节点进行处理。

要在您自己的架构中应用此设计，第一步是确定应用程序中租户的构成。常见的构成包括公司，帐户，组织或客户。列名称将类似于company_id或customer_id。

• 最佳实践
  通过公共tenant_id列对分布式表进行分区。 例如，在租户是公司的SaaS应用程序中，tenant_id可能是company_id。
  将小型跨租户表转换为引用表。 当多个租户共享一个小型信息表时，将其作为参考表进行分发。
  通过tenant_id限制过滤所有应用程序查询。 每个查询应一次请求一个租户的信息。

实时分析应用

虽然多租户架构引入了分层结构并使用共址表来为每个租户路由查询，但实时分析架构依赖于其数据的特定分布属性来实现高度并行处理。

我们使用“实体ID”作为实时分析模型中分布列的术语，而不是多租户模型中的租户ID。典型实体是用户，主机或设备。

实时查询通常会要求按日期或类别分组的数字聚合。Citus将这些查询发送到每个分片以获得部分结果，并在协调器节点上汇总最终结果。当尽可能多的Work节点工作时，查询运行最快。

• 最佳实践
  选择具有高基数的列作为分发列，不同值的数量限制了可以容纳数据的分片数量，以及可以处理数据的节点数量。在具有高基数的列中，还可以选择在分组子句中常用的那些列或连接键。
  选择均匀分布的列。否则某些分片的节点会比其他节点做更多的工作。
  根据join在其公共列上选择分布列形成共址表。
  将一些维度表更改为参考表提高查询性能。

时间序列数据

在Citus中建模时间序列信息时最常见的错误是使用时间戳本身作为分发列。基于时间的散列分布将看似随机的时间分配到不同的分片中，而不是将时间范围保持在分片中。涉及时间的查询通常会引用时间范围（例如最新数据），因此这种散列分布会导致网络开销。

• 最佳实践
  不要选择时间戳作为分发列。 选择其他分配列。在多租户应用中，使用租户ID，或在实时应用中使用实体ID。
  使用PostgreSQL表分区代替时间序列，每个表包含不同的时间范围，查询更快。

张 连壮

[CitusDB中国]站主，PostgreSQL粉丝，现从事Citus研发工作
愿Citus在中国发展的越来越好