1

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

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

当前的设计将地址本地存储在 customer、contract、employee、site、workorder、contractedSites 表中......总共大约 12 个不同的地方。我要求 DEV 团队修改设计以创建一个可以被所有其他实体引用的 ADDRESS 表（如果需要，可以使用链接表为地址历史、多个地址等提供灵活性）。

问题 - 由于所有这些场景、不同国家和多个电话号码等的地址/联系方式格式差异很大，我认为应该将 ADDRESS 和 CONTACTDETAILS 移动到 DataStore 并通过来自 Cloud SQL 平台的 id 引用它们。因此，该结构完全灵活，可以适应世界各地的地址格式。

这听起来是明智的还是它过度设计了解决方案并且应该只使用 CLoud SQL 中的通用地址表？

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

希望这是有道理的！

4

1 回答 1

1

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

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

  • 对于具有更多样化架构要求的数据，由于您已经在使用 Can SQL，因此可以简单地使用 JSON 类型来存储它。只要您使用 Cloud SQL 第二代。

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

  • Cloud Datastore 肯定会为您提供更大的灵活性来存储此类数据并进行大规模高效查询。这是它擅长的用例。

于 2016-06-09T17:14:20.913 回答