Developpez.com

Plus de 14 000 cours et tutoriels en informatique professionnelle à consulter, à télécharger ou à visionner en vidéo.

Débat Persistance : 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 hegros hegros - Membre Expert http://www.developpez.com
le 24/08/2010 à 23:59
Citation Envoyé par Luc Orient  Voir le message
Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.

Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...

SOA(architecture orienté service). Vous ne connaissez pas rpc et les web service ?

Il n'y a rien de magique non plus dans un SBGDR ou une procédure stockée.

Mettre un composant informatique entre le client et un système de base de données est également un pattern d'architecture qui s'applique bien à SOA.
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 25/08/2010 à 8:20
Citation Envoyé par Luc Orient  Voir le message
Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.

Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...

Justement les SI sont souvent composés d'une somme d'applications hétérogénes du fait de la taille, de la technologie, de l'utilité.
Ce qui fait que fut une période ou l'informatique d'entreprise était à plus de 70% concernée par les problèmatiques d'intégration (qui n'a pas entendu le néologisme "transcodage").
Une architecture de service serait une logique de bus où le SI est un composé de fonction métier. C'est à dire que le service encapsule les questions d'intégration et de technologie.
Chaque service étant par définition interopérable avec les autres, cela facilite la création de processus verticaux par l'utilisation de points uniques.
C'est très proche du principe du design pattern facade et c'est plutôt une bonne chose.
C'est en tous cas un raisonnement plus fiable que d'avoir des cron qui font des ftp et qui lancent des korn shell qui eux même déclenchent du C++ qui appellent une sp de la base de donnée x.
Ca ne réinvente pas la roue, c'est juste un raisonnement plus industriel et moins bidouille et surtout beaucoup plus maintenable.
Avatar de el muchacho el muchacho - Membre régulier http://www.developpez.com
le 24/10/2010 à 10:55
Citation Envoyé par dingoth  Voir le message
Allez, tout le monde switche vers Apache DbUtils !

Ou vers MyBatis + un cache quelconque style memcached.

Au final, d'après quelques expériences lues ici:

- Hibernate à un coût non négligeable en perfs (ce que je corrobore avec des mesures extensives pour des opérations CRUD). MyBatis, a contrario, a un coût minimal / JDBC.

- la génération auto de requêtes peut créer des requêtes lentes qu'il faut optimiser ensuite à la main, ce qui fait que l'avantage initial en terme de dev (on a vite un prototype qui fonctionne) est perdu par la suite en optimisation. Par contre, l'optimisation de requêtes nécessite des outils et/ou des connaissances que le développeur Java moyen n'ont pas. Un ORM comme Hibernate permet d'obtenir des requêtes correctement formées dans la plupart des cas.

- il n'y a pas besoin de connaître SQL. Cet argument est un voeu pieux. Il n'est simplement pas possible de développer un soft basé sur un SGBD SQL sans connaitre un minimum de SQL, ne serait-ce que pour débugger. On a tjrs besoin de faire des requêtes à la main, requêtes qui sont d'ailleurs à peu près les mêmes que celles du programme.

- l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact. Je n'ai pas suffisamment d'expérience pour avoir mon avis la-dessus, mais ce qui me parait certains, c'est que les entreprises qui basent leurs gros devs sur une solution Oracle ne risquent pas de changer de SGBD de sitôt. Pour une banque ou une administration, par exemple, cet argument me parait donc relativement mineur. Mais pour d'autres applications, il est plus pertinent.

Après, pour ce qui est du développement, vu qu'on utilise majoritairement des langages objet en entreprise (Java, C#), vouloir garder un modèle objet est loin d'être déconnant, bien que le mapping soit fastidieux à la main, mais relativement automatisable (ce que font Hibernate, MyBatis et d'autres).
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 quand il s'agit de mapper un schéma déjà existant, un outil comme Hibernate est probablement une perte de temps plus qu'autre chose (Mybatis est plus adapté).

Il se trouve que les langages fonctionnels sont probablement plus adaptés à la manipulation du SQL que le Java. Peut-être qu'avec l'adoption de paradigmes fonctionnels, les ORM disparaitront.
Avatar de charlycoste charlycoste - Membre à l'essai http://www.developpez.com
le 23/11/2014 à 20:04
Citation Envoyé par Patriarch24  Voir le message
... s'ils étaient si catastrophiques que cela [...], ils ne seraient plus beaucoup utilisés et soutenus depuis longtemps

Le syndrome du "si ça passe à la télé, c'est forcément un bon produit"
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur http://www.developpez.com
le 24/11/2014 à 12:40
le syndrome de la confiance des experts ...

EDIT : ou celui de déterrage de topic.
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 25/03/2015 à 14:31
Toujours les mêmes désespérantes idioties...

Citation Envoyé par cinemania  Voir le message
...je te déconseille fortement de laisser à ton SGBDR le loisir de gérer lui même l'accès concurrentiel, à moins que tu ne souhaite avoir du côté de tes n instances clientes, des bugs pour le moins incongrus et pas toujours très facile à repérer, et ce même avec des transactions en niveau d'isolation maximum (sérialisation)

Un SGBDR ne choisit pas de lui même le niveau d'isolation. Il est par défaut à un niveau que le développeur doit monter en fonction de ses besoins et des traitements à faire... Problème : rare sont les développeurs qui savent réellement ce qu'est l’isolation et peu savent la modifier. Pire, un certain nombre d'ersatz de SGBDR comme MySQmerde ne permettent pas grand chose en cette matière, voir rien ! (pas de transactions dans MyISAM).
Quand à piloter l’isolation au niveau du code c'est mathématiquement impossible. je m'amuse à le démontrer quotidiennement la chose dans toutes les formations que je donne !

A +
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 25/03/2015 à 14:35
Ca c'est aussi parfaitement stupide :
Citation Envoyé par Michel Rotta  Voir le message
En fait, l'important est peut-être de savoir, avant d'écrire l'application si ce qui est important, c'est l'application ou la base de donnée.

Expliquez moi un peu ce que vous pouvez faire avec votre programme mais sans les données ?

Maintenant pouvez vous faire quelques chose avec les données sans votre programme ?

la question est donc stupide. L'important dans le SI c'est TOUJOURS les données !

malheureusement peu de gens en ont conscience hélas...

A +
Avatar de SQLpro SQLpro - Rédacteur http://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 http://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 http://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 http://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 !
Offres d'emploi IT
Analyste SI-métier (H/F)
Société Générale - Ile de France - Val-de-Marne
Technical leader / moe perle (H/F)
Société Générale - Ile de France - Val de Marne
Ingénieur sénior en développement mobile / projet innovation H/F
Safran - Ile de France - Hauts de Seine

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Microsoft DotNET : Hinault Romaric -