切分如何处理相关表格的连接？

Question

当我读到关于切分的文章时，作者似乎没有考虑到切分表必须连接到的其他表(尽管他们将碎片描述为“原始数据库的子集”)。然而，这是一个非常普遍的情况，我仍然不知道如何处理。一些作者提到了由可复制到每个碎片(例如，Country)的切分表引用的“静态”表。但是，对于引用切分表的表，他们什么也没有说。

假设我们运行了一个社交网络，并意识到我们的用户表(id，name)由于大量的写操作或大小(或两者兼而有之)而不再适合单个服务器。因此，我们决定将其水平地划分为多个碎片(例如，4，因此id 1-1000的用户转到一个碎片，1001-2000转到另一个碎片等)。并选择一个User.id作为碎片键。由于用户表通常被连接到其他表中，所以我们将记录从引用给定用户或由其引用的表移到相应的碎片(这是一个相当大的挑战，因为关系通常是传递的，例如，表A可能引用引用切分表C的B)。为了简化事情，我们可以决定将除User表之外的所有数据复制到所有碎片中。到目前一切尚好。

然后，想象一下之友表(id、user_id、friend_id)，其中包含关于谁是who的朋友的信息，并引用用户表。一个用户1001有两个朋友，2002年和3003，他们位于不同的碎片。因此，如果我们需要获取有关用户1001朋友的信息，我们必须执行两个交叉切分联接。即使我们最初设法将所有相关用户放在同一个碎片上，用户也可以从不同的碎片中添加一个新朋友。我们不能将这个朋友4004移动到用户1001，因为来自同一个碎片#5的其他用户也可以将他作为朋友。

老实说，我不知道在执行切分时是如何处理这种情况的，而且我还没有看到任何解释这种情况的资源。

Answer 1

当跨切分表进行连接时，通常要优化的是正在通过碎片传输的数据量。

按照解释的这里，有5种类型的分布式连接，它们是从最优先排序到最少的：

1. 本地/配置参考表连接

这是您在Countries表中提到的示例。每个节点都在本地保存此表的副本，因为它很少更新。优点和缺点是显而易见的:并不是所有的东西都可以标记为参考表，但不涉及数据移动。

1. 本地/配置分布式表加入

这意味着向连接所需数据所在的所有节点发送查询。然后，对整个执行结果进行聚合。缺点是需要在联接条件中涉及的列上对表进行切分。这是最可伸缩的算法，因为它在进行连接之前不涉及数据移动。

这将适用于您的Friends表示例。据推测，您的Users表将由用户id键(这也是切分键)键确定，因此将有一个索引，因此查询应该是快速的。

1. 远程分布式表加入

集群中的所有节点都会将连接两侧的数据发送到单个节点，以便运行连接。只有当连接中涉及的行数较少时，这种类型的联接才能很好地执行。

1. 广播加入

如果您正在进行连接，其中一方有大型数据集，另一方有小数据集，则此类型将小数据集发送到较大的数据集，而具有大型数据集的节点在本地进行连接。

1. 洗牌加入

这是运行分布式连接的最昂贵但最灵活的方法。由于连接中涉及的许多行被复制到其他节点以执行连接，因此需要进行大量的数据移动。