目录

确定应用程序类型

概览

示例和特征

多租户应用

实时分析应用

选择分布列

多租户应用

最佳实践

实时应用

最佳实践

时间序列数据

最佳实践

表共置

Citus中用于hash分布表的数据共存

共置的实际示例

使用常规PostgreSQL表

按ID分布表

按租户分布表

共置意味着更好的功能支持

查询性能

更多

确定应用程序类型

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

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

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

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

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

示例：为其他企业托管店面的网站，例如数字营销解决方案或销售自动化工具。

特征：与单个租户相关的查询，而不是跨租户加入信息。这包括为Web客户端提供服务的OLTP工作负载，以及为每个租户提供分析查询的OLAP工作负载。在您的数据库模式中拥有数十或数百个表也是多租户数据模型的一个指标。

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

实时分析应用

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

示例:需要亚秒级响应时间的面向客户的分析仪表板。

特征:几张表，通常以设备、站点或用户事件的大表为中心，并且需要大量摄取大部分不可变的数据。涉及多个聚合和GROUPBY的相对简单（但计算量大）的分析查询。

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

选择分布列

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

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

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

多租户应用

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

下图说明了多租户数据模型中的共置(co-location)。它包含两个表，Accounts和Campaigns，每个表都由account_id分配。阴影框代表分片，每个分片的颜色代表哪个worker节点包含它。绿色分片一起存储在一个worker节点上，蓝色分片存储在另一个节点上。请注意，当将两个表限制为相同的account_id时，Accounts和Campaigns之间的join查询如何将所有必要的数据放在一个节点上。

要在您自己的schema中应用此设计，第一步是确定在您的应用程序中构成租户的内容。常见实例包括公司(

转载请注明:http://www.aideyishus.com/lkzp/487.html