Discussion :

[vivi_35]

Bonjour à tous.

J'ai un soucis de synchronisation de tables avec Postgres.

J'ai une table (appellons la table_1) qui contiennent plusieurs millions de lignes et une autre table dans une autre base (table_2) qui reprends toutes les lignes de la table_1 mais pas toutes les colonnes (juste quelques unes).

J'aimerai faire que les modifs faites sur les lignes de ma table_1 soient répercutées sur ma table_2.

J'ai déjà un processus qui fait ca : un batch lancé toutes les 15 minutes (je n'ai pas besoin que ce soit forcément instantané) qui va répercuter les modifications en fonction d'une colonne date_de_mise_a_jour. Ce batch ne fait que récupérer les données des lignes mises à jour depuis le dernier lancement du batch et répercute les changements. Ca marche plutôt bien et ca traite quelques dizaines de milliers de lignes toutes les 15 minutes.

Mon soucis c'est que si je suis amené à lancer une procédure sur ma table_1 qui fait un traitement assez important, il se peut que cette procédure mette plus de 15 minutes à se lancer! Hors, comme vous le savez, quand on lance une procédure, la fonction now() retourne la date au lancement de la procédure; du coup les lignes en question ne sont pas synchronisées car, lorsque le batch se lance, il ne prends pas ces lignes en compte vu qu'elles ont été mises à jour il y a plus de 15 minutes.

Du coup je cherche un moyen plus intelligent de faire cette synchronisation.

Je pensais utiliser dblink mais ca n'est pas très concluant car ca m'oblige à faire des requêtes très lourdes pour faire la jointure et je ne souhaite pas utiliser Slony.

Avez-vous une idée à me soumettre? ^^

[hpalpha]

Bonsoir,

au lieu d'utiliser un cron, pourquoi ne pas faire un trigger ?

[gerald2545]

avec un trigger tu ne peux pas accéder à une autre base de données? je me trompe?
Sinon, dans ta base 1 tu crées une table équivalente à ta table_2 de la base_2 qui te sert de transfert. A chaque fois qu'un enregistrement est inséré dans ta table_1 (base_1) tu inséres les données qu'il te faut dans table_2 (base_1) et tu lances ton cron sur le contenu de table_2 (base_1) dont tu supprimes les enregistrements copiés en fin de manip?
non?

[hpalpha]

Si tu peux faire un trigger sur une autre base, mais c'est de la bidouille plus qu'autre chose, mais ca marche, je l'ai utiliser pour une appli qui tourne encore tres bien.

Pour la deuxieme partie, je te suis pas trop bien (de bon matin au reveille, j'ai un peu de mal !)

[gerald2545]

je te laisse relire un coup après ton café ou tu veux plus de détail?
je propose ça mais je n'ai jamais fait.....donc c'est juste une idée

[vivi_35]

Sinon, dans ta base 1 tu crées une table équivalente à ta table_2 de la base_2 qui te sert de transfert. A chaque fois qu'un enregistrement est inséré dans ta table_1 (base_1) tu inséres les données qu'il te faut dans table_2 (base_1) et tu lances ton cron sur le contenu de table_2 (base_1) dont tu supprimes les enregistrements copiés en fin de manip?
non?

Et bien c'est une bonne idée mais j'aimerai éviter de créer une table "temporaire" parce que ma table_2 de ma base_2 à un équivalent sur une base_3, une base_4, etc ^^ En fait la table que j'essaie de dupliquer est une table qui contient les infos des comptes de mes utilisateurs et les tables répliquées contiennent les lignes pour une application (et un serveur) donné. Donc si j'ai mettons 10 applications, ca me fait 10 tables temporaires

[vivi_35]

Up

Sait-on jamais.

[budtucker]

Salut,

Est ce que les changements dans ta base 1 sont assez fréquents (plus d'une centaine de fois par minute) ? Si oui, il est clair qu'un trigger ferait ramer Postgre.

Pour une table faisant 1 million d'occurence, faire un export, c'est pire. Une table tempo risque de rendre le traitement lent, mais ça peut marcher.

Cependant, je préconise tout de même le Trigger. D'une part c'est plus propre [qu'un cron] et d'autre part, tout est centralisé à un seul endroit : Postgre.

Un Trigger entre 2 bases se fait par l'intermédiaire de dblink.
A+

[vivi_35]

Effectivement les changements dans ma table sont très fréquents On dois effectivement dépasser les 100 modifications par minute.

Je vais faire des tests via dblink mais ce que je n'aime pas trop dans ce dernier c'est que je dois systématiquement fournir une requête et préciser le type de chaque champ J'aimerai bien remplacer ma table_2 par une vue mais j'ai beaucoup de colonnes dans ma table d'origine et j'ai peur qu'utiliser dblink soit super contraignant dans ce cas précis.

[budtucker]

C'est clair, que si tu as beaucoup de colonne, ça risque d'être long. Mais tu peux très bien (faut voir si c'est possible dans ton cas) générer la liste des colonnes en batch dans une fonction qui renvoie un "record". La solution devrait être ça je pense. Tu créé ta requête SQL et ta "tonne" de colonne directement dans une boucle "for". La liste des colonnes sera à reccupérer dans les catalogues. Dans un "execute", tu lances la requête générée et tu renvoie pour chaque ligne le resultat que tu souhaites. Ensuite, en fonction de ce résultat, tu peux faire tes vérfications et éventuellement tes ajouts dans la nouvelle base.

L'avantage, c'est que ce n'est pas de la "bidouille" puisque l'on utilise 100 % de Postgre. L'avantage encore est que tu n'utilises qu'un seul processus : celui de Postgre.

Raconte nous au fur et à mesure....

A+

[icer]

ça te fait pas mal d'information dupliquées donc une baisse de l'intégrité de tes bases...

Pourquoi est-ce que tu n'utilise pas la même base de données pour tes différentes applications ?

[vivi_35]

ça te fait pas mal d'information dupliquées donc une baisse de l'intégrité de tes bases...

Pourquoi est-ce que tu n'utilise pas la même base de données pour tes différentes applications ?

Pour décharger le serveur de bado en question justement!

On a pas mal de serveurs web pour différentes applications et cette base est la base "commune" on va dire. Et c'est ingérable que tout les serveurs tapent le dit serveur sinon il monte tout de suite en load. Du coup on a décidé de faire cette sorte de copie "light" pour chaque appli; ca marche plutôt pas mal.

L'idéal serait de répliquer la base en question sur plusieurs serveurs et faire un systeme de load balancing mais on manque un peu de serveurs ^^