目录
-
确定分布策略
-
选择分布键
-
确定表的类型
-
为迁移准备源表
-
添加分布键
-
回填新创建的列
-
准备申请 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)”
。用例可能会有所不同,因此我们建议您在此步骤中进行彻底检查。
如需指导,请阅读以下部分:
-
确定应用程序类型
-
https://docs.citusdata.com/en/v10.2/develop/app_type.html#app-type
-
-
选择分布列
-
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
表格通常属于以下类别之一:
-
准备分发。 这些表已经包含
distribution key
,并准备好分发。 -
需要回填。 这些表可以按所选
key
进行逻辑分布,但不包含直接引用它的列。稍后将修改这些表以添加该列。 -
参考表。 这些表通常很小,不包含
distribution key
,通常由分布式表连接,和/或在租户之间共享。这些表中的每一个的副本将在所有节点上维护。常见示例包括国家代码查找、产品类别等。 -
本地表。 这些通常不连接到其他表,并且不包含
distribution key
。它们仅在coordinator
节点上维护。常见示例包括管理员用户查找和其他实用程序表。
考虑一个类似于 Etsy
或 Shopify
的示例多租户应用程序,其中每个租户都是商店。这是简化 schema
的一部分:
(带下划线的项目是主键,斜体项目是外键。)
在此示例中,商店是自然租户。在这种情况下,租户 ID
是 store_id
。在集群中分布表之后,我们希望与同一存储相关的行一起驻留在同一节点上。
为迁移准备源表
一旦确定了所需数据库更改的范围,下一个主要步骤就是修改应用程序现有数据库的数据结构。首先,修改需要回填的表,为 dist