使用Native Java UUID.getRandom（）作爲分片鍵和_id？

我明白，使用寫入沉重的應用程序時，使用ObjectId對於分片鍵來說是一個非常糟糕的主意。 但是，使用來自Java的native * UUID.randomUUID（）作爲Shard鍵是否是個好主意，因爲它們確實是隨機的，並且不會導致單個分片的熱點。使用Native Java UUID.getRandom（）作爲分片鍵和_id？

這些ID 128位ID，看起來像：

5842fa92557947f1b020041ff74868a4
308947443e564d80b97dd8411b4b727e
f8a7ee765bed4ce3bcc5800ac3a2a710
1bcfd08b89e94c58ae7695b3e7a1bc4f

它非常類似於的ObjectId （96bit int）。

另外，由於必須在_id上有索引，分片鍵將是_id，我們將通過爲shard_key創建另一個索引來節省RAM。一切收集都將準備好進行分片。

是否適用於Mongod或磁盤/內存空間問題的性能問題？

的UUID的碰撞率（from wikipedia）： 只有一點產生十億的UUID每秒未來100年後，創建只有一個重複的概率會約50％。如果地球上的每個人擁有6億個UUID，則一個重複的概率約爲50％。

來源

2012-12-07 Daniel Marcotte

使用UUID將分散你的寫訪問權限，但你不會有查詢隔離，所以你的查詢結果不會超過最佳結果。最快的查詢是隻有一個碎片回答的問題。 http://docs.mongodb.org/manual/core/sharding-internals/#sharding-shard-key-query-isolation

這將有助於瞭解您的收藏中有哪些內容可以更有效地幫助您。

來源

2012-12-07 21:37:19

所以我會更好地碎片，例如，我的帳戶使用_id和每個其他錶鏈接到我的帳戶（如傢俱，權利，訂單）基於新的索引使用AccountId？在AccountId + Furniture._id或者僅在AccountId上分片會更好，假設我將始終提供AccountId。 –

使用UUID是完全可以的（假設您只是按主鍵/分片鍵查找這些文檔）。分片鍵的目的之一是將相關文檔分組在一起。如果我們正在構建flickr，我們的分片鍵將以user_id開頭，以便用戶的照片坐在一個分片上。如果你的文檔不相關，主鍵也是分片鍵，那麼沒有問題。

來源

2012-12-07 17:16:59

有人知道爲什麼10gen從一開始就沒有這樣做，以避免讓開發者頭痛不已，假設這是正確的答案？ –

由於https://jira.mongodb.org/browse/JAVA-403，您可能會遇到問題，該問題將在下一個版本中解決。

來源

2012-12-08 14:20:02 jyemin

感謝指出這一點。另外，我不知道基準是否仍然是最新的，但是對於MongoDB，使用UUID和ObjectId似乎很麻煩。 –

使用Native Java UUID.getRandom（）作爲分片鍵和_id？

回答

相關問題