web-dev-qa-db-fra.com

MongoDB: Update / Upsert vs Insert

Récemment, j'ai remarqué une énorme différence de performances entre plusieurs insertions (via opérations en bloc ) et une insertion (plusieurs documents). Je voudrais savoir si j'ai raison sur ce point:

  • Upsert/Updates sera comme une find() et update() donc il fait 2 choses en lecture et en écriture
  • L'insertion va juste écrire donc c'est beaucoup plus rapide

Ainsi, la différence de performance?

Si c'est le cas, je me demande si j'ai besoin de beaucoup d'écritures régulièrement, au lieu de mettre à jour un document, j'écris un nouveau document avec un champ createdOn. Ensuite, pour interroger, je vais simplement rechercher des documents, triés par createdOn DESC. Je me demande si c'est une bonne méthode? Ou existe-t-il une meilleure façon?

  • Je me demande si j'ai un index sur la collection, cela pourrait-il accélérer la mise à jour? Mais cet index ne ralentira-t-il pas alors la partie écriture?
  • Avec la 2ème voie, où je ne fais que des encarts, ça va ralentir alors j'ai trop de documents? Est-ce pratique (pour accélérer les écritures)?
  • J'ai également essayé d'augmenter la taille du pool de connexions. Je ne sais pas quel est l'optimum, mais j'ai essayé 20 et je vois que je peux traiter environ 20 requêtes par seconde via mongostat. Je m'attendais à ce qu'il soit beaucoup plus élevé.
mongodbmongodb-queryupsert
15
Jiew Meng

Si vous insérez un document, Mongodb doit vérifier si le document avec le même objectId existe ou non. S'il existe, le document ne peut pas être inséré.

Le même cas s'applique à Update. Il doit vérifier si le document existe ou non. sinon la mise à jour ne peut pas être effectuée. Le cas où votre requête de mise à jour ralentira si vous ne trouvez pas de document basé sur votre champ ObjectId/Indexed.

Sinon, les performances d'insertion/mise à jour du document doivent être identiques.

Par exemple.....

Donc, insérer peut être comme ceci // (rapide)

  1. (Vérifier le document -> Introuvable -> Insérer un nouveau document)
  2. (Vérifier le document -> Trouvé -> Ne peut pas être inséré)

Et mise à jour avec upsert (ObjectId disponible) // (rapide)

  1. (Vérifier le document -> Introuvable -> Insérer un nouveau document)
  2. (Vérifier le document -> Trouvé -> Mettre à jour le document)

Ou mettre à jour avec upsert (sans ObjectId) // C'est lent

  1. (Trouver ObjectId (lent) -> Introuvable -> Insérer un nouveau document)
  2. (Trouver ObjectId (lent) -> Trouvé -> Mettre à jour les documents)
20
Code OverFlow

Je n'ai pas trouvé d'explication "officielle" sur le fonctionnement d'un upsert dans MongoDB, mais oui, il est sûr de supposer que, puisque l'opération vise à mettre à jour les documents existants et à n'ajouter un document que lorsque le document avec les critères donnés sont introuvables.

Si vous ajoutez un index, le upsert peut devenir plus rapide: après tout, l'index est utilisé pour "trouver" le document. La mise en garde se trouve dans le (s) champ (s) sur lesquels l'index fonctionne et les champs que vous mettez à jour. Si la partie mise à jour fait partie de l'index, vous aurez un impact sur les performances lors de la mise à jour du document. Si la partie mise à jour ne fait pas partie de l'index, vous n'encourrez pas de pénalité pour avoir écrit dans le document existant. Si le document est ajouté cependant, vous aurez un impact mineur sur les performances, car la collection d'index est mise à jour. Mais encore: l'ajout d'un document restera plus rapide.

Par conséquent, si dans votre scénario vous savez que vous ne souhaitez pas mettre à jour les documents, les insertions sont généralement plus rapides. Si vous voulez vous assurer de ne pas ajouter deux fois le même document, vous pouvez également opter pour l'ajout d'un index unique. Ensuite, un insert échouera simplement.

Dans l'ensemble, cela dépend du scénario spécifique, mais sur la base des informations que je peux extraire de votre question, je pense que la meilleure option est simplement d'insérer les documents. Puisque vous semblez vous assurer que le champ "createdon" rend les documents uniques dans votre scénario, vous n'avez qu'à vous soucier des index utilisés dans vos scénarios de lecture.

Quelques informations supplémentaires peuvent être trouvées sur le site MongoDB :

Pour plus d'informations sur la conception de vos index (en lecture), une très bonne explication pour savoir si vos index ajoutent quelque chose aux plans de requête peut être trouvée ici :

J'espère que ça aide.

2
Michaël van der Haven