Měli byste zvolit možnost 1.
Hlavním důvodem je, že říkáte, že se obáváte o výkon – použití indexu _id, který je vždy k dispozici a již jedinečný, vám umožní ušetřit nutnost udržovat druhý jedinečný index.
U možnosti 1 se obávám o výkon vložky při použití nesekvenčních klíčů. Vím, že to může zabít tradiční systémy RDBMS a viděl jsem náznaky, že by to mohla být pravda i v MongoDB.
Vaše další možnosti se tomuto problému nevyhnou, pouze jej přesunou z indexu _id na sekundární jedinečný index – ale nyní máte dva indexy, jeden je správně vyvážený a druhý s náhodným přístupem.
Existuje pouze jeden důvod ke zpochybnění možnosti 1, a to pokud plánujete přistupovat k dokumentům pouze pomocí jedné nebo pouze druhé hodnoty UUID. Dokud vždy poskytujete obě hodnoty a (tato část je velmi důležitá) je vždy seřadíte stejným způsobem ve všech svých dotazech, pak bude index _id efektivně sloužit svému plnému účelu.
Jako vysvětlení, proč se musíte ujistit, že vždy objednáváte dvě hodnoty UUID stejným způsobem, při porovnávání vnořených dokumentů { a:1, b:2 } se nerovná { b:2, a:1 } - mohli byste mít kolekci, kde dva dokumenty měly tyto hodnoty pro _id. Pokud tedy uložíte _id s polem a jako první, musíte toto pořadí vždy zachovat ve všech svých dokumentech a dotazech.
Další upozornění je, že index na _id:1 bude použitelný pro dotaz:
db.collection.find({_id:{a:1,b:2}})
ale nebude být použitelný pro dotaz
db.collection.find({"_id.a":1, "_id.b":2})