Per ampliare leggermente quanto affermato da Andre:
Poiché il timestamp ObjectID è solo al secondo, è possibile creare facilmente due (o più) ObjectID con lo stesso valore per il timestamp (i primi 4 byte). Se questi fossero creati sulla stessa macchina (ID macchina - i prossimi 3 byte), dallo stesso processo (PID - i prossimi 2 byte), l'unica cosa per differenziarli sarebbe il campo "inc", gli ultimi 3 byte alla fine.
Aggiornamento:gennaio 2020
Questa risposta continua ad essere popolare, quindi vale la pena aggiornarla un po'. Le specifiche ObjectID si sono evolute da quando questa risposta è stata scritta 8 anni fa e i 5 byte dopo il timestamp ora sono semplicemente casuali, il che ridurrà notevolmente la probabilità di eventuali collisioni. Gli ultimi tre byte sono ancora incrementali, ma inizializzati con un valore casuale per iniziare, rendendo ancora una volta meno probabili le collisioni. L'ObjectID ora contiene meno contesto (non puoi facilmente dire dove è stato generato e da quale processo) ma suppongo che le informazioni non siano state utilizzate in modo significativo e siano state deprecate a favore di una migliore randomizzazione dell'ID.
Termina aggiornamento
Vedi qui per le specifiche complete:
https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectIDs-BSONObjectIDSpecification
Quel campo "inc" è un campo sempre crescente (quindi puoi ragionevolmente aspettarti che l'ordinamento sia nell'ordine di inserimento/creazione) o un valore casuale (quindi probabilmente unico, ma non ordinato), supponendo che le specifiche siano implementate correttamente ovviamente . Nota che gli ObjectID possono essere generati dal driver o dall'applicazione (o addirittura manualmente) piuttosto che da MongoDB stesso, quindi a meno che tu non abbia il pieno controllo su come vengono generati, allora uno o tutti i precedenti potrebbero essere applicati.
