Je ne suis pas du tout d'accord avec l'auteur de la réponse choisie qui dit que Il n'y a pas d'auto-incrémentation de l'id dans MongoDB et il y a de bonnes raisons. . Nous ne savons pas pourquoi 10gen n'a pas encouragé l'utilisation d'identifiants auto-incrémentés. C'est de la spéculation. Je pense que 10gen a fait ce choix parce qu'il est simplement plus facile d'assurer l'unicité des ID de 12 octets dans un environnement en cluster. C'est une solution par défaut qui convient à la plupart des nouveaux arrivants et qui augmente donc l'adoption du produit, ce qui est bon pour les affaires de 10gen.
Laissez-moi maintenant vous parler de mon expérience avec les ObjectIds dans un environnement commercial.
Je suis en train de créer un réseau social. Nous avons environ 6 millions d'utilisateurs et chaque utilisateur a environ 20 amis.
Imaginons maintenant que nous ayons une collection qui stocke les relations entre les utilisateurs (qui suit qui). Cela ressemble à ceci
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
sur lequel nous avons un indice composite unique {user_id, followee_id} . Nous pouvons estimer la taille de cet index à 12*2*6M*20 = 2GB. Voilà l'index pour la recherche rapide des personnes que je suis. Pour une recherche rapide des personnes qui me suivent, j'ai besoin d'un index inverse. Cela représente 2 Go supplémentaires.
Et ce n'est que le début. Je dois porter ces identifiants partout. Nous avons un cluster d'activité où nous stockons votre fil d'actualité. C'est chaque événement que vous ou vos amis font. Imaginez l'espace que ça prend.
Et finalement, l'un de nos ingénieurs a pris une décision inconsciente et a décidé de stocker les références sous forme de chaînes qui représentent l'ObjectId, ce qui double sa taille.
Que se passe-t-il si un index ne tient pas dans la RAM ? Rien de bon, dit 10gen :
Lorsqu'un index est trop volumineux pour tenir dans la RAM, MongoDB doit lire l'index depuis le disque, ce qui est une opération beaucoup plus lente que la lecture depuis la RAM. Gardez à l'esprit qu'un index tient dans la RAM lorsque votre serveur dispose de RAM pour l'index combiné au reste de l'ensemble de travail.
Cela signifie que les lectures sont lentes. La contention des verrous augmente. Les écritures deviennent également plus lentes. Voir la contention des verrous dans 80% des cas n'est plus un choc pour moi.
En un rien de temps, vous vous retrouvez avec un cluster de 460 Go que vous devez diviser en fragments et qui est assez difficile à manipuler.
Facebook utilise un nom long de 64 bits comme identifiant d'utilisateur :) Il y a une raison à cela. Vous pouvez générer des identifiants séquentiels
- en utilisant Le conseil de 10gen .
- en utilisant mysql comme stockage des compteurs (si vous êtes préoccupé par la vitesse, jetez un coup d'œil à handlersocket )
- en utilisant le service de génération d'ID que vous avez créé ou en utilisant quelque chose comme Flocon de neige par Twitter.
Voici donc le conseil général que je donne à tout le monde. Faites en sorte que vos données soient aussi petites que possible. Lorsque vous vous développerez, cela vous épargnera de nombreuses nuits blanches.
