Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
n EntityManager.persist <-> 1 insert
Bonjour,
j'ai n entités JPA à persister et pour des raisons de performance je voudrais que cela se traduite par un seul insert en SQL. Est ce que c'est possible en utilisant la méthode persist de l'EntityManager ou dois-je faire une requête à la main (ou autre idée..)?
Je ne sais pas si c'est important mais j'utilise hibernate et hsqldd.
Merci par avance.
je n'ai jamais entendu parler d'une telle optimisation…Envoyé par gontard
qui au demeurant ne doit pas être triviale à implémenter à partir du niveau JPA…
(si vous avez besoin de performance pour des gros INSERT : regardez Spring Batch…)
Qu'est ce que tu veux dire par un seul insert pour n objets? Tu veux dire une seule transaction??
ce que je comprends de la question est :
pour une série de persist() sur des objets d'une même classe, est-ce qu'il est possible d'avoir un seul
insert into TABLE_NAME(FIELDS) values (TUPLE_1), (TUPLE_2), … ;
au lieu de :
insert into TABLE_NAME(FIELDS) values (TUPLE_1);
insert into TABLE_NAME(FIELDS) values (TUPLE_2);
… ;
Ok merci pour la précision. Et bien je ne sais pas, mais si quelqu'un a la réponse ca m'intéresse!
Exactement.
Grace à celà je passerai d'environ 150 inserts à seulement 3 (3 tables différentes). Ce qui aurait un impact non négligable sur les performances, du moins je l'espère.
En effet, j'ai peu d'espoir que cette optimisation existe. Si ce n'est pas le cas, je vais devoir créer une requête "à la main".
Et vu que les requêtes "à la main" se multiplient dans notre application, l'intêret de JPA devient de plus en plus discutable... c'est pourquoi avant d'envisager une refonte de note couche de persistance, je préfère creuser encore un peu dans JPA.
C'est pourquoi, je n'envisage pas pour l'heure d'utiliser d'autres lib comme Spring Batch(qui ne doit pas être utilisable avec JPA )
je ne m'attendrais pas à des miracles…
l'essentiel du travail est quand même l'écriture des N tuples et non le parsing des commandes…
et 1 INSERT de N tuples au lieu de N INSERT de 1 tuple, c'est toujours N écritures dans la DB…
sans parler qu'en amont pour qu'un telle "optimisation" puisse se faire, l'implémentation va devoir tester un graphe de dépendances d'objets…
si l'exercice peut être trivial pour un schéma simple, plus on aura de relations via des foreign keys ou via de l'inhéritance, plus l'analyse du graphe permettant de décider si oui ou non cette optimisation peut être faite va être lourde…
(sans parler du fait qu'il faudrait démontrer mathématiquement que cette analyse puisse répondre de manière déterministe dans un temps fini…)
la question étant principalement pour l'optimiseur de savoir si 1 persist qui implique 2 insert dans 2 tables A et B, est-ce que lors du deuxième persist on peut réarranger
INSERT INTO A TUPLE_A1
INSERT INTO B TUPLE_B1
INSERT INTO A TUPLE_A2
INSERT INTO B TUPLE_B2
en
INSERT INTO A TUPLE_A1, TUPLE_A2
INSERT INTO B TUPLE_B1, TUPLE_B2
sans risque de violation de contraintes : donc qu'aucun TUPLE_Ax n'ait de relations vers un quelconque TUPLE_By… (entres autres…)
Sans parler encore du fait que le calcul d'optimisation possible se fait probablement sur une machine A (celle qui héberge la WebApp) pour gagner du temps sur une machine B probablement distincte (celle qui héberge la DB)…
et dans le cas contraire, est-ce qu'une application basée sur une DB qui tourne tout sur un seul serveur faut la peine de se poser ce genre de questions ?
En fait il s'agit d'une appli standalone qui pourrait être amener( a plus long terme) à migrer sur une architecture du même type que celle que tu viens de décrire. Mais en attendant il faut que je gagne en perf...
Si l'optimisation n'existe pas en JPA, je vais créer 3 requêtes "à la main" et je ferai l'opimisation moi même. J'ai la main sur mes objets la construction de ces requêtes sera rapide.
Par contre, ce qui m'inquiète, c'est que tu dis que dans tous les cas celà représente autant d'écriture en base et que du coup le gain en perf ne serait pas significatif.
Est ce qu'il s'agit seulement d'une intuition ?
une déduction…
la quantité de données à écrire dans la DB est la même…
quelque soit le chemin que l'on prend…
donc on ne peut qu'économiser au niveau traitement pas au niveau des écritures…
maintenant d'un SGBDR à l'autre, l'INSERT de N-tuples peut être optimisé de manière différente, et il peut avoir un gain de performance dû à la façon dont les IO bas niveaux sont gérés dans un cas ou l'autre…
dû à la manière dont sa propre cache interne est gérée… peut-être qu'il va gagner sur le nombre de round-trip vers sa cache dans le cas de l'INSERT de N-tuples…
rien n'interdit d'avoir une bonne surprise…
... j'espère en effet.
Je vais bientôt implémenter cette solution, lorsque ca sera fait je vous ferai un retour...
Merci pour votre aide.
Finalement pour diverses raisons je n'ai pas implémenté cette solution.
Répondre avec citation
Partager