IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

JPA Java Discussion :

Quel JPA Provider ?


Sujet :

JPA Java

  1. #1
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut Quel JPA Provider ?
    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

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2009
    Messages : 92
    Par défaut
    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 ?

  3. #3
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut
    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 ).

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2009
    Messages : 92
    Par défaut
    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.

  5. #5
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par rastalien73 Voir le message
    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…)

  6. #6
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut
    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...)

  7. #7
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par rastalien73 Voir le message
    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

  8. #8
    Nouveau membre du Club
    Inscrit en
    Janvier 2009
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : Janvier 2009
    Messages : 6
    Par défaut
    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 ?

  9. #9
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2009
    Messages : 92
    Par défaut
    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)

  10. #10
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par rastalien73 Voir le message
    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…

    Citation Envoyé par rastalien73 Voir le message
    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…

    Citation Envoyé par rastalien73 Voir le message
    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…

    Citation Envoyé par rastalien73 Voir le message
    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

Discussions similaires

  1. Réponses: 5
    Dernier message: 24/05/2011, 10h27
  2. Réponses: 7
    Dernier message: 22/06/2010, 17h26
  3. [E03] ADO vers DB AS400 : Quel provider utiliser ?
    Par Godzestla dans le forum Macros et VBA Excel
    Réponses: 1
    Dernier message: 20/01/2009, 09h33
  4. Réponses: 2
    Dernier message: 02/12/2008, 11h56
  5. quels sont les avantages de jpa
    Par une_tite_question dans le forum JPA
    Réponses: 6
    Dernier message: 09/05/2008, 11h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo