C vs C++

Postgres.0 · 12/07/2011 11:34:52

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

gleu · 12/07/2011 11:37:24

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.

Postgres.0 · 12/07/2011 11:54:38

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.

Postgres.0 · 12/07/2011 12:00:13

Et puis les tables sont sur deux serveurs differents

gleu · 12/07/2011 13:27:14

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

Postgres.0 · 12/07/2011 13:37:23

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

Postgres.0 · 12/07/2011 13:38:39

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

gleu · 12/07/2011 15:21:23

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.

cedric · 12/07/2011 18:00:25

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

Postgres.0 · 13/07/2011 11:58:15

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

Postgres.0 · 13/07/2011 15:10:03

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

arthurr · 13/07/2011 15:54:35

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

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

gleu · 13/07/2011 23:06:28

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.

cedric · 14/07/2011 16:47:16

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.

Postgres.0 · 18/07/2011 10:08:09

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.

gleu · 18/07/2011 11:05:23

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

Postgres.0 · 18/07/2011 11:32:21

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.

gleu · 18/07/2011 11:38:17

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';".

Postgres.0 · 19/07/2011 17:01:52

Merci gleu,

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

gleu · 19/07/2011 17:40:06

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.

cedric · 19/07/2011 18:36:10

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'.

Postgres.0 · 20/07/2011 09:35:32

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.

gleu · 20/07/2011 09:46:10

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

Postgres.0 · 20/07/2011 16:12:06

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

gleu · 21/07/2011 10:31:46

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.

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

C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

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

Re : C vs C++

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux