1

我知道对于一个写入繁重的应用程序，使用 ObjectId 对于分片键来说是一个非常糟糕的主意。但是，使用 Java 中的本机 *UUID.randomUUID()作为分片键是否是个好主意，因为它们是真正随机的，不会导致单个分片出现热点。

这些 ID 是128 位 ID，如下所示：

  • 5842fa92557947f1b020041ff74868a4
  • 308947443e564d80b97dd8411b4b727e
  • f8a7ee765bed4ce3bcc5800ac3a2a710
  • 1bcfd08b89e94c58ae7695b3e7a1bc4f

它与 ObjectId (96bit int) 非常相似。

另外，由于在 _id 上必须有一个索引，所以分片键将是 _id，我们将通过为 shard_key 创建另一个索引来节省 RAM。一切集合都准备好进行分片。

是因为Mongod的性能问题还是磁盘/内存空间问题？

UUID 的冲突率是（来自维基百科）： 仅在接下来的 100 年每秒生成 10 亿个 UUID 之后，仅创建一个副本的概率约为 50%。如果地球上每个人都拥有 6 亿个 UUID，那么出现重复的概率约为 50%。

4

3 回答 3

2

使用 UUID 会将您的写访问权限分布在各个分片上，但您不会有查询隔离，因此您的查询结果不会达到最佳。最快的查询是只有一个分片回答的查询。 http://docs.mongodb.org/manual/core/sharding-internals/#sharding-shard-key-query-isolation

这将有助于了解您的收藏中的内容，从而更有效地帮助您。

于 2012-12-07T21:37:19.747 回答
1

使用 UUID 是完全可以的（前提是您只需要通过它们的主/分片键来查找这些文档）。shard key 的目的之一是将相关文档组合在一起。如果我们正在构建，比如说，flickr，我们的分片键将以 开头user_id，以便用户的照片一起放在一个分片上。如果您的文档不相关并且主键也是分片键，那么没有问题。

于 2012-12-07T17:16:59.567 回答
1

由于https://jira.mongodb.org/browse/JAVA-403，您可能会遇到问题，该问题计划在下一个版本中修复。

于 2012-12-08T14:20:02.047 回答