基于Google平台的PolyGlot数据库设计

Question

我正在设计一个全球ERP /调度系统，它必须托管在Google和Google上。

在大多数情况下，数据是强关系的，体积不大或易失性大，因此自然适合关系数据库。

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

这个问题--由于地址/联系人详细信息格式对于所有这些场景、不同国家和多个电话号码等都有很大的不同，我认为地址& CONTACTDETAILS应该移到DataStore中，并通过id从Cloud平台引用它们。因此，该结构是完全灵活的，以适应世界的地址格式。

这听起来合理吗?还是说它超出了设计解决方案的范围，应该只在CLoud SQL中使用通用地址表？

我有一个担心，因为谷歌平台的瓶颈似乎是唯一的MySQL主人。这是一个限制在16个vCPU上的托管服务，所以我尝试将更多的功能区转移到Datastore中。

希望这是合理的！

Answer 1

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

• 您提到了16 vCPU限制-虽然会更容易扩展(就像我们为您做的那样)，但地址不太可能成为担心的理由。
• 对于具有更多样化的模式需求的数据，由于您已经在使用，所以可以简单地使用JSON类型来存储它。只要你在上。
• 事务:如果需要同时涉及Cloud和Cloud中的数据的操作才是事务性的，则必须自己实现。如果你能忍受潜在的矛盾和/或清理，没问题。
• Cloud肯定会允许您更灵活地存储这种类型的数据，并在规模上高效地查询它。这是它擅长的那种用例。