Pour développer un peu ce qu'a dit André :
Étant donné que l'horodatage d'ObjectID n'est qu'à la seconde, deux (ou plus) ObjectID peuvent facilement être créés avec la même valeur pour l'horodatage (les 4 premiers octets). Si ceux-ci ont été créés sur la même machine (ID machine - les 3 octets suivants), par le même processus (PID - les 2 octets suivants), alors la seule chose qui les différencierait serait le champ "inc", les 3 derniers octets à la fin.
Mise à jour :janvier 2020
Cette réponse continue d'être populaire, il vaut donc la peine de la mettre à jour un peu. La spécification ObjectID a évolué depuis que cette réponse a été écrite il y a 8 ans et les 5 octets après l'horodatage sont désormais simplement aléatoires, ce qui réduira considérablement la probabilité de collisions. Les trois derniers octets sont toujours incrémentiels, mais initialisés à une valeur aléatoire pour démarrer, ce qui rend à nouveau les collisions moins probables. L'ObjectID contient maintenant moins de contexte (vous ne pouvez pas facilement dire où il a été généré et par quel processus) mais je suppose que l'information n'était pas utilisée de manière significative et a été dépréciée en faveur d'une meilleure randomisation de l'ID.
Finir la mise à jour
Voir ici pour la spécification complète :
https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectIDs-BSONObjectIDSpecification
Ce champ "inc" est soit un champ toujours incrémenté (alors vous pouvez raisonnablement vous attendre à ce que le tri soit dans l'ordre d'insertion/création) ou une valeur aléatoire (alors probablement unique, mais pas ordonnée), en supposant que la spécification est implémentée correctement bien sûr . Notez que les ObjectID peuvent être générés par le pilote ou l'application (ou même manuellement) plutôt que par MongoDB lui-même, donc à moins que vous n'ayez un contrôle total sur la façon dont ils sont générés, alors tout ou partie de ce qui précède peut s'appliquer.
