Les frameworks de mapping Objet / Relationnel (ORM)
Sont-ils dangereux pour les performances et la stabilité des applications ?

Le , par SQLpro, Rédacteur
Toutes ces histoire de framework et d'ORM sont les plus belles merdes mercatiques que l'on a fait depuis l'existence de l'informatique. Si vous voulez avoir l'assurance de ne pas finir à temps votre prijet et que ce dernier soit inexploitable lors de la montée en charge, alors allez-y, amusez vous bien avec Hibernate et les frameworks associé comme JPA...

Voici un extrait de l'article que je suis en train d'écrire sur les dérives de ce genre d'immondices...

6 – Pourquoi pas un ORM ?

Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…


A lire sur le sujet :
http://www.dulcian.com/Articles/Thic...ited_final.htm
http://thehelsinkideclaration.blogsp...vc-part-2.html

A +


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 25/03/2015 à 16:05
Oulala, beaucoup de bêtise et en plus on me prête des propos que je n'ai jamais dit !

Citation Envoyé par el muchacho Voir le message
Un ORM comme Hibernate permet d'obtenir des requêtes correctement formées dans la plupart des cas.
Pour en avoir vu de multiples fois en audit, les requêtes pissées par Hibernate sont en général le summum du crétinisme... Exemple 185 requête avec WHERE toto = 245 puis WHERE toto = 851 etc, au lieu de WHERE toto IN (245, 851...) générant des round-trip en pagaille pendant une transaction... les verrous étant maintenant pendant tout ce process on constatait 99% du temps consacré au réseau pour 1% de réel traitement de la part du SGBDR !!! Bravo hibernate
Parlons de la méthode de pagination d'Hibernate qui consiste pour chaque page à afficher de reparcourir toutes les données : Superbe !!!
Parlons aussi des jointures spaghetti qu'Hibernate génère à outrance....
Pour ma part en 15 ans d'audit, j'ai vu deux entreprises faire faillite à cause des mefaits d'Hibernate...

- l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact.
je n'ai pas dit que c'était inexact.. j'ai dit que c'était utopique et d'ailleurs une même requête dans Hibernate provoque des résultats différents dans les différentes SGBDR, ne serait-ce qu'à cause de la gestion des collations...

Le vrai avantage d'un ORM apparait, comme il a été rappelé, quand on part d'une base vierge et qu'on fait du MDA. On crée son modèle objet, et le schéma de base est créé en fonction. La modification du modèle, qui peut être importante dans les premières itérations du projet et/ou que les spécifications fonctionnelles ne sont pas fixées, est alors quasi instantanée, et on ne se retrouve pas avec des bugs de mapping en permanence.
Mais c'est justement là, que les entreprises font faillite. tant que les données sont peanuts, alors le système crache... Dès que le volume arrive les performances chutent dramatiquement et l'un (le dev) accuse l'autre (la prod) de pas avoir pris le bon serveur... (bataille du muscle contre l'intelligence comme dirait rudi...). Le problème est que c'est inégal. Un bon schéma (cela n'arrive jamais avec hibernate) avec de bon index (Hibernate n'en pose jamais) c'est un facteur 100 à 10000 au niveau des performances. Rien à voir avec le doublement des cœurs ou de la RAM !

A +
Avatar de fr1man fr1man - Membre expert https://www.developpez.com
le 25/03/2015 à 21:37
@SQLpro
Je peux aussi vous dire qu'en 11 ans d'expérience avec Hibernate, sur des petits projets comme des gros, je n'ai pas rencontré de problèmes liés à son utilisation.
Les problèmes étaient plutôt dus à une méconnaissance du framework ou plus généralement, de la base de données utilisée, et ils ont été résolus sans entraîner de dépôt de bilan...
Vous êtes tellement orientés contre les ORM que vous perdez toute objectivité....dommage...
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur https://www.developpez.com
le 27/03/2015 à 14:25
Citation Envoyé par SQLpro Voir le message
Pour en avoir vu de multiples fois en audit, les requêtes pissées par Hibernate sont en général le summum du crétinisme... Exemple 185 requête avec WHERE toto = 245 puis WHERE toto = 851 etc, au lieu de WHERE toto IN (245, 851...) générant des round-trip en pagaille pendant une transaction... les verrous étant maintenant pendant tout ce process on constatait 99% du temps consacré au réseau pour 1% de réel traitement de la part du SGBDR !!!
  1. DB2 est plus performant en requête séparée qu'avec un IN
  2. Hibernate ne fait que ce qu'on lui demande. Si tu écris une boucle infinie, il faut pas incriminer le langage ou le compilateur ...
  3. Certaines routines ETL ne consomment qu' 1% de traitement SGBDR et 99% de trafic réseau

Citation Envoyé par SQLpro Voir le message
Parlons de la méthode de pagination d'Hibernate qui consiste pour chaque page à afficher de reparcourir toutes les données : Superbe !!!
Je connais pas tous les SGBD mais au moins pour MySQL, Oracle et Postgres, il utilise les mécanismes de pagination proposé par leurs moteurs.
Après il est reconnu que la pagination par position n'est pas la plus optimale : http://blog.jooq.org/2013/10/26/fast...e-seek-method/
Citation Envoyé par SQLpro Voir le message
Parlons aussi des jointures spaghetti qu'Hibernate génère à outrance....
Les jointures sont celles demandées, là-dessus Hibernate ne fait qu'une seule supposition : par défaut il jointe par clé (ce qui est logique ...)
Citation Envoyé par SQLpro Voir le message
Pour ma part en 15 ans d'audit, j'ai vu deux entreprises faire faillite à cause des mefaits d'Hibernate...
En bien moins d'expérience, j'ai rarement vu un ingénieur qui maitrisait un minimum correctement Hibernate. C'est généralement un outil imposé qui semble magique et donc personne ne veut investir dessus, bien à tord !
Citation Envoyé par SQLpro Voir le message
je n'ai pas dit que c'était inexact.. j'ai dit que c'était utopique et d'ailleurs une même requête dans Hibernate provoque des résultats différents dans les différentes SGBDR, ne serait-ce qu'à cause de la gestion des collations...
+1
Citation Envoyé par SQLpro Voir le message
Mais c'est justement là, que les entreprises font faillite. tant que les données sont peanuts, alors le système crache... Dès que le volume arrive les performances chutent dramatiquement et l'un (le dev) accuse l'autre (la prod) de pas avoir pris le bon serveur... (bataille du muscle contre l'intelligence comme dirait rudi...).
En général le problème c'est le développeur. Celui-ci considère que tant que ca compile et éventuellement que ca s'exécute, il a fait son job. Or c'est faux. Tant que la communication inter/intra système ne correspond pas aux exigences du système (temps de réponse, conso CPU/RAM, volume réel, concurrence, etc.), le boulot n'est pas terminé et il y a un bug. Ce problème n'est pas spécifique à l'utilisation d'Hibernate.
S'il le développeur ne veut pas comprendre ou qu'il n'y a personne pour lui faire comprendre, le problème n'est pas Hibernate mais ailleurs.

Citation Envoyé par SQLpro Voir le message
Un bon schéma (cela n'arrive jamais avec hibernate)
Le but d'Hibernate (ou de tout ORM) étant au final de stocker des objets dans une base relationnelle, le schéma idéal est donc celui qui permet de contenir des objets. Il y a quelques règles mais aucune qui ne pose de difficulté à un SGBDR.
Seulement, au final (de mon expérience), Hibernate est souvent utilisé sur une base dite legacy. Ce qui donne naissance à un certain nombre de contorsion.

Citation Envoyé par SQLpro Voir le message
de bon index (Hibernate n'en pose jamais) c'est un facteur 100 à 10000 au niveau des performances.
La pose des index c'est souvent du ressort du DBA ou du développeur (dans une certaine limite). Les indexes sont des objets qui peuvent grandement améliorer les performances mais il ne faut pas oublier qu'ils peuvent être ignorés et plomber les perfs (si le coût de leur maintien est trop important).
De plus, avoir de bons indexes demandent une bonne connaissance du SGBDR retenu et de l'utilisation des données par l'application. Donc rien qu'Hibernate puisse évaluer.
Avatar de Slylord Slylord - Futur Membre du Club https://www.developpez.com
le 17/04/2015 à 11:07
Après plusieurs années au travail à utiliser l'architecture logicielle "classique" (Spring, Hibernate, JPA etc.), j'ai testé cette approche à la maison sur un projet personnel assez conséquent...

Elle a un inconvénient: il faut bien connaitre SQL (pas un souci dans mon cas). Pour le reste, c'est tout simplement "une tuerie" , le plus bluffant étant l'amélioration des performances!

Je vais tenter dans mon entreprise d'en vanter les mérites sur un projet test, et propager la bonne parole. Je sais que les résistances vont être forte, la faute aux habitudes bien ancrées et à la méconnaissance du SQL et des SGBD en général.

Merci de m'avoir fait (re)découvrir cette approche, frappée du sceau du bon sens !
Avatar de fsanti fsanti - Nouveau Candidat au Club https://www.developpez.com
le 30/01/2017 à 10:51
Bonjour à tous,
Je suis tombé par hasard sur ce commentaire tellement vrai, je n'ai jamais compris l'intérêt de ces ORMs...ça doit satisfaire une catégorie de "développeur" qui ne pensent qu'a pondre dans un temps record des "applications" pour s'attirer les grâces d'un management qui ne comprend toujours pas que le développement est un vrai métier et que sans une approche "bottom-top" le projet est voué à l'échec...ha non j'oubliais, il suffit de mettre en place des "caches misères" et des WebServer avec 16CPU et 100Giga de RAM pour résoudre les problèmes de montée en charge...
On pourrait se dire que le pire est passé, car beaucoup sont revenus sur l'utilisation de se genre de Framework et ont finalement compris qu'il fallait un vrai travail d'analyse au niveau du modèle et de l'accès aux données à travers des Stored Procedure, mais non les bases No-SQL sont maintenant là !!!! C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données et de stoker "as-it-is" ce que l'on a à l'écran et là aussi en cas de problèmes de performance on rajoute juste des Nodes et l'affaire est dans le sac !!!
Tout cela fait le bonheur des fabriquant de matériel et de hosting !!! Pourquoi normaliser un modèle de données, il faut réfléchir et ça prend du temps !!! En plus il faut écrire des SP et pondre des object POCO/DTO alors qu'une boiboite fait tout ça en coup de cuillère à pot !!! Quel temps perdu...
Bref, j'attends le moment où l'on aura tellement de data non structurées que même les plus grosses infra ne pourront plus les traiter...
Cela fait des années que je travaille sur l'optimisation de DB de plusieurs tera et comme par magie des requêtes qui prenaient plusieurs dizaines de minutes ce sont soudainement exécutées en quelques secondes !!!
Les vrai SGBDR ont encore de beaux jours et les DBA sont encore au chaud pour quelques temps !!!
Florian
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 30/01/2017 à 11:30
Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 30/01/2017 à 19:08
Citation Envoyé par fsanti Voir le message
Bonjour à tous,
Je suis tombé par hasard sur ce commentaire tellement vrai, je n'ai jamais compris l'intérêt de ces ORMs...ça doit satisfaire une catégorie de "développeur" qui ne pensent qu'a pondre dans un temps record des "applications" pour s'attirer les grâces d'un management qui ne comprend toujours pas que le développement est un vrai métier et que sans une approche "bottom-top" le projet est voué à l'échec...ha non j'oubliais, il suffit de mettre en place des "caches misères" et des WebServer avec 16CPU et 100Giga de RAM pour résoudre les problèmes de montée en charge...
+1000
je partage totalement cet avis...
pour ce qui est de pondre des applications en temps record là c'est parce que les entreprises n'ont pas le budget et le temps matériel pour faire quelque chose de correct et structuré c'est l'éternel problème.
Ensuite pour ce qui est d'utiliser des caches-misères plutôt que d'optimiser que va-t-il se passer quand une majorité de webserver vont être saturés ?
Surtout que des traitements non optimisés ça pompe pas mal niveau ressources matérielles,consommation électrique etc..

Citation Envoyé par fsanti Voir le message
Bref, j'attends le moment où l'on aura tellement de data non structurées que même les plus grosses infra ne pourront plus les traiter...
euhh c'est le but du Big Data dont on nous rabâche sans arrêts les mérites...mais si on balance des données non structurées là encore une fois on a affaire à de belles usines à gaz bref rien de nouveau en somme

curieux que Mr el_slapper ne nous rappelle pas la problèmatique de la "dette technique" ...

Citation Envoyé par fsanti Voir le message
C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données
bien d'accord et qui de nos jours fait l'ébauche d'un MCD ? Ne serait-ce que sous Access qui utilise les liaisons entre tables ?
Avatar de fr1man fr1man - Membre expert https://www.developpez.com
le 31/01/2017 à 9:10
@fsanti
Vous mélangez un peu tout.
Personne ne vous interdit de faire de l'analyse et de pondre un beau modèle de données et d'ensuite utiliser un ORM.
Personne ne vous interdit non plus d'utiliser des procédures stockées dans le cas où l'avantage serait conséquent.
Personne ne vous interdit de travailler de concert avec les DBA pour optimiser votre modèle de données et vos requêtes si besoin.
De plus, au niveau des coûts, certains préféreront ajout de la RAM ou un serveur, plutôt que de payer des journées de développements.
Aucun raisonnement n'est stupide s'il est argumenté.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 31/01/2017 à 20:05
Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.

Il y a des cas d'utilisation parfaitement valides pour tout type de solution. Devoir gonfler un serveur pour supporter la charge ça peut être un choix plus avisé que de passer des jours à optimiser un système sans garantie de résultat et en prenant le risque de casser. Oui c'est moche, mais c'est la vie . Les applications légères et élégantes à leur début mais auxquelles on a fait avaler n'importe quoi par la suite, où les compétences se sont éparpillées et perdues en route, ça devrait pas exister mais ça existe.

Un ORM est un outil, un moyen, s'il expédie n'importe quoi comme requête à la DB, c'est que la personne qui s'en servait ne savait pas ce qu'elle faisait. Marrant d'attribuer systématiquement l'outil la responsabilité d'un boulot mal fait. Mais bon on voit ça tout le temps.

Pour le noSQL, faut voir le contexte, si c'est pour faire des modélisations qui demanderaient à un SGBDR traditionnel un modèle en EAV comme certaines solutions eCommerce. Ca peut tout à fait faire du sens.
Avatar de Pill_S Pill_S - Membre expert https://www.developpez.com
le 02/02/2017 à 10:08
Citation Envoyé par _skip Voir le message
Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.
Tout à fait d'accord. Vous êtes quand même tous en train de vous plaindre que votre marteau "automatique" tape moins vite que votre marteau manuel. Personne ne se dit à un moment que le marteau automatique était peut-être plus complexe, et donc nécessitait un poil plus de réflexion avant d'être efficace?

Avec des raisonnements pareils, on se remettrait tous à l'assembleur sous prétexte que c'est plus perfo...
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur https://www.developpez.com
le 04/02/2017 à 16:43
Citation Envoyé par fsanti Voir le message
je n'ai jamais compris l'intérêt de ces ORMs...
je pense que cela a déjà été décrit précédemment. Mais des solutions à base d'ORM peuvent être bien plus efficaces aussi bien en termes de temps de développement qu'en temps d'exécution. Les frameworks d'ORM sont des solutions éprouvées qui savent générer du code optimisé pour la plupart des SGBD. Sans compter également sur une bonne gestion du cache. Et avec surement moins de bugs que ce que tu pourrais produire toi-même.

Car soyons francs de l'ORM tu en auras obligatoirement besoin. Sauf si tu considères toutes tes données sous forme d'enregistrement linéaire, même en cas de jointure N-N !

Les solutions type jOOQ ou QueryDSL offrent aujourd'hui de bon compromis si tu veux rester proche de ton modèle relationnel.

Citation Envoyé par fsanti Voir le message
ça doit satisfaire une catégorie de "développeur" qui ne pensent qu'a pondre dans un temps record des "applications" pour s'attirer les grâces d'un management qui ne comprend toujours pas que le développement est un vrai métier et que sans une approche "bottom-top" le projet est voué à l'échec...
Ce n'est pas très lean ou même très agile, pourtant certains pensent que c'est sans ces dernières que les projets sont voués à l'échec Chaque approche/méthode a ses qualités et ses défauts, et c'est l'adéquation entre le projet et les personnes qui les utilisent qui fait qu'un projet peut fonctionner ou pas.

Nombreuses sont les personnes ici qui seront t'expliquer qu'il n'y a pas de recettes miracles.

Citation Envoyé par fsanti Voir le message
C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données et de stoker "as-it-is" ce que l'on a à l'écran et là aussi en cas de problèmes de performance on rajoute juste des Nodes et l'affaire est dans le sac !!!
Assez marrant car c'est l'un des principaux de problèmes des vieilles applications pensées en MERISE

Citation Envoyé par fsanti Voir le message
Pourquoi normaliser un modèle de données, il faut réfléchir et ça prend du temps
Un modèle normalisé est quasiment l'opposé d'un modèle optimisé ! La normalisation vise à optimiser la redondance mais l'éviction de celle-ci tend à minimiser les performances. Bien comprendre ses outils (ORM ou design) c'est essentiel pour faire une bonne application. Ce n'est pas l'outil en lui-même qui est mauvais.

Citation Envoyé par fsanti Voir le message
Bref, j'attends le moment où l'on aura tellement de data non structurées que même les plus grosses infra ne pourront plus les traiter...
Cela fait des années que je travaille sur l'optimisation de DB de plusieurs tera et comme par magie des requêtes qui prenaient plusieurs dizaines de minutes ce sont soudainement exécutées en quelques secondes !!!
Les vrai SGBDR ont encore de beaux jours et les DBA sont encore au chaud pour quelques temps !!!
Tout comme tu pourrais mettre à genoux un SGBD avec bien moins de données si l'approche relationnelle n'est pas adaptée. D'ailleurs tu pourras pas manipuler des To de données sur une seule machine, sauf si tes transactions concernent toujours un même petit lot de données (données chaudes/froides).

Pas plus que ton modèle relationnelle et pré-construit ne peut stocker toutes les données aux entrées de ton SI et qu'énormément de valeurs peuvent être créées à termes en transformant ces données froides. Que ce soit par analyse manuelle ou automatique (ex : machine learning).
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique SGBD & SQL