Трябва да изберете опция 1.
Основната причина е, че казвате, че се притеснявате за производителността - използването на индекса _id, който винаги е там и вече е уникален, ще ви позволи да спестите необходимостта да поддържате втори уникален индекс.
За вариант 1 се притеснявам за производителността на вмъкване, за да имам непоследователни клавиши. Знам, че това може да убие традиционните RDBMS системи и видях индикации, че това може да е вярно и в MongoDB.
Другите ви опции не избягват този проблем, те просто го преместват от индекса _id към вторичния уникален индекс - но сега имате два индекса, веднъж балансиран вдясно, а другият с произволен достъп.
Има само една причина да поставите под въпрос опция 1 и това е, ако планирате да получите достъп до документите само с една или само другата стойност на UUID. Докато винаги предоставяте и двете стойности и (тази част е много важна) винаги ги подреждате по един и същи начин във всичките си заявки, тогава индексът _id ще служи ефективно на пълната си цел.
Като уточнение защо трябва да сте сигурни, че винаги подреждате двете стойности на UUID по един и същи начин, когато сравнявате поддокументи { a:1, b:2 } не е равно на { b:2, a:1 } - можете да имате колекция, в която два документа имат тези стойности за _id. Така че, ако първо съхранявате _id с поле a, тогава винаги трябва да поддържате този ред във всичките си документи и заявки.
Другото предупреждение е, че индексът на _id:1 ще може да се използва за заявка:
db.collection.find({_id:{a:1,b:2}})
но това не може да се използва за заявка
db.collection.find({"_id.a":1, "_id.b":2})
