Sans aller jusqu'a dire que c'est exactement le témoignage que j'attendais... C'est exactement le temoignage que j'attendais :)
bon moi la seule différence c'est que je vais pas utiliser un bytea mais un champ text tout bête.
Je serais toi, si c'est pour une raison de portabiliter, je ferais simplement un warper autour des fontion bytea. Surtout pour les perfs, il est plus rapide d'utiliser un bytea que d'encoder en autre chose.
Tu peux aussi mettre a contribution le protocol v3 de postgres, qui fait qu'il ressemble bcp plus a ce que l'on trouve dans les autres sgbd, c'est a dire requettes parametrable et surtout, envoie direct des données en format binaire, sans conversion (ni par bytea ni rien d'autre).
Le gros avantage, c'est avant tout la vitesse, tu ne fais plus que tu transfert brut. Puis c'est plus propre. Je suis en train de mettre à jour mes routines pour en tenir compte, voir un peu ce que ca donne.
juste une question pour que je me rende bien compte. Quel est la taille d'un backup (non compréssé si possible) que je me rende compte de la volumétrie de ta base. parce que moi il devrait y avoir plusieurs milliers de documents ajoutté par mois.
C'est pas une base gigantesque, le dump fait dans les 6 ou 7 giga, on a quelques milliers de documents plus d'autres bases de données clients qui font quelques mega.
Pour ca, la version 8 de Pg va nous etre tres utile puisque nous allons simplement fair un backup par semaine et le reste, c'est de l'archivage de fichiers de logs.
Si un jour tu rencontre quand meme des problemes de perfs, tu peux toujours distribuer les requettes en utilisant slony pour repliquer la base, c'est ce que l'on avait fait avant de passer au bi-pro en raid. Un PIII 450 ca suffisait plus ... :)
ce qui va nous emmener rapidement a quelques gigas de données... oula. je n'avais pas fait ce calcul !!!
Justement, tout dans un seul dump.
La machine prend feu, tout pete, les disques grillent... etc. tu restore juste ton dump et tu as ton applis qui repart tout seul. En tout cas c'est ce que l'on a nous puisque on n'enregistre pratiquement pas de fichiers, tout est dans la bases, meme les pages web.
a+
Etienne SOBOLE wrote:
Sans aller jusqu'a dire que c'est exactement le témoignage que
j'attendais...
C'est exactement le temoignage que j'attendais :)
bon moi la seule différence c'est que je vais pas utiliser un bytea mais
un champ text tout bête.
Je serais toi, si c'est pour une raison de portabiliter, je ferais
simplement un warper autour des fontion bytea. Surtout pour les perfs, il
est plus rapide d'utiliser un bytea que d'encoder en autre chose.
Tu peux aussi mettre a contribution le protocol v3 de postgres, qui fait
qu'il ressemble bcp plus a ce que l'on trouve dans les autres sgbd, c'est a
dire requettes parametrable et surtout, envoie direct des données en format
binaire, sans conversion (ni par bytea ni rien d'autre).
Le gros avantage, c'est avant tout la vitesse, tu ne fais plus que tu
transfert brut. Puis c'est plus propre. Je suis en train de mettre à jour
mes routines pour en tenir compte, voir un peu ce que ca donne.
juste une question pour que je me rende bien compte.
Quel est la taille d'un backup (non compréssé si possible) que je me rende
compte de la volumétrie de ta base.
parce que moi il devrait y avoir plusieurs milliers de documents ajoutté
par mois.
C'est pas une base gigantesque, le dump fait dans les 6 ou 7 giga, on a
quelques milliers de documents plus d'autres bases de données clients qui
font quelques mega.
Pour ca, la version 8 de Pg va nous etre tres utile puisque nous allons
simplement fair un backup par semaine et le reste, c'est de l'archivage de
fichiers de logs.
Si un jour tu rencontre quand meme des problemes de perfs, tu peux toujours
distribuer les requettes en utilisant slony pour repliquer la base, c'est
ce que l'on avait fait avant de passer au bi-pro en raid. Un PIII 450 ca
suffisait plus ... :)
ce qui va nous emmener rapidement a quelques gigas de données...
oula. je n'avais pas fait ce calcul !!!
Justement, tout dans un seul dump.
La machine prend feu, tout pete, les disques grillent... etc. tu restore
juste ton dump et tu as ton applis qui repart tout seul. En tout cas c'est
ce que l'on a nous puisque on n'enregistre pratiquement pas de fichiers,
tout est dans la bases, meme les pages web.
Sans aller jusqu'a dire que c'est exactement le témoignage que j'attendais... C'est exactement le temoignage que j'attendais :)
bon moi la seule différence c'est que je vais pas utiliser un bytea mais un champ text tout bête.
Je serais toi, si c'est pour une raison de portabiliter, je ferais simplement un warper autour des fontion bytea. Surtout pour les perfs, il est plus rapide d'utiliser un bytea que d'encoder en autre chose.
Tu peux aussi mettre a contribution le protocol v3 de postgres, qui fait qu'il ressemble bcp plus a ce que l'on trouve dans les autres sgbd, c'est a dire requettes parametrable et surtout, envoie direct des données en format binaire, sans conversion (ni par bytea ni rien d'autre).
Le gros avantage, c'est avant tout la vitesse, tu ne fais plus que tu transfert brut. Puis c'est plus propre. Je suis en train de mettre à jour mes routines pour en tenir compte, voir un peu ce que ca donne.
juste une question pour que je me rende bien compte. Quel est la taille d'un backup (non compréssé si possible) que je me rende compte de la volumétrie de ta base. parce que moi il devrait y avoir plusieurs milliers de documents ajoutté par mois.
C'est pas une base gigantesque, le dump fait dans les 6 ou 7 giga, on a quelques milliers de documents plus d'autres bases de données clients qui font quelques mega.
Pour ca, la version 8 de Pg va nous etre tres utile puisque nous allons simplement fair un backup par semaine et le reste, c'est de l'archivage de fichiers de logs.
Si un jour tu rencontre quand meme des problemes de perfs, tu peux toujours distribuer les requettes en utilisant slony pour repliquer la base, c'est ce que l'on avait fait avant de passer au bi-pro en raid. Un PIII 450 ca suffisait plus ... :)
ce qui va nous emmener rapidement a quelques gigas de données... oula. je n'avais pas fait ce calcul !!!
Justement, tout dans un seul dump.
La machine prend feu, tout pete, les disques grillent... etc. tu restore juste ton dump et tu as ton applis qui repart tout seul. En tout cas c'est ce que l'on a nous puisque on n'enregistre pratiquement pas de fichiers, tout est dans la bases, meme les pages web.
a+
John Gallet
Bonjour,
le problème serait résolu si tu utilisait IBM DB2. En effet, c'est le seul SGBDR à répondre aujourd'hui à cette double roblématique : externaliser les données fichiers et intégrer un mécanisme d'intégrité référentielle et de sauvegarde gobale.
En quoi le type BFILE d'Oracle ne correspond pas à cette description ?
a++; JG
Bonjour,
le problème serait résolu si tu utilisait IBM DB2. En effet, c'est le seul SGBDR
à répondre aujourd'hui à cette double roblématique : externaliser les données
fichiers et intégrer un mécanisme d'intégrité référentielle et de sauvegarde gobale.
En quoi le type BFILE d'Oracle ne correspond pas à cette description ?
le problème serait résolu si tu utilisait IBM DB2. En effet, c'est le seul SGBDR à répondre aujourd'hui à cette double roblématique : externaliser les données fichiers et intégrer un mécanisme d'intégrité référentielle et de sauvegarde gobale.
En quoi le type BFILE d'Oracle ne correspond pas à cette description ?
