Fragmenter la persistance

Bonjour,

Voici la question que je me pose et surtout, si c'est bien de faire comme ça.

Pour simplifier et sans rentrer dans les détails, je possède une table d'utilisateurs dans une database qio se situe sur un serveur central (point d'entrée).
Chacun de ces utilisateurs va posséder des milliers de fichiers et il faudra donc ensuite etre capable de retrouver ces fichiers rapidement lors de certaines requetes. Ces fichiers (du moins, leurs informations) seront aussi dans une base de données.

Cependant, pour accroitre la performance pour la recherche des fichiers, et faire de la distribution, il y aura un nombre N d'autres serveurs avec base de données.
Lorsqu'un utilisateur ajoutera un fichier, le serveur central choisira un serveur entre les N serveurs disponibles au hasard (ou selon celui qui a le plus de ressources libres) et ajoutera dans la base de données de ce serveur le fichier en question.

Ces bases de données de fichiers auront donc pour chaque fichier une clé étrangère représentant l'utilisateur propriétaire. Mais cette clé étrangère représente donc un utilisateur qui se situe dans une base de données exterieure sur un autre serveur. Est-ce grave?

Avec les technologies JEE, JPA... y-a-t-il moyen de conserver ce genre de lien à travers plusieurs machines physiques?

Je sais pas si je suis claire. Mon but est donc de faire de la distribution de calculs et ressources pour retrouver une correspondance sur un fichier parmi peut-etre les millions en mémoire.

Comment s'y prendre correctement?

Bonjour, je trouve cette architecture beaucoup trop compliquée pour le besoin spécifié. C'est une architecture dans laquelle tu pars de zéro ou tu as déjà trouvé l'existant tel quel? si l'existant est tel quel, le plus compliqué à gérer n'est pas au niveau de JPA/Hibernate, mais déjà au niveau physique, si tu parviens déjà à définir des contraintes de clés étrangères sur des tables situées physiquement sur une base de données d'un autre serveur,c'est que ton mapping JPA suivra, car tu peux très bien gérer plusieurs contexte de persistence dans ton projet JPA, je veux dire plus d'un persistent context dans ton fichier persistence.xml,un exemple ici. Bon courage :mouarf:

Merci beaucoup ! C'est très bon à savoir !

Code:

---

si tu parviens déjà à définir des contraintes de clés étrangères sur des tables situées physiquement sur une base de données d'un autre serveur

---

Je me demandais d'ailleurs si cela était possible?

Mes besoins spécifiés ont été simplifiés dans le but de mieux vous faire comprendre mais en gros, ça sera plus ou moins équivalent. Mon but étant de faire du distribué afin de répartir les traitements sur des données entre plusieurs serveurs. Aurais-tu une autre idée sur laquelle me pencher?

Bonjour,
Dans notre environnement nous utilisons oracle, dans lequel nous mettons en place le mécanisme de DBLINK pour définir des relations entre des tables existant physiquement sur des bases de données de serveurs différents.Je ne sais pas si ce mécanisme est possible sur d'autres SGBD.Lequel utilisez vous?

Disons qu'une contrainte d'intégrité, est une sorte de garde fou automatique.
Tu peux très bien avoir des données réparties dans plusieurs bases avec des "pseudo" clés étrangères pour retrouver les informations, mais sans que les contraintes ne soient connues par les deux bases. C'est alors à ton application de contrôler cette intégrité, car c'est elle qui connait "la contrainte".

Après le risque est plus élevé d'avoir des données incohérentes entre les bases (suppression d'un tuple dans une base alors que ce tuple est référencé par un autre d'une autre).

Sinon effectivement, DBLINK permet de faire ceci en monde ORACLE.
Je sais que JTA permet de faire du transactionnel sur plusieurs bases en même temps, mais je ne pense pas que JTA soit capable de gérer les contraintes d'intégrité.

Bonjour, et encore merci.
Je suis sous MySQL et non sur Oracle. Je vais donc devoir gérer les contraintes d'integrités moi-meme. Si je manipule bien les rollback et commit, je ne devrais avoir de soucis.
Sinon, je pourrais faire un petit script qui tournera de temps en temps vérifiant si aucune incohérence ne persiste dans les bases.

Sinon j'aimerais juste etre rassuré concernant l'architecture générale afin de faire du distribué. Est-ce correct? Est-ce comme ça que font les entreprises généralement?

Pour ma part : non.

Le distribué est à plusieurs niveaux :
1 - plusieurs frontaux web load balancés
2 - plusieurs serveurs d'applications (mais pas trop) en cluster (répartition et failover EJB)
3 - une base de données en CLUSTER (donc du même éditeur) qui répartit les informations sur ses différents noeuds. Ces noeuds sont déclarés dans le URL de connexion JDBC (en tout cas pour Oracle).
4 - un SAN pour le stockage pur.

Il me semble que MySQL propose une version Cluster non ?
Exemple : http://www.johnandcailin.com/blog/jo...ng-mysql-proxy

Doc officielle :
http://dev.mysql.com/doc/refman/5.0/fr/ndbcluster.html

je ne l'ai jamais fait, donc je ne sais pas si cela marche bien avec MySQL.
Visible cela marche à peu près de la même façon qu'Oracle DB : https://blogs.oracle.com/carriergrad...jdbc_connector

Merci encore pour votre réponse enrichissante.

Plusieurs problèmes se posent :
- Mysql-proxy est en version alpha, et MySQL conseille de ne pas l'utiliser en environnement de production.
- Elle permet de segmenter nos données sur plusieurs serveurs MySQL mais ne permet pas non plus de définir des contraintes d'intégrité entre ces serveurs. (ce n'est qu'un constat, pas un problème puisque je traiterai ça en interne)

En fait, mon soucis est que la plus grosse partie du volume que représentera mes données fera parti d'une seule et meme table. Ainsi, il faudrait segmenter cette table sur plusieurs serveurs et faire en sorte que mon application soit capable de :
- lors de l'ajout d'un tuple, choisir dans quelle base de données l'insérer.
- pouvoir récupérer tous les tuples en fusionnant le contenu de chaque base de données.

Voilà pourquoi ma méthode serait de faire mon propre EJB (réplicable) qui se chargera de faire lui meme le load balancing. Cela est loin d'etre compliqué.
Qu'en pensez-vous?

EDIT:
Mon application sera hebergée sur Amazon EC2 et je viens de découvrir et me renseigner sur Amazon RDS (http://aws.amazon.com/running_databases/) qui permet d'héberger sa base de données MySQL. Amazon s'occuperait alors lui meme des back-ups, replications, segmentation et scalabilité offrant donc la meilleure performance possible.
Ainsi, si j'ai bien compris, je n'ai meme plus le besoin de me soucier du coté architecture de ma base de données et je peux ainsi TOUT déléguer à Amazon RDS en créant qu'une seule base au sein de ce service?

Quelqu'un aurait déjà eu une expérience avec?