原文：Scaling Our Analytical Processing Service: Sharding a PostgreSQL Database with Citus
在线广告商正在根据绩效数据做出越来越多的决策。 无论是选择要投资的受众或创意，还是启用广告活动预算的算法优化，决策越来越依赖于随时可用的数据。 我们的开发团队构建了强大的工具来帮助我们的客户分析性能数据并做出更好的决策。
我们的解决方案由高度可定制的报告组成，包括由我们自己的极其灵活的查询语言提供支持的下钻表和图表。支持查询语言的数据服务处理数 TB 的数据。除了作为我们面向用户的分析工具的后端之外，它还为我们所有的自动优化功能和我们的一些内部 BI 系统提供支持。在这篇博文中，我将向您介绍我们如何通过对后端系统使用的数据库进行分片来解决扩展问题。
海量数据库等于扩展麻烦
我们的分析数据处理服务，称为 Distillery，使用 PostgreSQL 数据库。该服务将 JSON 格式的查询安全地转换为最终在数据库级别运行的 SQL 查询。大多数数据处理都发生在数据库中，因此 Distillery 后端主要将我们自己的查询语言转换为 SQL 查询。原始的 API 查询很复杂，这使得一些生成的 SQL 查询变得复杂，并使得它们对数据库级别的要求很高。因此，当我们在报告系统的开发过程中遇到扩展问题时，我们并不感到惊讶。
过去，我们垂直扩展了我们的主副本数据库架构，但后来很明显我们已经达到了这种方法的极限。我们的数据库在运行三年中积累了近 5TB 的数据，并且变得无法管理。大尺寸使得更新繁重的应用程序写入速度变慢，维护任务难以执行。最后，最大的问题是我们的数据中心无法提供更大的服务器。
解决方案：使用 Citus 分片 PostgreSQL 数据库
当垂直扩展失败时，我们不得不开始水平扩展我们的报告数据库。这意味着我们需要在多个数据库服务器之间拆分数据和处理。我们还必须缩小包含每个单独数据库实例中统计数据的庞大数据库表。
这种将数据库数据切片成更小单元的方法称为数据库分片。我们的团队决定使用 PostgreSQL Citus 插件来处理分片。这不是唯一的选择 — 我们考虑使用自定义应用程序级分片，但决定使用 Citus 插件，因为：
- 我们有大量复杂的查询，需要同时使用多个不同的分片。
Citus插件自动处理这些复杂的查询并在分片之间分配处理。 - 它还广泛支持我们运行复杂报告查询所需的
PostgreSQL功能。 - 该扩展使分片管理相对容易，因此我们不必花费太多精力来管理单独数据库实例中的分片表。
Citus 基于 coordinator(协调器) 和 worker(工作器) PostgreSQL 数据库实例。worker 持有数据库表分片，coordinator 计划 SQL 查询，以便它们可以跨 worker 之间的多个分片表运行。 这允许将大型表分布在多个服务器上，并分布到更小、更易于管理的数据库表中。写入较小的表更有效，因为数据库索引维护成本降低。此外，写入负载是并行化的，并在数据库实例之间共享。Citus 解决了我们最大的两个痛点：写入效率低下和垂直扩展即将结束。
Citus 的数据库分片带来了额外的好处，因为新架构加速了我们的报告查询。我们的一些查询命中了多个 worker 实例和分片，Citus 扩展可以对其进行优化以在不同的数据库实例中并行运行它们。 由于较小的表索引和更多资源可用于在单独的 worker 中进行查询处理，因此仅针对单个 worker 分片的查询也会加快速度。
将大型数据库和复杂的报告查询迁移到这种类型的分片数据库架构中绝非易事。它涉及仔细的准备和计划，我们将在接下来进行研究。
迁移到新数据库
过去，我们通过旧的 PHP 单体运行报告查询。早在数据库扩展问题出现之前，我们就开始使用 Ruby on Rails 构建更新的报告后端。在决定只在新后端处理 SQL 查询迁移后，我们开始逐步淘汰旧后端。这使我们能够专门针对 Citus 优化新的报告查询。它使从应用程序级别的迁移更容易，因为我们只需迁移此服务即可与 Citus 分片 PostgreSQL 一起使用。
分片数据库对数据库模式有一定的要求。模式必须具有一个作为分片条件的值。分片逻辑使用此值来区分数据位于哪个分片上。 在 Citus-PostgreSQL 中，分片是使用表主键控制的。此复合主键包含一个或多个列，其中第一个定义的列用作分片值：
ALTER TABLE ad_stats ADD PRIMARY KEY (account_id, ad_id, date);
SELECT create_distributed_table('ad_stats', 'account_id'); -- Defines sharding for Citus cluster
这里 account ID 列用作分片键，这意味着我们正在根据我们的客户帐户分配数据（单个客户也可以有多个帐户）。这意味着单个帐户的数据位于单个表分片中。我们必须确保所有主键都采用这种格式，并且表中包含帐户 ID 信息。我们还必须更改一些外键和唯一性约束，因为它们还必须包含分片列。幸运的是，所有这些更改都可以安全地应用于正在运行的生产数据库，而没有任何性能或数据完整性问题，尽管我们不得不进行一些更广泛的数据库索引重建。
第二步是让我们的报表后端生成的 SQL 查询与分片数据库兼容。首先，查询必须包含 SQL WHERE 子句中的分片值。这意味着，例如，过滤器必须采用以下形式
SELECT * FROM campaigns WHERE account_id = 'xxx' AND name = 'yyy'
如果我们没有 account_id 条件，Citus 分布式查询计划器将没有信息需要从哪个分片中找到相关行。从所有可能的分片中读取不会像从单个分片中读取那样有效。
此外，Citus 对您可以在分片表之间执行的 JOIN 类型有一定的限制。通常 JOIN 要求分片列出现在 JOIN 条件中。例如，这将不起作用：
SELECT *
FROM
campaigns
LEFT JOIN ads ON campaigns.id = ads.campaign_id
WHERE
campaigns.account_id = 'xxx'
这将导致错误：
ERROR: cannot run outer join query if join is not on the partition column&
这意味着 SQL 外连接需要 Citus 无法从查询中确定的表分片之间的一对一匹配。因此，查询需要在 JOIN 条件中包含分片列，Citus 能够从中检测到 ads 表连接的范围在一个分片内：
SELECT *
FROM
campaigns
LEFT JOIN ads ON campaigns.account_id = ads.account_id -- Use sharding column
AND campaigns.id = ads.campaign_id
WHERE
campaigns.account_id = 'xxx'
我们进行了各种其他 SQL 查询优化，使 Citus 查询规划器能够有效地运行我们复杂的统计报告查询。 例如，我们使用通用表表达式 (CTE) 组织查询，这允许 Citus 查询计划器为涉及同时读取多个分片的繁重查询选择最佳计划。 这些针对多个帐户的查询也在 Citus worker 集群中高度并行化，从而提高数据处理效率。 此外，我们还为 Citus 扩展做出了贡献，增加了对 PostgreSQL JSON(B) 聚合的支持，我们的报告查询将其用于某些数据预聚合步骤。您可以在 Github 中查看PR。
PR
- https://github.com/citusdata/citus/pull/2015
运行中的新数据库系统
我们的数据库系统完全从单一主副本配置迁移到 coordinator + 4 个 worker 服务器，每个服务器都复制以实现高可用性。这意味着我们包含 5TB 数据的旧数据库被分割成一个集群，其中每个数据库服务器保存大约 1TB 数据。Citus 允许我们相当容易地添加更多的 worker 服务器，以便在公司继续发展时将其进一步分割。我们还可以将拥有大量统计数据的最苛刻的客户隔离到他们自己的数据库服务器上。
迁移前的数据库架构。
迁移后的数据库架构。
上图描绘了迁移前后的数据库架构。与之前拥有 2 台大型数据库服务器的状态相比，我们现在总共拥有 10 台数据库服务器。这些较小的数据库实例更易于管理，因为大多数数据存在于单独的数据库工作服务器中。协调器持有较少量的数据，例如一些元数据和对分片不敏感的数据。第二张图还显示了我们用来确保在一个数据库实例出现故障时快速恢复的数据库副本。这种从 primary master 服务器到副本服务器的故障转移由 pgpool 组件处理。副本还共享来自主服务器的一些读取负载。
最后，我们在数据处理方面要求最高的数据透视表报告查询从新数据库系统中获得了 2-10 倍的性能提升。 此功能生成的数据库查询非常复杂，因为我们允许用户自由定义数据的分组、过滤和聚合方式。它还允许查询跨分片自由运行，因为用户可以定义任何帐户组合。Citus 分片数据库的好处真正体现在这些特定的查询中。数据库迁移非常必要，因为我们的旧数据库基础架构几乎被它生成的复杂查询所淹没。
该图显示了在数据库迁移项目期间，某些类型的查询获得性能提升的 90 个百分点的持续时间。
更多
- 分布式 PostgreSQL - Citus 架构及概念