Sous réserve de cette question, demande tout: quelle efficacité est la méthode EXECUTEBATCH? Existe-t-il un repère de performance, qui dit.
ou est-ce juste une convention?
EDIT: Voici ce que je travaille avec: un DB2 V 8.1 hébergé sur z / OS, une application Web qui insérerait 80 000 enregistrements à une entrée dans sa pire exécution de scénario.
5 Réponses :
Je ne suis pas sûr de ce que vous demandez, mais d'insérer plusieurs milliers de lignes, une déclaration par lots est extrêmement plus rapide. Je ne peux pas vous donner des chiffres, cependant.
@skaffman qui était ma question - à quel point est-ce extrêmement rapide? Pouvez-vous me donner une approximation?
J'avais estimé quelque part entre 10 et 20 fois, cela dépendrait dans une large mesure de la base de données elle-même. Une instruction non par lots implique beaucoup plus de trafic réseau, donc un serveur Supprimer en profiterait davantage de lots qu'un local, par exemple.
Plus de 10-20X dans mon expérience (pour mon étui d'utilisation particulier).
Dans mon expérience, il est nettement plus rapide - même si vous insérez / mettez à jour quelques enregistrements à la fois. Si vous faites plus d'une mise à jour, je vous recommanderais presque toujours de les lotter si cela a du sens.
Cela dit, vous devez effectuer des tests réels pour déterminer l'amélioration des performances de votre situation particulière.
Vous ne savez pas quelle base de données vous utilisez. Quand j'ai dirigé un test sur cette utilisation de DB2, c'est ce que j'ai vu:
écrire dans la base de données:
1 Insérez-le a pris 2500 microsecondes.
10 insère qu'il a fallu 6000 microsecondes. (600 microsecondes par écriture)
10000 inserts Il a fallu environ 1 million de microsecondes. (100 microsecondes par écriture)
performance maximum là-bas. Tout cela signifie qu'il y a une énorme surcharge dans l'envoi de messages et l'utilisation d'une méthode de lot minimise cela. Bien entendu, l'envoi d'inserts / mises à jour dans d'énormes lots exécute le risque de les perdre si l'application se bloque.
Aussi de note: les numéros exacts varient en fonction de votre DB et des paramètres. Donc, vous devrez trouver votre propre "tache sucré". " Mais cela vous donne une idée.
@Windfinder Avez-vous utilisé ExecuteBatch pour tout ce qui précède? Et, vous avez dit que «d'énormes lots risquent de perdre des accidents de l'application» - si j'utilise la gestion des transactions - je devrais être bon dans ce scénario?
Oui, j'ai utilisé ExecuteBatch. La gestion des transactions n'éliminera pas complètement ce risque, mais cela pourrait le réduire.
Dans la manière la plus simple des manières, si je pouvais définir une autocommande sur false et ne pas engager que lorsque l'exécutébatch retourne, comment suis-je à risque?
@WindFinder - Comment avez-vous trouvé et mesurez-vous ces moments?
Pouvons-nous obtenir la même amélioration de la performance si nous utilisons une déclaration appelable mais avec la procédure n'ayant que l'instruction insertion?
Spécification JDBC Le chapitre 14 indique que la soumission de plusieurs déclarations SQL, au lieu de individuellement, peut améliorer considérablement les performances
dans les instructions de mise à jour de Batchexecute () prennent plus de temps, puis insérez des instructions avec les instructions d'insertion et de mise à jour 5001 La ration de performance est de 15:84
Et où est la réponse?
Plutôt que d'avoir tout le monde vous donne des chiffres laineux, pourquoi ne pas l'essayer pour vous-même et le mesurer? Seulement vous pouvez savoir à quel point vous bénéficierez de votre configuration.
@skaffman Je ne veux pas faire ce qui est communément appelé optimisation prématurée. Je voudrais cependant comprendre à quel point c'est nettement plus rapide.
Je comprends cela, mais vous ne pouvez pas faire un choix éclairé sans un peu de benchmarking.
Pensez à utiliser RewriteBatchedStatifs = True Stackoverflow.com/Questions / 26307760 / ...