Je sais que nous pouvons faire des documents de mise à jour en vrac dans mongodb avec dans un appel de DB, mais c'est homogène, c'est-à-dire que tous ces documents concernés suivent un type de critère. Mais ce que je voudrais faire, c'est quelque chose comme , pour envoyer plusieurs demandes de mise à jour qui mettront à jour des documents ou une classe de documents absolument différents dans un appel unique de DB. Ce que je veux faire dans mon application consiste à insérer / à mettre à jour un tas d'objets avec la clé primaire composée, si la clé est déjà existante, mettez-la à la mise à jour; Insérez-le autrement. Puis-je faire tout cela dans une combinaison de mongodub?
3 Réponses :
C'est deux questions séparées. Au premier; Il n'y a pas de mécanisme natif de MongoDB sur la masse d'envoi de critères / met à jour des paires bien que techniquement cela dans une boucle vous-même est liée aussi efficace que tout support en vrac natif.
Vérification de l'existence d'un document basé sur un document intégré ( Ce que vous faites référence à la clé composée, mais dans l'intérêt de la terminologie correcte pour éviter de confusion, il est préférable d'utiliser le nom de Mongo dans ce cas) et d'insérer / mettre à jour en fonction de cette vérification d'existence peut être effectuée avec UPSert: P>
Document A: p>
{
_id: ObjectId(...),
key: {
name: "Will",
age: 20
}
}
db.users.update({name:"Will", age:20}, {$set:{age: 21}}), true, false)
espère que cela aide p> p>
Merci pour votre réponse rapide. Au premier point, il ne sera-t-il pas beaucoup plus efficace d'envoyer plusieurs critères / mises à jour dans un appel de DB, en particulier lorsqu'il existe des tonnes de documents à mettre à jour et à résident du pilote / serveur MongoDB dans différentes machines? La deuxième question que vous avez mentionnée n'est pas une nouvelle question. Peut-être que je ne l'ai pas bien présent. Ce que je veux dire la clé composée n'est rien à voir avec _ID, il ne s'agit que de deux champs (disons, type et nom) du document et je les utilise unis pour déterminer si l'objet existe déjà en DB, et l'op à utiliser. C'est juste pour le scénario représentant le but.
Salut. Oui, ce serait plus efficace mais une telle opération en vrac n'est actuellement prise en charge que pour les inserts. L'une des raisons pourraient être difficiles à présenter des erreurs possibles au client par tentative de mise à jour. Signalez-le comme un problème / une question sur jira.mongodb.com si vous estimez que cela devrait être ajouté. J'ai mal compris la deuxième partie de votre question en raison de la terminologie. Ce que vous avez besoin de sons comme un upser de base. Je vais éditer ma réponse en conséquence, alors vérifiez si cela vous aide.
Oui, getlasterror peut-être un problème si la mise à jour en vrac avec plusieurs critères est un support, et les choses pourraient être plus compliquées si la transaction est adoptée. J'ai donc changé ma mise en œuvre avec la boucle de mise à jour et UPSERT correspond exactement à cela. Résolu!
Il n'y a pas de réel avantage de faire des mises à jour comme vous le suggérez.
La raison pour laquelle il existe une API d'insertion en vrac et qu'il est plus rapide, c'est que Mongo peut écrire tous les nouveaux documents de manière séquentielle à la mémoire et mettre à jour les index et autres comptables en une seule opération.
Une chose similaire se passe avec des mises à jour qui affectent plus d'un document: la mise à jour ne traversera que l'index uniquement une fois et mettra à jour les objets tels qu'ils sont trouvés.
Envoi de critères multiples avec plusieurs critères ne peut bénéficier d'aucune de ces optimisations. Chaque critère désigne une requête séparée, comme si vous avez émis chaque mise à jour séparément. Le seul avantage possible envoierait un peu moins d'octets sur la connexion. La base de données devrait toujours faire chaque requête séparément et mettre à jour chaque document séparément.
Tout ce qui se produirait serait que Mongo filerait les mises à jour en interne et les exécuterait séquentiellement (car une seule mise à jour peut se produire à la fois), c'est exactement la même chose que si toutes les mises à jour ont été envoyées séparément.
Il est peu probable que les frais généraux d'envoi des requêtes soient significatifs soient importants, le verrouillage mondial de Mongo sera le facteur de limitation de toute façon.
Je pense que vous avez oublié: L'insert en vrac réduit le nombre de tours de retour de serveur. La mise à jour en vrac ferait la même chose.
Cela peut être un facteur dans certains cas, mais pour le cas général, les aller-retour ajoutées ne sont pas un problème en raison de la serrure de l'écriture mondiale. Pour de nombreuses autres bases de données, vous êtes tout à fait correct et, à l'avenir, cela peut également être vrai pour Mongo.
Nous constatons des avantages de la clause $ de la clause. Notre cas d'utilisation consistait à mettre à jour le «statut» dans un document pour obtenir des enregistrements de nombres de nombres volumineux. Dans notre première coupe, nous faisions une boucle pour la boucle et nous faisions des mises à jour une par 1. Mais ensuite, nous avons changé d'utiliser $ en clause et qui apportait une énorme amélioration.