Il est en fait facile d'obtenir la réponse en analysant le principe. Supposons que vous ayez une pile de nombres en main, de 1 à 100, ci-dessous :
Un mec vient te demander un numéro, tu lui en donnes un, ce n'est pas un problème.
Deux personnes sont arrivées ensemble et toutes deux vous ont demandé un numéro. Que devez-vous faire ? Venez lentement un par un, envoyez les uns après les autres, ralentissez mais ça y arrivera
Et si 10 personnes venaient en même temps et vous demandaient votre numéro ? Et si 100 personnes ?
Imaginez le nombre de personnes arrivant sous forme de demandes simultanées, et il n'est pas difficile de constater que l'attribution rapide des numéros est devenue un goulot d'étranglement. L'identification automatique n'est donc pas une bonne chose pour les SGBDR. Mais heureusement, les bases de données traditionnelles sont autonomes. Elles s’ajoutent simplement un verrou pour gérer la concurrence dans la mémoire, il n’y a donc pas de gros problème. MongoDB est une base de données distribuée. Plusieurs machines doivent se coordonner les unes avec les autres. Vous en obtenez 1, j'en reçois 2 et lui en obtient 3. Ce verrou doit être coordonné via le réseau, ce qui est très inefficace. Pensez à l'objectif de la distribution. L'un d'eux est d'améliorer la concurrence, donc les identifiants à incrémentation automatique et la concurrence élevée sont en fait contraires l'un à l'autre. Dans un environnement distribué, garantir une incrémentation correcte affectera inévitablement l'efficacité. De plus, l’ID auto-agrandissant n’a en réalité pas beaucoup d’avantages, sauf qu’il semble plus propre, il a donc été inévitablement abandonné. (N'oubliez pas que l'ObjectID peut en fait être trié, c'est-à-dire l'ordre du temps d'insertion)
Généralement dans MongoDB, vous n'utiliserez pas de modèle d'auto-incrémentation pour le champ _id, ni pour aucun autre champ, car il ne s'adapte pas aux bases de données contenant un grand nombre de documents. Généralement, la valeur par défaut ObjectId est plus idéale pour le _id.
文档上自己说,pas adapté aux bases de données comportant un grand nombre de documents,自增的不适合有大数量documents的数据库
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il est en fait facile d'obtenir la réponse en analysant le principe. Supposons que vous ayez une pile de nombres en main, de 1 à 100, ci-dessous :
Un mec vient te demander un numéro, tu lui en donnes un, ce n'est pas un problème.
Deux personnes sont arrivées ensemble et toutes deux vous ont demandé un numéro. Que devez-vous faire ? Venez lentement un par un, envoyez les uns après les autres, ralentissez mais ça y arrivera
Et si 10 personnes venaient en même temps et vous demandaient votre numéro ? Et si 100 personnes ?
Imaginez le nombre de personnes arrivant sous forme de demandes simultanées, et il n'est pas difficile de constater que l'attribution rapide des numéros est devenue un goulot d'étranglement. L'identification automatique n'est donc pas une bonne chose pour les SGBDR. Mais heureusement, les bases de données traditionnelles sont autonomes. Elles s’ajoutent simplement un verrou pour gérer la concurrence dans la mémoire, il n’y a donc pas de gros problème. MongoDB est une base de données distribuée. Plusieurs machines doivent se coordonner les unes avec les autres. Vous en obtenez 1, j'en reçois 2 et lui en obtient 3. Ce verrou doit être coordonné via le réseau, ce qui est très inefficace.
Pensez à l'objectif de la distribution. L'un d'eux est d'améliorer la concurrence, donc les identifiants à incrémentation automatique et la concurrence élevée sont en fait contraires l'un à l'autre. Dans un environnement distribué, garantir une incrémentation correcte affectera inévitablement l'efficacité. De plus, l’ID auto-agrandissant n’a en réalité pas beaucoup d’avantages, sauf qu’il semble plus propre, il a donc été inévitablement abandonné. (N'oubliez pas que l'ObjectID peut en fait être trié, c'est-à-dire l'ordre du temps d'insertion)
https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field/#considerations
文档上自己说,pas adapté aux bases de données comportant un grand nombre de documents,自增的不适合有大数量documents的数据库