Dovresti scegliere l'opzione 1.
Il motivo principale è che dici di essere preoccupato per le prestazioni:l'utilizzo dell'indice _id che è sempre presente e già unico ti consentirà di risparmiare dovendo mantenere un secondo indice univoco.
Per l'opzione 1, sono preoccupato per le prestazioni dell'inserto per avere chiavi non sequenziali. So che questo può uccidere i tradizionali sistemi RDBMS e ho visto indicazioni che questo potrebbe essere vero anche in MongoDB.
Le altre tue opzioni non evitano questo problema, lo spostano semplicemente dall'indice _id all'indice univoco secondario, ma ora hai due indici, uno bilanciato a destra e l'altro ad accesso casuale.
C'è solo un motivo per mettere in dubbio l'opzione 1 ed è se si prevede di accedere ai documenti solo per uno o solo per l'altro valore UUID. Finché fornisci sempre entrambi i valori e (questa parte è molto importante) li ordini sempre allo stesso modo in tutte le tue query, l'indice _id servirà in modo efficiente al suo scopo.
Come elaborazione sul motivo per cui devi assicurarti di ordinare sempre i due valori UUID allo stesso modo, quando confronti i documenti secondari { a:1, b:2 } non è uguale a { b:2, a:1 } - potresti avere una raccolta in cui due documenti avevano quei valori per _id. Quindi, se memorizzi _id con un campo prima, devi sempre mantenere quell'ordine in tutti i tuoi documenti e query.
L'altra cautela è l'indice su _id:1 sarà utilizzabile per la query:
db.collection.find({_id:{a:1,b:2}})
ma non essere utilizzabile per la query
db.collection.find({"_id.a":1, "_id.b":2})
