No, non è affatto male e in effetti è integrato ObjectId è abbastanza grande all'interno dell'indice, quindi se ritieni di avere qualcosa di meglio, sei più che benvenuto a cambiare il valore predefinito di _id campo a qualunque cosa.
Ma, e questo è un grande ma , ci sono alcune considerazioni quando si decide di allontanarsi dall'ObjectId predefinito formulato , in particolare quando si utilizzano gli _ids a incremento automatico come mostrato qui:https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field
Il multithreading non è un grosso problema perché findAndModify e le serrature atomiche possono effettivamente occuparsene, ma poi hai appena colpito il tuo primo problema. findAndModify non è la funzione più veloce né la più leggera e si sono verificati significativi cali di prestazioni durante l'uso regolare.
Devi anche considerare il sovraccarico di farlo da solo, anche senza findAndModify . Per ogni inserto avrai bisogno di una query in più. Immagina di avere un ID univoco che devi interrogare sull'unicità di ogni volta che vuoi inserire. Alla fine la tua frequenza di inserimento scenderà a una scansione e il tuo tempo di blocco aumenterà.
Naturalmente il ObjectId è davvero bravo ad essere unico senza dover controllare o formulare la propria unicità toccando il database prima dell'inserimento, quindi non ha questo sovraccarico.
Se ritieni ancora che un intero _id sia adatto al tuo scenario, allora provaci, ma tieni a mente il sovraccarico descritto sopra.
