Vous devriez choisir l'option 1.
La raison principale est que vous dites que vous vous inquiétez des performances - l'utilisation de l'index _id qui est toujours là et déjà unique vous permettra d'éviter d'avoir à maintenir un deuxième index unique.
Pour l'option 1, je m'inquiète des performances d'insertion du fait d'avoir des clés non séquentielles. Je sais que cela peut tuer les systèmes RDBMS traditionnels et j'ai vu des indications que cela pourrait également être vrai dans MongoDB.
Vos autres options n'évitent pas ce problème, elles le déplacent simplement de l'index _id vers l'index unique secondaire - mais maintenant vous avez deux index, l'un équilibré à droite et l'autre à accès aléatoire.
Il n'y a qu'une seule raison de remettre en question l'option 1 et c'est si vous prévoyez d'accéder aux documents par une ou l'autre valeur UUID. Tant que vous fournissez toujours les deux valeurs et (cette partie est très importante) que vous les ordonnez toujours de la même manière dans toutes vos requêtes, l'index _id remplira efficacement son rôle.
Pour expliquer pourquoi vous devez vous assurer de toujours ordonner les deux valeurs UUID de la même manière, lorsque vous comparez des sous-documents { a:1, b:2 } n'est pas égal à { b:2, a:1 } - vous pourriez avoir une collection où deux documents avaient ces valeurs pour _id. Donc, si vous stockez _id avec le champ a en premier, vous devez toujours conserver cet ordre dans tous vos documents et requêtes.
L'autre précaution est que l'index sur _id:1 sera utilisable pour la requête :
db.collection.find({_id:{a:1,b:2}})
mais ce ne sera pas être utilisable pour la requête
db.collection.find({"_id.a":1, "_id.b":2})
