我正在开发一个在 mongodb 上运行的多租户应用程序。每个租户可以创建多个应用程序。大多数集合的架构通过 ObjectID 引用其他集合。我正在考虑使用以下格式手动创建一个分片键：
(v3 murmurhash of the record's ObjectId) + (app_id.toHexString())
这是否足以确保任何特定应用程序的记录最终都可能在同一个分片上？
此外，如果某个特定应用程序与分片上的所有其他应用程序相比变得超大，会发生什么情况？
【问题讨论】：
如果您使用基于散列的分片键并且输入不断变化（ObjectID 通常可以被认为对于每条记录都是唯一的），那么您将根本无法获得分片上的数据局部性（巧合除外），尽管它会通过在所有分片上随机分布写入来为您提供出色的写入吞吐量。这基本上是这种方法的权衡，内置hash based sharding也是如此，这些权衡不会因为它是由两个字段构成的手动哈希而改变。
基本上，因为 MongoDB 使用基于范围的块来拆分给定分片键的数据，在这种情况下，您将使用连续的哈希范围作为块。假设您的哈希在某种程度上没有错误，那么单个顺序范围内的数据基本上是随机的。因此，即使在单个块中，您也没有数据局部性，更不用说在分片上，它将是完全随机的（根据设计）。
如果您希望能够将应用程序按范围分组在一起，从而更有可能位于特定分片上，那么您最好预先添加 app_id 以使其成为复合分片键中最左侧的字段.像下面这样的分片将（基于有限的描述）是一个好的开始：
{app_id : 1, _id : 1}
尽管 ObjectID 会随着时间的推移单调增加（更多关于 here 的讨论），但如果有相当数量的应用程序 ID 并且您要对 ObjectID 执行任何基于范围或有针对性的查询，那么它可能不过仍然可以正常工作。您可能还希望根据您的查询模式包含其他字段。
请记住，无论您最常见的查询模式是什么，您都希望分片键（理想情况下）尽可能满足它。它必须被索引，它已被mongos 用来决定路由查询（如果没有，那么它是scatter/gather），所以如果你要不断地查询app_id 和_id 那么上面的分片键很有意义。
如果您使用手动散列密钥方法，您不仅会有随机分布，而且除非您要查询该散列，否则它不会很有用。
【讨论】：