Vous n'êtes pas identifié(e).
Bonjour à tous.
Dans le cadre d'un projet, je souhaite stocker un (très) grand nombre de données binaires dans une même base.
J'ai commencé à regarder quelles étaient les solutions possibles. J'ai noté à ce jour 3 possibilités:
1) La première, que j'ai déjà mise en production il y a 4 ans sur un projet de base non pérenne, est le stockage des donnée binaires dans un champ de type BYTEA.
Dans ce cas, il faut échapper les caractères spéciaux par '\\'. Le volume final est de ce fait augmenté d'un facteur 2 à 3 (tout dépend du type de données origine) ce qui a un impact non négligeable sur le stockage.
2) Autre solution implémentée par un collègue, encoder le type binaire pour éviter d'avoir à échapper ces caractères spéciaux mais là aussi augmentation certes moindre mais d'environ 4/3 du volume
3) Sinon, utiliser le type 'large_object' dit 'lo' mais la limitation du type 'oid' utilisé pour référencer chacun des objets "lo" dans la table du dictionnaire est limité à 2*32 donc déjà inférieur à mon nombre actuel de données.
Si parmi vous certains ont été confrontés à cette problématique, leurs retours d'expérience me très seraient utiles, aussi bien sur la partie stockage que sur les performances en R/W.
Bonne journée.
Hors ligne
Si vous n'avez pas à faire de requêtes sur ces données binaires, autant ne pas les stocker dans la base.
Habituellement (enfin pour moi), on stock le PATH du fichier binaire dans la base et ce PATH pointe vers un fichier sur le FileSystem.
La base est plus petite, donc plus facile à sauvegarder / restaurer, par contre, il faut penser à backuper les fichiers sur le FS.
Dernière modification par arthurr (31/07/2013 14:26:43)
Hors ligne
D'accord avec arthurr. Stocker des objets binaires en base peut se faire et il existe de bonnes raisons pour le faire. Mais elles ne sont pas nombreuses et généralement, les inconvénients dépassent fortement les avantages.
Guillaume.
Hors ligne
Ok.
Alors disons que dans le cas où l'utilité est avérée et si vous avez été confronté à une telle configuration, quelle a été pour vous la solution la plus satisfaisante parmi celles que j'ai listées.
Je vous remercie par avance.
Hors ligne
le 1/ en utilisant une fonction automatique d’échappement suivant le langage utilisé pour peupler la base (quote en perl, pg_escape_bytea en php, ...).
"Le volume final est de ce fait augmenté d'un facteur 2 à 3" : d'après la doc, non : "Par exemple, une chaîne littérale passée au serveur comme E'\\001' devient \001 après être passée au travers de l'analyseur d'échappement de chaîne. Le \001 est envoyé à la fonction d'entrée de bytea, qui le convertit en un octet simple ayant une valeur décimale de 1", de plus ta donnée va être "Toasted" donc compressée.
Hors ligne
Bonsoir à tous.
J'avais oublié de mettre à jour ce post.
Effectivement, l'augmentation du à l'échappement ne se limite qu'à la RAM (durant la manip de la donnée avec un programme C/ecpg).
J'ai ré-importé une table de 60Go d'Oracle vers Postgresql et le volume est quasi-identique entre les 2 serveurs.
Merci arthurr.
Hors ligne
