Discussion :

[rastalien73]

Bonjour,
Dans le cadre d'un projet de RCP Eclipse j'ai besoin d'utiliser la persistence d'objet.
Il s'agit d'avoir une API orienté objet permettant de manipuler des objets persistés sans se soucier du code SQL.

Mon application utilise la base de donnée embarquée SQLite.

Une première approche à été de comparer les performances entre une API faites maison qui génère du code JDBC et l'utilisation du framework Hibernate.

Premier problème Hibernate ne supporte pas "nativement" SQLite. Ensuite après avoir fourni un dialect SQLite à Hibernate il s'avère que les performances obtenu sont insuffisantes pour mon application (requêtes trop lentes).

Aujourd'hui l'API "maison" existante à atteint ses limites et je souhaiterais savoir si parmi vous quelqu'un aurait testé un autre JPA provider (EclipseLink ? éventuellement avec une autre base de donnée embarqué) et qui aurait des performances se rapprochant de celles de SQLite ?

Cordialement

[ohanny]

Le passage à un ORM est un choix qui n'est pas sans conséquence. Compte-tenu de l'importance de cette décision, ne faudrait-il pas d'abord se poser la question de la base de données => SQLite vraiment indispensable ? si il faut absolument garder SQLite, n'y a t'il pas un risque d'évolution puisque peu d'implémentations JPA supportent SQLite ?

[rastalien73]

Compte-tenu de l'importance de cette décision, ne faudrait-il pas d'abord se poser la question de la base de données => SQLite vraiment indispensable ?

SQLite n'est pas indispensable, c'est la solution existante aujourd'hui. Ce qui est indispensable c'est l'utilisation d'un SGDB fichier (embedded) performant (D'après mes recherches je n'en ai pas trouver de plus performant que SQLite... Mais toute solution aussi performante est bien sur envisageable ).

[ohanny]

Si la performance est un élément essentiel, il faut noter que de toute façon, l'utilisation d'un ORM générera un overhead. Je pense qu'il faut surtout choisir le couple bdd-orm qui conviendra le mieux, plutôt que choisir chaque élément séparément => tu peux perdre sur une bdd, mais te rattraper sur l'orm. Maintenant, je ne saurai pas te conseiller sur les perfs des uns et des autres, mais si garder sqlite impose une implémentation jpa qui n'est pas très performante, les temps de réponse globaux s'en resentiront.

[JeitEmgie]

SQLite n'est pas indispensable, c'est la solution existante aujourd'hui. Ce qui est indispensable c'est l'utilisation d'un SGDB fichier (embedded) performant (D'après mes recherches je n'en ai pas trouver de plus performant que SQLite... Mais toute solution aussi performante est bien sur envisageable ).

définissez précisément "embedded" dans le cadre de votre projet …

(j'ai déjà vu des applications "desktop" qui utilisait PostgreSQL de manière "embedded"… càd que le serveur PosgreSQL n'existait que tant que l'utilisateur final ne quittait pas l'application standalone… et l'ensemble des dossiers et fichiers de PostgreSQL nécessaires au fonctionnement était packagé dans l'application elle-même… l'utilisateur final ne voyant qu'un fichier fichier : le package de l'application…)

[rastalien73]

définissez précisément "embedded" dans le cadre de votre projet …

Cela signifie qu'idéalement, ma base est sauvegardé dans un fichier (a la SQLite != Derby par example) et qu'aucun serveur est nécessaire en demon puisqu'il s'agit d'une application standalone local.

Si j'ai compris ce que vous proposiez, il s'agit de démarrer un serveur, Postgres en l'occurence, le temps que l'application est éxécuté ?
Dans ce cas, quid des performances ?

- Au niveau de la charge à l'éxécution
- Performance entre une BD embarquée fichier comme SQLite et une BD serveur (MySQL,Postgres...)

[JeitEmgie]

Cela signifie qu'idéalement, ma base est sauvegardé dans un fichier (a la SQLite != Derby par example) et qu'aucun serveur est nécessaire en demon puisqu'il s'agit d'une application standalone local.

Si j'ai compris ce que vous proposiez, il s'agit de démarrer un serveur, Postgres en l'occurence, le temps que l'application est éxécuté ?
Dans ce cas, quid des performances ?

- Au niveau de la charge à l'éxécution
- Performance entre une BD embarquée fichier comme SQLite et une BD serveur (MySQL,Postgres...)

"proposer" est un bien grand mot, j'attire l'attention sur le fait que cela reste une possibilité…

"dans un fichier" : l'air de rien, ça limite très fort le choix…
la plupart des SGBD vont séparer tables, indexes, meta infos… dans plusieurs fichiers…
"dans un fichier ou un dossier" c'est déjà plus souple…

de quelle "performance" parlez-vous ?
du temps de lancement de l'application ?
si c'est fait intelligement : aucune différence… le serveur démarrera en parallèle du chargement de l'UI…

de l'exécution des requêtes ?
plus elles sont complexes (join and C°) plus PosgreSQL aura l'avantage
…

[rastalien73]

de quelle "performance" parlez-vous ?
du temps de lancement de l'application ?
si c'est fait intelligement : aucune différence… le serveur démarrera en parallèle du chargement de l'UI…
de l'exécution des requêtes ?
plus elles sont complexes (join and C°) plus PosgreSQL aura l'avantage

Quand je parle de performance je pense typiquement à la vitesse pour insérer 200 000 objets à la suite. C'est mon critère de performance le plus fort.

Je pense que le fait d'utiliser un serveur rajoute une couche de communication qui peut emboutir ces performances. De plus cela demanderai une installation et une configuration local d'un serveur de BD pour chaque utilisateur. Cela ne me semble pas raisonnable.

Le mécanisme de dialecte utilisé par Hibernate existe-t-il chez tous les JPA provider ?

[ohanny]

Toplink permet de définir un dialecte comme hibernate, et OpenJPA utilise une propriété openjpa.jdbc.DBDictionary pour sélectionner une base de données (mais je crois que le dialecte est reconnu automatiquement via le nom du driver et cette propriété ne semble pas obligatoire)

[JeitEmgie]

Quand je parle de performance je pense typiquement à la vitesse pour insérer 200 000 objets à la suite. C'est mon critère de performance le plus fort.

les ORM et JPA ne sont orientés "batch"…
leur surcoût pour ce genre d'opérations est élevé…
plus que le surcoût d'une solution en client-serveur…

Je pense que le fait d'utiliser un serveur rajoute une couche de communication qui peut emboutir ces performances.

à engine identique : oui, c'est un peu plus lent…
mais on parle de comparer 2 engines très différents…

De plus cela demanderai une installation et une configuration local d'un serveur de BD pour chaque utilisateur. Cela ne me semble pas raisonnable.

d'autres avant vous l'ont fait, et c'est totalement transparent pour l'utilisateur : il ne sait même pas que son application utilise PostgreSQL…

Le mécanisme de dialecte utilisé par Hibernate existe-t-il chez tous les JPA provider ?

n'attendez pas d'un produit comme TopLink développé par ORACLE qu'il supporte bien tous ses concurrents…
et les autres ? difficile d'imaginer qu'ils ne supportent qu'un RDBMS… ou que le SQL le plus commun…

notez que beaucoup d'exemples JPA sont basés sur HSQLDB qui est bien supporté par Hibernate et qui a un mode standalone…

http://hsqldb.org/web/hsqlDocsFrame.html