Powinieneś wybrać opcję 1.
Głównym powodem jest to, że martwisz się o wydajność – użycie indeksu _id, który jest zawsze obecny i już unikalny, pozwoli Ci zaoszczędzić na konieczności utrzymywania drugiego unikalnego indeksu.
W przypadku opcji 1 martwię się o wydajność wstawiania do posiadania kluczy niesekwencyjnych. Wiem, że może to zabić tradycyjne systemy RDBMS i widziałem wskazówki, że może to być prawdą również w MongoDB.
Twoje inne opcje nie pozwalają uniknąć tego problemu, po prostu przesuwają go z indeksu _id do drugorzędnego unikalnego indeksu - ale teraz masz dwa indeksy, raz zbalansowany w prawo, a drugi z dostępem losowym.
Istnieje tylko jeden powód, aby kwestionować opcję 1, a mianowicie, jeśli planujesz uzyskać dostęp do dokumentów za pomocą tylko jednej lub tylko drugiej wartości UUID. Tak długo, jak zawsze podajesz obie wartości i (ta część jest bardzo ważna) zawsze porządkujesz je w ten sam sposób we wszystkich swoich zapytaniach, indeks _id będzie skutecznie spełniał swoje zadanie.
Jako wyjaśnienie, dlaczego musisz się upewnić, że zawsze porządkujesz dwie wartości UUID w ten sam sposób, podczas porównywania poddokumentów { a:1, b:2 } nie jest równe { b:2, a:1 } - możesz mieć kolekcję, w której dwa dokumenty mają te wartości dla _id. Więc jeśli najpierw przechowujesz _id z polem, musisz zawsze zachować tę kolejność we wszystkich swoich dokumentach i zapytaniach.
Inną przestrogą jest to, że indeks _id:1 będzie użyteczny dla zapytania:
db.collection.find({_id:{a:1,b:2}})
ale to nie być użytecznym dla zapytania
db.collection.find({"_id.a":1, "_id.b":2})
