mongodb - shard键-复合vs散列

Question

我正在使用现有的mongodb集合。数据如下所示：

{ user_id: 123, post: { id: 123456789, title: "..." } },
{ user_id: 123, post: { id: 123456790, title: "..." } },
{ user_id: 124, post: { id: 123456791, title: "..." } }

我需要把这个收藏撕成碎片，而且我在选择一个碎片钥匙时遇到了困难。我经常根据用户执行操作(例如，从用户123获取所有帖子)。是否应该创建一个基于

{
  user_id: 1,
  post.id: 1
}

还是一样的，但是散列了吗？

如果它是散列的，我假设范围查询将被广播到所有碎片。但是如果是而不是散列，那么文档会在碎片之间平均分配吗？您可以看到这些值单调地增加。

谢谢,

编辑:我想我犯了一个错误，似乎复合索引不能散列。来自文档(https://docs.mongodb.com/manual/core/index-compound)：

不能创建具有散列索引类型的复合索引。如果尝试创建包含散列的复合索引，则会收到错误。

我想这意味着这个问题是不明智的，所以我将结束。

编辑2:再想一想，这个问题是有效的，但它的措辞更好一些--我似乎有两个选择：

1. 散列post.id字段(应该是唯一的)，如果散列将有助于确保数据在碎片之间的均匀分布，或
2. 创建user_id和post.id的复合键，就像上面的代码一样。这还将确保唯一性，并应有助于单个用户的数据局部性。，但它能确保数据在碎片之间的均匀分布吗？

谢谢

Answer 1

散列post.id字段(应该是唯一的)，如果散列，将有助于确保数据在碎片之间的均匀分布。

如果您的If是单调的(如当前示例所示)，我将强烈考虑使用UUID/GUID，它可以在不依赖中心序列的情况下生成。除非您的序列号是由另一个记录系统提供的，否则它们将为需要声明下一个可用编号的分布式客户端引入一个缩放和协调挑战。GUID将更有效地实现您希望通过散列实现的结果。

MongoDB的默认ObjectId就是为此目的而设计的一个例子:一个伪随机的12字节值，它可以在分布式环境中独立地生成，并且有一些基于前导时间戳的近似排序。

生成自定义UUID超出了MongoDB的范围，但是如果您有其他要求(长度、值的范围、排序、碰撞的可能性、.)有许多可用的算法/库来生成UUID，或者您可以创建自己的公式。

切分键值的基数决定了您是否会得到有效的数据分布。哈希碎片键可以帮助分发初始写入，前提是原始值中存在基数:这基本上是将序列从单调递增更改为一致。

创建user_id和post.id的复合键，就像上面的代码一样。这还将确保唯一性，并应有助于单个用户的数据局部性。，但它能确保数据在碎片之间的均匀分布吗？

切分键需要很高的基数，但不一定是唯一的。例如，如果在单个字段(即{month:1} (代表一年中的几个月)上)切分，则该字段只有12个可能的值。一个月的所有数据都将在单个碎片上结束，因此，如果第5个月的值大于第11个月的值，则数据分布将本质上是不均匀的。MongoDB用于切分集合的数据分布是基于能够自动将切分键划分为越来越小的键范围(称为块)。一个基本的假设是，每个块表示大致相等范围的数据(平均)，即使是块在碎片之间的分布也会导致平衡。

对于您的用例，假设您解决了单调增加ID的问题，{user_id, post.id}似乎是一个可能的组合碎片键。这似乎符合我前面提到的三个方面。

然而，与其猜测切碎的关键结果，我建议在开发环境中测试这一点。

如果您对数据模型和分布模式有很好的理解或估计，我建议在测试环境中使用有代表性的数据进行切分。如果需要的话，有很多有用的工具来生成假的(但概率的)数据。有关使用模式分析和“更类似于此”方法的示例配方，请参见：将集合复制到自身中。