PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 12/07/2011 11:34:52

Postgres.0
Membre

C vs C++

Bonjour,

je commence un projet sur Postgresql :

le but est de copier des transactions d'un serveur vers un autre, il y a 300000 lignes à copier.
Dans l'existant, on utilise le langage C (libpq) pour se connecter au Serveur distant et copier les transactions ligne par ligne.
Mes questions sont de savoir si le C++ est meilleur que le C pour ce genre de replication.
Puis comment faire pour copier les lignes par bloc.

Merci de votre aide

Hors ligne

#2 12/07/2011 11:37:24

gleu
Administrateur

Re : C vs C++

Personnellement, j'utiliserais plutôt C. En fait, vu les détails que vous donnez, j'utiliserai des outils tout fait (comme pg_dump si c'est seulement sur une fois, ou slony si c'est vraiment de la réplication). Bref, vu ce que vous dites, je ne vois pas l'intérêt de créer son propre outil.


Guillaume.

Hors ligne

#3 12/07/2011 11:54:38

Postgres.0
Membre

Re : C vs C++

Ce n'est ps de la vrai replication, j'avoue.
Mais je ne peux pas faire de pg_dump, car ce n'est pas la meme table sur les deux serveurs.
En fait, les objets sur le base source et la base cible ne sont pas identiques.

Hors ligne

#4 12/07/2011 12:00:13

Postgres.0
Membre

Re : C vs C++

Et puis les tables sont sur deux serveurs differents

Hors ligne

#5 12/07/2011 13:27:14

gleu
Administrateur

Re : C vs C++

OK, utilisez plutôt du C (pour le langage) et du COPY (binaire si possible, pour l'instruction PostgreSQL).


Guillaume.

Hors ligne

#6 12/07/2011 13:37:23

Postgres.0
Membre

Re : C vs C++

Merci, mais je dois justifier ce choit.
Peus tu m'expliquer ce que fait le COPY.

Hors ligne

#7 12/07/2011 13:38:39

Postgres.0
Membre

Re : C vs C++

Car je penses que le copy, c'est plus entre table et fichier system.

Hors ligne

#8 12/07/2011 15:21:23

gleu
Administrateur

Re : C vs C++

L'intérêt du COPY, ce sont les performances. Il est impossible d'obtenir de meilleures performances avec plusieurs INSERT. COPY permet d'insérer plusieurs lignes en ne faisant qu'une synchronisation sur disque.


Guillaume.

Hors ligne

#9 12/07/2011 18:00:25

cedric
Membre

Re : C vs C++

Postgres.0 a écrit :

Ce n'est ps de la vrai replication, j'avoue.
Mais je ne peux pas faire de pg_dump, car ce n'est pas la meme table sur les deux serveurs.
En fait, les objets sur le base source et la base cible ne sont pas identiques.

Si le but est de recopier les données ajoutées/modifiées/... J'utiliserai PgQ (cf skytools) cela contient tout ce qu'il vous faut et est excessivement performant (C et PL/pgsql)

A noter que la version skytools3 devrait etre releasée prochainement.

http://wiki.postgresql.org/wiki/SkyTools


Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Hors ligne

#10 13/07/2011 11:58:15

Postgres.0
Membre

Re : C vs C++

PgQ est utilisé déjà, mais il veulent que j'améliore les perf.
On utilise un curseur dans le C pour copier les transactions une à une, ça fait beaucoup.
Ce qu'il veulent c'est écrire par bloc en mode assynchrone (c'est à dire ne pas attendre l'ACK avant d'envoyer le bloc suivant).
J'aimerai déjà voir sur un exemple (copy)  comment faire pour copier un bloc d'un serveur à un autre.
En suite gerer des timeout en cas de perte de connexion.

Désolé mais je n'arrive pas encore à bien apprehender le sujet.

Merci de votre aide

Hors ligne

#11 13/07/2011 15:10:03

Postgres.0
Membre

Re : C vs C++

Est ce que je peux faire un Copy d'une table vers une autre sans passer par un fichier?

Hors ligne

#12 13/07/2011 15:54:35

arthurr
Membre

Re : C vs C++

http://docs.postgresqlfr.org/9.0/sql-copy.html

...
FROM { 'nom_fichier' | STDIN }
...
TO { 'nom_fichier' | STDOUT }
...

Hors ligne

#13 13/07/2011 23:06:28

gleu
Administrateur

Re : C vs C++

Est ce que je peux faire un Copy d'une table vers une autre sans passer par un fichier?

"SELECT * INTO t2 FROM t1"

Ça crée une table t2 contenant les colonnes de t1 et les données de t1 sont placées dans t2. Évidemment, ça ne marche que sur un même serveur.


Guillaume.

Hors ligne

#14 14/07/2011 16:47:16

cedric
Membre

Re : C vs C++

Postgres.0 a écrit :

PgQ est utilisé déjà, mais il veulent que j'améliore les perf.
On utilise un curseur dans le C pour copier les transactions une à une, ça fait beaucoup.
Ce qu'il veulent c'est écrire par bloc en mode assynchrone (c'est à dire ne pas attendre l'ACK avant d'envoyer le bloc suivant).
J'aimerai déjà voir sur un exemple (copy)  comment faire pour copier un bloc d'un serveur à un autre.
En suite gerer des timeout en cas de perte de connexion.

Désolé mais je n'arrive pas encore à bien apprehender le sujet.

Merci de votre aide

Je ne saisis pas exactement quelles limites vous avez atteint. Ni ce que vous essayez de mettre en œuvre à la place. (vous parlez  de 'bloc', 'transaction', 'ligne', 'asynchrone'... une réplication asynchrone ? ou une réplication avant que le commit d'une transaction mettant a jour 300k lignes soit faite ??!!  ce n'est pas très clair... )

au cas ou:
Il existe plusieurs consumers utilisables avec PgQ.
Par défaut on trouve londiste bien sur. mais il y a aussi des consumers plus spécifiques qui conviendraient ici (bulk loader par exemple). On peut aussi développer ses propres consumers.
PgQ est le système de queueing le plus efficient disponible.
Entre la configuration de la taille des batch et les optimisations coté consumers vous devriez avoir les outils nécessaires pour améliorer votre existant.


Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Hors ligne

#15 18/07/2011 10:08:09

Postgres.0
Membre

Re : C vs C++

Bonjour,

merci pour les reponses.
Ici, nous travaillons en mode autocommit.
Quand je dis une transaction, c'est pour parler d'une ligne d'une table.
Ici "replication" c'est copier les données d'un serveur à un autre, je reafirme que c'est pas une vrai replication.
En fait, on copie les lignes d'une table d'un serveur à une autre table d'un autre serveur.
Sauf qu'on transfere les lignes une à une.
Ce que moi je veux faire, c'est au lieu de copier les lignes une à une, j'aimerai les copier par bloc.
Comme ça je gagne du temps

PS: je me suis trompé PgQ n'est pas utilisé ici.
Ici on utilise un batch  en C (libpq) pour ramener les donnée d'un serveur à un autre.

Hors ligne

#16 18/07/2011 11:05:23

gleu
Administrateur

Re : C vs C++

Donc on en revient à du COPY effectué par un programme utilisant la libpq. Rien de bien méchant.


Guillaume.

Hors ligne

#17 18/07/2011 11:32:21

Postgres.0
Membre

Re : C vs C++

Si j'ai bien compris, pour utiliser COPY :

il faut copier de la table A dans un fichier F, en suite, de ce fichier F, je copie dans la table B sur l'autre serveur.
COPY FROM TableA  TO fichierF

COPY FROM fichierF TO TableB.

Est-ce-que tu as un lien vers un bout de code dans lequel COPY est utilisé avec libpq.

Hors ligne

#18 18/07/2011 11:38:17

gleu
Administrateur

Re : C vs C++

Regarde le code de pg_dump, c'est ce qu'il fait. Et il y a surement d'autres codes dispos sur internet qui le font. D'ailleurs, en en parlant, ça me fait penser au code réalisé par un patch pour pgAdmin. Le code en question permet de copier une table d'un serveur vers un autre serveur. Le patch se trouve dans ce message : http://archives.postgresql.org/pgadmin- … g00227.php

Oh, d'autre part. Un COPY complet de la table ne te servira pas. Il te faut un COPY que des nouvelles lignes. Donc plutôt un "COPY (SELECT * FROM la_table_source WHERE la_condition') TO 'le_fichier';". Suivi d'un "COPY la_table_destination FROM 'le_fichier';".


Guillaume.

Hors ligne

#19 19/07/2011 17:01:52

Postgres.0
Membre

Re : C vs C++

Merci gleu,

comment je vais etre sur qu'en faisant un COPY je ne perds de lignes.

Hors ligne

#20 19/07/2011 17:40:06

gleu
Administrateur

Re : C vs C++

Je ne suis pas sûr de comprendre la question. COPY vous indique le nombre de lignes copiés, il vous suffit de comparer ça au nombre de lignes que vous indiquez à COPY. De toute façon, soit il enregistre tout soit il n'enregistre rien.


Guillaume.

Hors ligne

#21 19/07/2011 18:36:10

cedric
Membre

Re : C vs C++

Postgres.0 a écrit :

PS: je me suis trompé PgQ n'est pas utilisé ici.
Ici on utilise un batch  en C (libpq) pour ramener les donnée d'un serveur à un autre.

PgQ a un coût bien sur, mais pas nécessairement supérieur aux autres solutions envisageables. J'y regarderais a deux fois avant de faire un projet complètement 'maison'.


Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Hors ligne

#22 20/07/2011 09:35:32

Postgres.0
Membre

Re : C vs C++

Ce que je veux dire, c'est que s'il y a une interruption ou un problème quelconque avec mon fichier, comment je vais garantir que je ne perds pas des donnée.

Hors ligne

#23 20/07/2011 09:46:10

gleu
Administrateur

Re : C vs C++

C'est à votre programme de gérer cela. PostgreSQL ne peut pas y faire grand-chose.


Guillaume.

Hors ligne

#24 20/07/2011 16:12:06

Postgres.0
Membre

Re : C vs C++

Merci, je commence à voir un peu mieu.
Sinon j'ai d'autres questions :

Dans mon programme j'ai une fonction qui me connecte à la base, je lui donne le nom du service et ça marche car elle trouve le fichier conf machin...

Mais quand je fais deux appels successifs à cette fonction (pour me connecter à deux bases differentes), elle ne me connecte qu'à la première base.
Je ne comprends pas.

Dernière question: comment pourrais je gerer les timeout.

Merci et désolé pour les spams

Hors ligne

#25 21/07/2011 10:31:46

gleu
Administrateur

Re : C vs C++

Le service peut préciser la base de données. Ça pourrait expliquer pourquoi vous vous connectez toujours à la même. On aura besoin de plus d'infos si ce n'est pas le problème.

Quant aux timeouts, la question est trop générale pour pouvoir donner une réponse intéressante.

Il serait bien de formuler des questions assez précises.


Guillaume.

Hors ligne

Pied de page des forums