Choix persistance avec cache cluster safe

Bonjour,

je créé une nouvelle application. Mon besoin est de pouvoir croître assez facilement en dimensions à termes. Du coup, j'ai envisagé l'utilisation d'une persistance (hibernate) non pas pour une "indépendance vis à vis du SGBDR" car je suis assez sur de mon choix (postgres).
Mon but premier est de bénéficier facilement de fonctionnalités de cache en mode "cluster safe" car j'aurais certainement un loadbalancing/failover sur les serveurs applicatifs.
Bon but second sera de pouvoir aussi monter en charge au niveau SGBDR: soit en réplicant, soit en distribuant (ex: client 1 à 1000 sur SGBDR1 et 1001 à 2000 sur SGBDR2 sachant que les données entre les deux sont cloisonnées à 99% mis à part quelques tables de paramétrage communes).

Alors voici quelques questions pour vérifier que je n'ai pas des raccourcis de raisonnement aberrant, en sachant que je pars d'un modèle relationnel préexistant (le modèle objet étant produit à partir du modèle relationnel):
1) Il est plus simple d'utiliser un JPA ou hibernate que de développer sa persistance si on veut avoir une gestion "transparente" et performante. L'intérêt d'un JPA/Hibernate n'est pas uniquement l'ORM et le support de plusieurs SGBDR ?

2) Hibernate serait plutot vu comme une implémentation de JPA qui offre des services supplémentaires et qui reste performante et bien mature et supporté ?

3) La réplication des BD est transparente pour une persistance en toute logique ? La distribution est-elle aussi simple ? A une epoque il y avait des middleware types CJDBC, etc.

Compte tenu de mon besoin, que me conseillez vous ?
- utiliser du JDBC ou un autre framework de persitance ou une autre implementation que JPA/Hibernate plus adaptée pour gérer de la distribution de mes plages de clients ?
- utiliser JPA hibernate ? Si oui avec quelles implementation de persistance ? Quel outil de cache et sous quel mode (terracota ? ehcache ? jboss cache ? repliqué ? distribué ? version ? )
- comment gérer ma "distribution" ou le scaling SGBDR : distribution ? replication ? load balancing ? fail over ? framework ou middle ware ?

merci pour vos conseils

Bonjour,
Youhhhhhh tu poses là plusieurs problématiques très intéressantes dans un seul post, tu mélanges un peu les questions et du coup on a du mal à savoir par quel bout adapter des réponses, mais je vais éssayer de répondre au mieux et je laisserai d'autres membres apporter leur expertise.

Citation:

---

Envoyé par fja34

Bonjour,

je créé une nouvelle application. Mon besoin est de pouvoir croître assez facilement en dimensions à termes. Du coup, j'ai envisagé l'utilisation d'une persistance (hibernate) non pas pour une "indépendance vis à vis du SGBDR" car je suis assez sur de mon choix (postgres).
Mon but premier est de bénéficier facilement de fonctionnalités de cache en mode "cluster safe" car j'aurais certainement un loadbalancing/failover sur les serveurs applicatifs.
Bon but second sera de pouvoir aussi monter en charge au niveau SGBDR: soit en réplicant, soit en distribuant (ex: client 1 à 1000 sur SGBDR1 et 1001 à 2000 sur SGBDR2 sachant que les données entre les deux sont cloisonnées à 99% mis à part quelques tables de paramétrage communes).

---

Pour moi il faut décorréler le cache persistent du loadBalancing sur les serveurs applicatifs, tu peux très bien faire du loadBalancing applicatif sans activer un cache (et inversement), c'est 2 problématiques différentes, mais je peux te rejoindre sur le fait de savoir quel est l'impact d'un loadBalancing applicatif sur un mécanisme de cache repliqué, et je peux te rassurer qu'avec la réplication de session (s'il est mis en place) c'est bien géré, donc transparent pour le développeur.

Citation:

---

Envoyé par fja34

Alors voici quelques questions pour vérifier que je n'ai pas des raccourcis de raisonnement aberrant, en sachant que je pars d'un modèle relationnel préexistant (le modèle objet étant produit à partir du modèle relationnel):
1) Il est plus simple d'utiliser un JPA ou hibernate que de développer sa persistance si on veut avoir une gestion "transparente" et performante. L'intérêt d'un JPA/Hibernate n'est pas uniquement l'ORM et le support de plusieurs SGBDR ?

2) Hibernate serait plutot vu comme une implémentation de JPA qui offre des services supplémentaires et qui reste performante et bien mature et supporté ?

---

En effet l'intérêt de JPA/Hibernate ne se limite pas seulement à l'ORM, c'est une norme,un ensemble de best pratice de code de persistence, c'est d'ailleurs une implémentation du pattern DAO.JPA est implémenté par Hibernate,TopLink,EcluipeLink, etc..., et une autre vertue d'Hibernate c'est le fait de rester indépendant de la BD, mais l'expérience a montré qu'une fois qu'un SGBD choisi on n'en change pas trop souvent :mouarf:.

Citation:

---

Envoyé par fja34

3) La réplication des BD est transparente pour une persistance en toute logique ? La distribution est-elle aussi simple ? A une epoque il y avait des middleware types CJDBC, etc.

---

La distribution des BD est tout d'abord liée au type de SGBD que tu vas utiliser, il y'en a qui ne l'implémentent pas.Par contre je n'ai pas de recul sur le comportement d'Hibernate connectée à une BD tournant sur le mécanisme de replication, mais j'ai envie de dire que ça doit rester transparent pour lui, par principe d'indépendance avec le MPD, c'est de la cuisine interne du SGBD, mais je reste ouvert si quelqu'un d'autre peut mieux nous éclairer la dessus.

Citation:

---

Envoyé par fja34

Compte tenu de mon besoin, que me conseillez vous ?
- utiliser du JDBC ou un autre framework de persitance ou une autre implementation que JPA/Hibernate plus adaptée pour gérer de la distribution de mes plages de clients ?
- utiliser JPA hibernate ? Si oui avec quelles implementation de persistance ? Quel outil de cache et sous quel mode (terracota ? ehcache ? jboss cache ? repliqué ? distribué ? version ? )
- comment gérer ma "distribution" ou le scaling SGBDR : distribution ? replication ? load balancing ? fail over ? framework ou middle ware ?

---

Avant de répondre à ta question, j'aurais une question à te poser pour bien comprendre. Ton souci est il lié à une volumétrie très importante ou au nombre de transaction à un instant t quelconque qui peut être très important? ou les 2?

Citation:

---

Envoyé par fja34

merci pour vos conseils

---

Nous sommes là pour ça :mouarf:

Bonjour,

merci pour le temps que tu as pris à me répondre. J'étais un peu désespéré de ne pas voir de réponse au bout de plusieurs jours ;)

Alors, tout d'abord une question pragmatique:
- je veux développer un logiciel assez souple et rapidement
- je suis un adepte du "je modélise mon SQL et je génère mes classes à partir de mon modèle relationnel".

J'ai choisi du JSF 2 avec primefaces coté front.

Mes problématiques sont:
1) gérer un passage à l'échelle... je fais un logiciel de gestion pour des petites structures. Une structure aura entre 1 et 10 utilisateurs on va dire (et pas forcément simultanés. Dans la table comptable qui sera la plus volumineuse, j'aurais moins de 50 000 lignes par an et par structure. Mon objectif en mode saas est donc d'héberger dans un premier temps sur un environnement par exemple 30 structures (soit environ 100 à 150 utilisateurs et bien moins en simultané). Ensuite, je veux pouvoir grossir (plus grosse machine) puis pouvoir répartir les clients sur plusieurs machines le jour où par exemple j'en ai 1000 (hourra !).
Mon problème est donc dans l'absolu que je préfère avoir un "cluster de sgbd" qui stockent toutes les données de façon redondantes pour avoir à la fois la répartition des charge et la redondance pour la haute dispo / sauvegarde. Cela me permet potentiellement de limiter les risque si je pars pour des questions de perfs sur des machines physiques et non virtuelles (ca ne m'empechera pas de faire des sauvegarde, je rassure). Le cache est aussi un outil qui me permet de retarder les problèmes de charge au niveau SGBDR le plus tard possible sachant que JSF est gourmand et que plus tard je retarde, plus j'ai des moyens pour investir dans un refactering ou une réarchitecture ou de nouvelles techno
2) j'ai aussi le problème d'un accès au client/adhérent de la structure pour modifier son compte, etc. C'est un usage très occasionnel, mais c'est toujours du plus qui peut engender des utilisateurs simultanés en plus.

J'ai donc une volumétrie très importantes potentiellement et beaucoup d'utilisateurs avec une techno pas très économe (hibernate / jsf). Mais je n'ai pas de grosse complexité, car chaque table sera filtrée dans les requette par l'identifiant de ma structure et donc le moteur de base de données réduira la complexité de toutes les jointures très facilement en conservant des requêtes très petites qui peuvent s'exécuter en 10 ou 100ms.

Donc c'est un "traffic important, volumineux mais pas complexe" en gros. Par ailleurs, il s'agit d'un environnement avec peu de d'écriture et beaucoup de requête en lecture, sauf en période de rentrée scolaire où il y a tous les renouvellements d'adhésion pour tous les clients !

On peut mettre la réplication de coté je pense dans la suite du débat, car apparemment c'est pas forcément bien géré à ce jour par postgres.

Tout ceci devrait répondr à ta question sur mon besoin.

Ensuite, je complète mes questions concernant deux points:

Je galère sur la partie setup de mon projet (jusqu'ici dans mon métier, j'ai toujours bossé sur de l'existant, en plus j'aime pas maven et je l'ai dégagé). J'ai pris jboss tools et j'ai fait un reverse. Il me casse le pieds sur la génération et il me fait pas d'annotations propres, je sais pas pourquoi ca pete dans tous les sens. je suis donc parti sur un bon vieux mapping en XML, ce qui me permet de faire une hiérarchie objet bien propre à coté (sans relation hiérarchique représentée via ORM).

Du coup, je suis pas JPA. Et je me pose la question: si je suis certain d'utiliser Hibernate comme implémentation de persistance, (ce qui n'est pas aberrant, a priori, on n'a toujours pas fait mieux dans un cas comme le mien ?: c'est une vrai question) vaut il mieux se limiter à une norme JPA (et considérer que certains services de cache s'appliquent plutôt à JPA qu'à hibernate, que JPA m'ouvre plus facielement à des extensons) ou au contraire utiliser hibernate directement et considérer que tous les outils de type ehcache ou autre sont directement liés à l'implémentation et non à la norme ?

Si éventuellement vous pouvez me donner un coup de main sur le setup de mon projet, je suis preneur ! Mais peut être pas dans ce fil ;)

Merci

J'avoue qu'un problème posé de manière aussi kilométrique fatigue un peu les yeux, ça fait 3 fois que je re-parcours complètement ton post et à la fin j'oublie réellement où tu bloques, pourtant j'essaie d'être concentré en lisant :mouarf:.
Essaie d'être synthétique ou poses une seule problématique à la fois, on pourra mieux t'aider.
Si ton application est destinée à 90% sur l'année à de la pure lecture, il y'a donc peu de transactions à gérer, donc ceci minimise les problèmes de performance, avec 50000 lignes dans une table on est à des années lumières de commencer à penser repliquer les tables.
Si tu choisis d'utiliser Hibernate/JPA , il faudra mettre l'accent sur les stratégies de mapping oneToMany et ManyToMany, notamment sur le type de fetch, car c'est très souvent source de beaucoup d'extraction de données volumineuses inutiles en bases. Le problème le plus souvent n'est pas une techno en elle même mais bien ce qu'on en fait.
l'ORM via les fichiers XML plutôt que l'annotation c'est aujourd’hui clairement du "has been", ça se fait plus !!! Avec Hibernate tools en quelques secondes ton modèle POJO JPA est fin prêt avec les annotations qu'il faut.
Pour ce qui est de JSF2, qu'elle technologie RIA comptes tu choisir pour la gestion de tes composants qui alimenteront tes écrans ? (primefaces, richfaces, Mojarra, etc...)
Je te conseillerai pour l'instant de mettre de côté ces problématiques de replication de données et cache pour d'abord créer un socle métier fonctionnel et opérationnel de ton projet. Chaque chose en son temps. Et pour finir de grâce synthétiser des questions, ça n'aide pas les autres en recherche de lire une pile d'informations où on s'y perd à la fin.

Citation:

---

Envoyé par DevServlet

J'avoue qu'un problème posé de manière aussi kilométrique fatigue un peu les yeux, ça fait 3 fois que je re-parcours complètement ton post et à la fin j'oublie réellement où tu bloques, pourtant j'essaie d'être concentré en lisant :mouarf:.

---

La première moitié c'est pour détailler mon usage dans la mesure où tu voulais savoir quels objectifs j'ai à terme.

Dans l'ensemble t'as répondu à mes questions. J'ai des problèmes avec JBoss Hibernate tools qui me génère sans annotations alors que je respecte bien le tuto que tu référence si ce n'est que je n'étais pas en JPA. Je vais approfondir le sujet.

Pour le RIA je penchais pour Primefaces essentiellement.

Merci.

Je vais apporter mon point de vue; désolé si je répète ce qui a été dit.
Concernant la persistance, le choix d'un ORM est de t'abstraire de la base de données et par la même occasion de t'éviter d'écrire du SQL au maximum et ainsi faciliter tes développements.
Tu peux te concentrer sur JPA et seulement utiliser les spécificités de l'implémentation choisie, selon tes besoins.
Si tu es à l'aise en SQL et que tu as peur de ne pas bien maitriser JPA, tu peux rester avec JDBC mais cette option est de moins en moins utilisée.
Attention quand même, un ORM (comme tout framework) demande un investissement personnel pour bien maitriser les concepts clés. On peut vite faire n'importe quoi.

Par rapport à tes besoin, c'est bien de penser grand, mais parler déjà clustering, c'est peut-être un peu prématuré.
Jusqu'à présent, je suis toujours passé par de la réplication, même sur des projets conséquents.
On avait étudier la possibilité d'un cluster, mais ça impliquait l'utilisation de plusieurs machines: trop cher et complexe pour nos besoins.
Par exemple chez Mysql ils conseillent au moins 4 machine physiques pour le cluster : http://www.mysql.fr/products/cluster/faq.html#11

Citation:

---

Envoyé par fr1man

Je vais apporter mon point de vue; désolé si je répète ce qui a été dit.
Concernant la persistance, le choix d'un ORM est de t'abstraire de la base de données et par la même occasion de t'éviter d'écrire du SQL au maximum et ainsi faciliter tes développements.
Tu peux te concentrer sur JPA et seulement utiliser les spécificités de l'implémentation choisie, selon tes besoins.
Si tu es à l'aise en SQL et que tu as peur de ne pas bien maitriser JPA, tu peux rester avec JDBC mais cette option est de moins en moins utilisée.
Attention quand même, un ORM (comme tout framework) demande un investissement personnel pour bien maitriser les concepts clés. On peut vite faire n'importe quoi.

---

ok merci

pour le coté JPA ORM, c'est plus des services en aval qui me motivent (cache applicatif et 2n niveau eh cache, ...) qu'autre chose. Je suis bien plus à l'aise avec un SQL/JDBC dans les mains actuellement.