分布式 PostgreSQL 集群(Citus)官方示例 - 实时仪表盘

Citus 提供对大型数据集的实时查询。我们在 Citus 常见的一项工作负载涉及为事件数据的实时仪表板提供支持。

例如，您可以是帮助其他企业监控其 HTTP 流量的云服务提供商。每次您的一个客户端收到 HTTP 请求时，您的服务都会收到一条日志记录。您想要摄取所有这些记录并创建一个 HTTP 分析仪表板，为您的客户提供洞察力，例如他们的网站服务的 HTTP 错误数量。 重要的是，这些数据以尽可能少的延迟显示出来，这样您的客户就可以解决他们网站的问题。 仪表板显示历史趋势图也很重要。

或者，也许您正在建立一个广告网络，并希望向客户展示其广告系列的点击率。 在此示例中，延迟也很关键，原始数据量也很高，历史数据和实时数据都很重要。

在本节中，我们将演示如何构建第一个示例的一部分，但该架构同样适用于第二个和许多其他用例。

• real-time-analytics-Hands-On-Lab-Hyperscale-Citus
  • https://github.com/citusdata/real-time-analytics-Hands-On-Lab-Hyperscale-Citus
• Architecting Real-Time Analytics for your Customers
  • https://github.com/citusdata/postgres-analytics-tutorial

数据模型

我们正在处理的数据是不可变的日志数据流。我们将直接插入 Citus，但这些数据首先通过 Kafka 之类的东西进行路由也很常见。 这样做具有通常的优势，并且一旦数据量变得难以管理，就可以更容易地预先聚合数据。

我们将使用一个简单的 schema 来摄取 HTTP 事件数据。 这个 schema 作为一个例子来展示整体架构；一个真实的系统可能会使用额外的列。

-- this is run on the coordinator

CREATE TABLE http_request (
  site_id INT,
  ingest_time TIMESTAMPTZ DEFAULT now(),

  url TEXT,
  request_country TEXT,
  ip_address TEXT,

  status_code INT,
  response_time_msec INT
);

SELECT create_distributed_table('http_request', 'site_id');

当我们调用 create_distributed_table 时，我们要求 Citus 使用 site_id 列对 http_request 进行 hash 分配。 这意味着特定站点的所有数据都将存在于同一个分片中。

• create_distributed_table
  • https://docs.citusdata.com/en/v10.2/develop/api_udf.html#create-distributed-table

UDF 使用分片计数的默认配置值。我们建议在集群中使用 2-4 倍于 CPU 核的分片。使用这么多分片可以让您在添加新的工作节点后重新平衡集群中的数据。

• 2-4 倍于 CPU 核的分片
  • https://docs.citusdata.com/en/v10.2/faq/faq.html#faq-choose-shard-count

Azure Database for PostgreSQL — 超大规模 (Citus) 使用