mysql - 在 Google Cloud Platform 上设计一个 PolyGlot 数据库

Question

我正在设计一个必须托管在 Google Cloud SQL 和 Google Datastore 上的全局 ERP/调度系统。

在大多数情况下，数据是强相关的，而且数据量不大或不稳定，因此非常适合关系数据库。

当前的设计将地址存储在本地的客户、契约(Contract)、员工、站点、工作单、contractedSites 表中……总共大约 12 个不同的地方。我要求 DEV 团队修改设计以创建一个地址表，该表可以被所有其他实体引用(必要时使用链接表来为地址历史、多个地址等提供灵 active )。

问题 -由于所有这些场景、不同国家和多个电话号码等的地址/联系人详细信息格式大不相同，我认为应该将地址和联系人详细信息移动到数据存储并通过 Cloud SQL 平台的 ID 引用它们。因此该结构非常灵活，可以适应世界各地的地址格式。

这听起来是否明智，或者是否过度设计了解决方案，应该只使用 CLoud SQL 中的通用地址表？

我担心 Google 平台的瓶颈似乎是单个 MySQL 主服务器。这是一项仅限于 16 个 vCPU 的托管服务，因此我正尝试将更多功能区域移至数据存储区。

希望这是有道理的!

Answer 1

您当然可以做到这一点，而且不会是第一个运行混合数据库系统的人。不过，您会增加复杂性，在继续前进之前，您应该权衡几件事。

• 您提到了 16 个 vCPU 的限制 - 地址不太可能成为担心这一点的原因，尽管 Cloud Datastore 会更容易扩展(例如，我们会为您做这件事)

  <

• 对于具有更多样化模式要求的数据，由于您已经在使用 Could SQL，可以简单地使用 JSON 类型来存储它。 只要您使用的是 Cloud SQL Second Gen。

• 事务:如果您需要涉及 Cloud SQL 和 Cloud Datastore 中的数据的操作是事务性的，您必须自己实现。如果您可以忍受潜在的不一致和/或清理，没问题。

• Cloud Datastore 肯定会让您更灵活地存储此类数据并大规模高效查询。这是它擅长的用例。