分布式 PostgreSQL 集群(Citus)官方教程 - 迁移现有应用程序

目录

• 确定分布策略

• 选择分布键

• 确定表的类型

• 为迁移准备源表

• 添加分布键

• 回填新创建的列

• 准备申请 Citus

• 建立开发 Citus 集群

• 在键中包含分布列

• 向查询添加分布键

• 其他（SQL原则）

• 启用安全连接

• 检查跨节点流量

• 迁移生产数据

• 小型数据库迁移

• 大数据库迁移(Citus Cloud)

• 重复 schema

• 启用逻辑复制

• 开放访问网络连接

• 开始复制

• 切换到 Citus 并停止与旧数据库的所有连接

• 更多

将现有应用程序迁移到 Citus 有时需要调整  schema 和查询以获得最佳性能。  Citus 扩展了  PostgreSQL 的分布式功能，但它不是扩展所有工作负载的直接替代品。高性能  Citus 集群需要考虑数据模型、工具和所使用的  SQL 功能的选择。

第一步是优化现有的数据库模式，以便它可以在多台计算机上高效工作。

• 确定分布策略

  • 选择 分布键(distribution key)

  • 识别表的类型

• 为迁移准备源表

  • 添加分布键

  • 回填新创建的列

接下来，更新应用程序代码和查询以处理 schema 更改。

• 准备申请 Citus

  • 建立开发 Citus 集群

  • 向查询添加分布键

  • 启用安全连接

  • 检查跨节点流量

在开发环境中测试更改后，最后一步是将生产数据迁移到 Citus 集群并切换生产应用程序。我们有技术可以最大限度地减少此步骤的停机时间。

• 迁移生产数据

  • 小型数据库迁移

  • 大数据库迁移

确定分布策略

选择分布键

迁移到 Citus 的第一步是确定合适的 distribution key 并相应地规划表分布。在多租户应用程序中，这通常是租户的内部标识符。我们通常将其称为 “租户 ID(tenant ID)” 。用例可能会有所不同，因此我们建议您在此步骤中进行彻底检查。

如需指导，请阅读以下部分：

1. 确定应用程序类型

   • https://docs.citusdata.com/en/v10.2/develop/app_type.html#app-type

2. 选择分布列

   • https://docs.citusdata.com/en/v10.2/sharding/data_modeling.html#distributed-data-modeling

我们很乐意帮助您检查您的环境，以确保选择了理想的 distribution key 。为此，我们通常会检查  schema 布局、更大的表、长时间运行和/或有问题的查询、标准用例等。

确定表的类型

一旦确定了 distribution key ，请查看  schema 以确定如何处理每个表以及是否需要对表布局进行任何修改。我们通常建议使用电子表格进行跟踪，并创建了您可以使用的模板。

• https://docs.google.com/spreadsheets/d/1jYlc22lHdP91pTrb6s35QfrN9nTE1BkVJnCSZeQ7ZmI/edit

表格通常属于以下类别之一：

1. 准备分发。 这些表已经包含  distribution key ，并准备好分发。

2. 需要回填。 这些表可以按所选  key 进行逻辑分布，但不包含直接引用它的列。稍后将修改这些表以添加该列。

3. 参考表。 这些表通常很小，不包含  distribution key ，通常由分布式表连接，和/或在租户之间共享。这些表中的每一个的副本将在所有节点上维护。常见示例包括国家代码查找、产品类别等。

4. 本地表。 这些通常不连接到其他表，并且不包含  distribution key 。它们仅在  coordinator 节点上维护。常见示例包括管理员用户查找和其他实用程序表。

考虑一个类似于 Etsy 或  Shopify 的示例多租户应用程序，其中每个租户都是商店。这是简化  schema 的一部分：

（带下划线的项目是主键，斜体项目是外键。）

在此示例中，商店是自然租户。在这种情况下，租户 ID 是  store_id 。在集群中分布表之后，我们希望与同一存储相关的行一起驻留在同一节点上。

为迁移准备源表

一旦确定了所需数据库更改的范围，下一个主要步骤就是修改应用程序现有数据库的数据结构。首先，修改需要回填的表，为 dist