Sie sollten sich für Option 1 entscheiden.
Der Hauptgrund ist, dass Sie sich Sorgen um die Leistung machen - die Verwendung des _id-Index, der immer vorhanden und bereits eindeutig ist, ermöglicht es Ihnen, sich die Pflege eines zweiten eindeutigen Index zu ersparen.
Bei Option 1 mache ich mir Sorgen um die Einfügeleistung, die auf nicht sequentielle Schlüssel zurückzuführen ist. Ich weiß, dass dies herkömmliche RDBMS-Systeme töten kann, und ich habe Anzeichen dafür gesehen, dass dies auch in MongoDB der Fall sein könnte.
Ihre anderen Optionen vermeiden dieses Problem nicht, sie verschieben es nur vom _id-Index zum sekundären eindeutigen Index - aber jetzt haben Sie zwei Indizes, einmal das ist rechtsbalanciert und das andere ist der wahlfreie Zugriff.
Es gibt nur einen Grund, Option 1 in Frage zu stellen, und zwar, wenn Sie vorhaben, nur über einen oder nur den anderen UUID-Wert auf die Dokumente zuzugreifen. Solange Sie immer beide Werte angeben und (dieser Teil ist sehr wichtig) Sie sie in all Ihren Abfragen immer auf die gleiche Weise anordnen, erfüllt der _id-Index effizient seinen vollen Zweck.
Als Erläuterung, warum Sie sicherstellen müssen, dass Sie die beiden UUID-Werte immer auf die gleiche Weise anordnen, wenn Sie die Unterdokumente { a:1, b:2 } vergleichen ist nicht gleich { b:2, a:1 } - Sie könnten eine Sammlung haben, in der zwei Dokumente diese Werte für _id hatten. Wenn Sie also zuerst _id mit Feld a speichern, müssen Sie diese Reihenfolge in all Ihren Dokumenten und Abfragen immer beibehalten.
Die andere Vorsicht ist dieser Index auf _id:1 wird für die Abfrage verwendbar sein:
db.collection.find({_id:{a:1,b:2}})
aber es wird nicht für die Abfrage
verwendbar seindb.collection.find({"_id.a":1, "_id.b":2})
