Si vous avez plusieurs serveurs Web, avec plusieurs processus, il n'y a vraiment rien que vous puissiez supprimer en perdant l'unicité.
Si vous regardez la nature de l'ObjectId :
- une valeur de 4 octets représentant les secondes depuis l'époque Unix,
- un identifiant de machine de 3 octets,
- un identifiant de processus de 2 octets, et
- un compteur de 3 octets, commençant par une valeur aléatoire.
Vous verrez qu'il n'y a pas grand-chose que vous puissiez supprimer en toute sécurité. Comme les 4 premiers octets sont l'heure, il serait difficile d'implémenter un algorithme qui supprime des parties de l'horodatage de manière propre et sûre.
L'identifiant de machine et l'identifiant de processus sont utilisés dans les cas où plusieurs serveurs et/ou processus agissent en tant que clients du serveur de base de données. Si vous avez laissé tomber l'un de ceux-ci, vous pourriez vous retrouver avec des doublons à nouveau. La valeur aléatoire comme les 3 derniers octets est utilisée pour s'assurer que deux identifiants, sur la même machine, dans le même processus sont uniques, même lorsqu'ils sont demandés fréquemment.
Si vous l'utilisiez comme id de commande , et vous voulez une unicité assurée, je ne supprimerais rien du nombre de 12 octets car il a été soigneusement conçu pour fournir un mécanisme distribué robuste et efficace pour générer des numéros uniques lorsqu'il existe de nombreux clients de base de données connectés.
Si vous avez pris les 5 derniers caractères de l'ObjectId..., et sur une période donnée, quelle est la probabilité de conflit ?
- identifiant de processus
- compteur
La probabilité de conflit est élevée . L'ID de processus peut rester le même pendant toute la période, et l'autre numéro est juste un numéro incrémentiel qui se répétera après 4095 commandes. Mais, si le processus se recycle, vous avez également la possibilité qu'il y ait un conflit avec des commandes plus anciennes, etc. Et si vous parlez de plusieurs clients de base de données, les chances augmentent également. Je n'essaierais tout simplement pas de réduire le nombre. Cela ne vaut pas la peine que les clients mécontents essaient de passer des commandes.
Même l'horodatage et la valeur de départ aléatoire ne sont pas suffisants lorsque plusieurs clients de base de données génèrent des ObjectIds . Lorsque vous commencez à examiner les différentes pièces, en particulier dans le contexte d'une ferme de clients de base de données, vous devriez voir pourquoi les pièces sont là et pourquoi les supprimer pourrait entraîner un effondrement dans ObjectId génération.
Je vous suggère de mettre en œuvre un algorithme pour créer un numéro unique et le stocker dans la base de données. C'est assez simple à faire. Cela a un peu d'impact sur les performances, mais c'est sûr.
J'ai écrit ceci
répondre il y a quelque temps sur les défis de l'utilisation d'un ObjectId dans une Url. Il comprend un lien vers la création d'un numéro unique à incrémentation automatique à l'aide de MongoDB.
