在分片中，建议不要分享任何内容，将所有内容都放在一边。本质上，这转换为：要一起使用的数据将被一起存储（即，在单个分片中）。这非常适合在应用程序级别哲学上分割数据。
但完全非规范化数据并不总是切实可行。例如，考虑一个电子商务网站。理想情况下，与用户相对应的所有数据应保持在一起。但是，一些数据，如产品可用性，需要在整个过程中同步。在某些情况下，如上所述，此同步需要实时发生。例如，假设用户已将产品添加到其愿望清单中。原则上，关于心愿单项目的所有数据应与用户的其他数据保持在一起。但是，多个用户可以列出相同的项目，其他用户也可以购买该项目，从而影响其可用性。因此，需要以某种方式共享和同步信息。
多连接带来的复杂性和性能影响也是众所周知的。
为了使问题更加棘手，可以预期在上述示例中，或者在任何情况下需要适当的ACID事务，同步必须实际上是实时的。如果喜欢的数量有延迟更新可能是可以接受的，但电子商务网站显示延迟的产品可用性数据将是不利的事情！
在这种情况下，最好的方法是什么？
一个初步思路是对可用性，交易状态等领域使用推送/通知机制。但我真的很想听听专家的意见。显然，我已经在High Scalability上阅读了关于eBay架构的内容，但它没有涉及这个级别的实现细节。
关于dba.stackexchange，有一个相关的相关讨论，但问题多于答案。
EDIT / UPDATE： 考虑的数据库是Postgres。
答案 0 :(得分：1)
您没有具体指定任何数据库，因此我将讨论一些真正高端的网格框架如何在PostgreSQL上解决这个问题。如果没有别的，这将为您提供答案的起点。
出于本讨论的目的，格子框架是一个基本上具有一系列协调分片的框架，它们看起来像一个数据库。可以说存在一些差异，特别是在工具方面，但它们遇到的问题完全相同。格式通过两阶段提交等方式管理存储节点，允许协调员有效地强制执行跨分片参照完整性。 Pg世界中最常用的框架是Postgres-XL。
使用Postgres-XL（以前称为StormDB），您可以在协调器和存储节点之间进行划分。每个存储节点实际上都是一个分片。协调器节点管理对存储节点的访问，并将整个存储节点集显示为单个连贯的数据库。
几点：
在这种情况下，您的选择是接受跨节点性能命中或同步数据。如果你执行后者，你的写入将永远不会比最慢的节点更快，所以你不想用经常写入的数据来做这件事。
这有效意味着您必须确定经常写入的数据和最稳定的数据。稳定的数据可以同步。易变数据不应该是。
因此，在电子商务解决方案中，如果您的零件目录非常稳定，您可以同步它，然后分割客户和订单。但是，部分的实时现有数据不会在主机之间复制，而是单独进行分片/分区，以便对此进行更新也可以进行写扩展。因此，有时您必须考虑将现有表分解为稳定且易变的部分。