problème de conception [Résolu]

[LeHibou2]

Bonjour à tous,

Je viens vous voir car j'ai un pépin.

Une base déjà existante a pas mal d'enregistrements (plus d'un milliard).

Un autre serveur aura aussi ses enregistrements avec ses propres clés primaires. Pas de réplication possible.

Pour simplifier l'exemple, considérons deux tables :
table 1 => inscrit
table 2 => adresses

La table 2 contient l'id de la table 1 pour les jointures sur le champ id.

Idem sur l'autre serveur.

Alors trois idées sont venues :

1) sur le deuxième serveur où les données vont devoir être mergées, les clés primaires (id) auront une valeur très supérieure. Avantage : permet de s'en sortir pendant un temps mais si les id se rejoignent, c'est la fin des haricots.

2) se débrouiller pour que les id de chaques serveurs commencent par un chiffre, cela nous oblige à avoir 9 serveurs au max.

3) avoir un id de type texte s1-"id" pour le serveur 1 s2-"id" pour le serveur 2 etc. Ceci nous ferait perdre massivement en performance.

Je ne vois pas de solution pour ne pas être ennuyé avec les clés primaires lors de merge massifs. Le tout sans réplication (sinon je ne serais pas là).

Vous avez une idée qu'on n'aurait pas vue ? On ne peut plus changer de manière drastique les base. Un nouveau modèle ne peut pas être envisagé pour le moment.

Merci à vous,

LeHibou2

[CinePhil]

Il faut ajouter une colonne identifiant le serveur d'où provient la donnée et l'inclure dans la clé primaire.

inscrit (ins_serveur, ins_id...)
adresse (adr_id_serveur, adr_id, adr_id_inscrit...)

On suppose ici que l'id du serveur de l'adresse est le même que l'id du serveur de l'inscrit.

[LeHibou2]

C'est effectivement une excellente solution.

Cependant comment être sûr de trouver la ligne selon que l'on se connecte sur le serveur 1 ou 2 ?

Ca complique pas mal.


Autre solution : prévoir 100 milliards de lignes par serveur et commencer les id du serveur 2 à 200 milliards. etc...
Le merge ne pose plus de soucis comme ça.

100 milliards de lignes, c'est quand même pas mal. On peut aussi encore aller plus loin avec 1000 milliards de lignes.

Point de vue perf, cela restera correct, non ? Bien sûr un poil plus long que si on avait id=1, mais je ne pense pas que cela sera très problèmatique.

Un point que je ne soupçonne pas ?

Merci beaucoup,

[CinePhil]

Envoyé par LeHibou2

C'est effectivement une excellente solution.

Cependant comment être sûr de trouver la ligne selon que l'on se connecte sur le serveur 1 ou 2 ?

Quel problème ?

Soit je sais que j'ai besoin de la ligne 124 du serveur 2, soit je cherche l'inscrit ayant pour login "LeHibou2" et c'est la requête qui me retournera par exemple l'identifiant {124, 2}.

[LeHibou2]

N'est-ce pas plus long que de simplement chercher l'id dans la base ?

Je veux dire : id unique grâce à une plage d'id entre deux serveurs très large ?

[CinePhil]

Dans les deux cas, c'est une recherche sur la clé primaire. C'est peut-être légèrement plus long avec deux colonnes mais pas sûr que ce soit significatif.

[LeHibou2]

Merci beaucoup Cinéphil,

On part donc sur deux solutions à creuser avec sérieux.

La réplication aurait permis de gagner pas mal de temps. Quoique sur du wan.. avec de la réplication master-master...