Forums PostgreSQL.fr

ramirez22

Membre

[PG10] Stockage de fichiers

Bonjour,

Je reviens vers vous pour des conseils et des précisions.
Malgré le temps passé entre mon dernier post et celui-ci, je n'ai guère avancé dans ma connaissance profonde de PostgreSQL, donc prière d'employer un langage connu du Vulgum Pecus

Ma base permet une recherche de plans, en fonction de nombreux paramètres.
Ces plans sont dit 'sensibles' par ma société, et je dois évidemment essayer de sécuriser tout ça. mais c'est un autre sujet.
Je dispose d'un serveur sous Windows sever 2012 et d'un postgreSQL 10 installé. La plupart des ports de comm' ont été bloqués.

La table principale de la base contiendra plusieurs dizaines de milliers de lignes (50 000 à 100 000 à vue de nez) et chaque ligne est associée à un fichier pdf et potentiellement un autres fichier (les sources comme un fichier Word, AutoCAD etc ...). La taille des fichiers peut monter à 50-60 Mo dans le pire des cas. Sinon, ça tourne autour des 5 Mo en moyenne.

J'ai lu un peu de tout et son contraire sur le Net concernant la 'gestion' des fichiers par les SGBDD:
- "surtout pas de fichier, c'est pas fait pour ça"
- "pas de problème, sauf si les fichiers sont gros ou s'il y en a beaucoup"
- "vas-y fonce, c'est tout bon"

Bref, il y a de quoi péter un câble RJ45
Comme d'habitude, la vérité doit se trouver au milieu de tout ça, et je compte un peu sur vous pour éclairer ma lanterne (sans vouloir lancer un Troll sur le sujet).
Et d'abord, c'est quoi un fichier trop gros ? Et à partir de combien on considère qu'il y en a beaucoup ?

Bref, à priori, il existe deux modes de gestion, résumé en 2 types de données :
- le LargeObjet ou BLOB
- le bytea

J'ai également entendu parler de l'extension 'external_file' qui serait utile pour (à ce que j'ai compris) référencer et manipuler des fichiers physiquement stockés ailleurs que dans la base.

Sinon, il y a encore la possibilité de laisser la gestion des fichiers à l'OS (ce qui est un peu son boulot après tout) et de faire référence au chemin uniquement dans la base (c'est ce qui est actuellement réalisé). Mais cela nécessite de prévoir un serveur de fichier, d'ouvrir quelques ports supplémentaires etc ...

L'avantage de passer par la BDD, c'est que je n'ajoute pas d'ouverture de port, je bénéficie du chiffrement de la connexion directement par le SGBDD (SSL ou SSH) et que mes données ne sont pas facilement accessibles (nécessité d'avoir un ROLE permettant l'accès à ces données). Par contre, quid de la charge du serveur et du besoin en bande passante ? A ce sujet, j'ai omis de préciser qu'actuellement il y a 30 ROLES avec LOGIN et ultérieurement, cela pourrait monter à plus de 100. Par contre, le nombre de personnes connectées simultanément ne devrait pas excéder la dizaine sauf cas particulier et rarissime.
L'inconvénient, c'est que la sauvegarde de la base prendra un quart de siècle, mais ça c'est pas un soucis. Par contre, si l'application n'est pas utilisable parce qu'il y a trop de latence entre les requêtes ou que le fichier PDF met 3 plombes à se charger, c'est rédhibitoire.

A vos claviers et merci d'avance de vos éclaircissements.

Cdt,
Ramirez

gleu

Administrateur

Re : [PG10] Stockage de fichiers

Vous avez lu tout et son contraire parce que ça dépend évidemment du contexte. Ma première réaction a été "pas dans la base". Ceci dit, si le temps de sauvegarde n'est pas un problème, ça diminue mon objection. Il n'en reste pas moins que les opérations de maintenance risquent d'être ralenties par cette volumétrie. Surtout qu'on parle là de 100000 objets à 5 Mo de moyenne, 60 dans le pire des cas. Ce qui veut dire une instance comprise entre 500 Go et 6 To, en ne comptant que les documents. Et je ne prends en compte qu'un seul fichier par ligne, alors qu'apparemment la source peut aussi être stockée, ce qui veut dire plus ou moins doubler la volumétrie précédente... et tout ça sur un serveur Windows. Bon courage

Pour moi, c'est à tester avec une base contenant la volumétrie cible, ie au minimum les 500 Go.

---

Guillaume.

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Bonjour et merci de ce premier retour.

et tout ça sur un serveur Windows.

Pas le choix hélas ...

Pour moi, c'est à tester avec une base contenant la volumétrie cible, ie au minimum les 500 Go.

Pas faux, je vais essayer de mettre ça en œuvre, mais je ne sais pas quand ni trop comment pour l'instant Encore un peu de lecture en perspective ...

Surtout qu'on parle là de 100000 objets à 5 Mo de moyenne, 60 dans le pire des cas. Ce qui veut dire une instance comprise entre 500 Go et 6 To, en ne comptant que les documents. Et je ne prends en compte qu'un seul fichier par ligne, alors qu'apparemment la source peut aussi être stockée, ce qui veut dire plus ou moins doubler la volumétrie précédente..

Je n'ai pas encore de vision claire de la volumétrie, mais je devrais avoir une estimatif grossier assez rapidement. Je reviendrai d'ici peu pour compléter ces infos.

Mais pour compléter ma maigre connaissance de PostgreSQL, pourquoi est-il déconseillé de stocker des données de fichier ?
Pour éviter de surcharger le serveur (pendant qu'il envoie le fichier, il ne peut pas traiter d'autre requête) ? Mais alors dans ce cas, mettre un serveur de fichiers sur le même serveur physique ne va pas changer grand chose (les ressources restent "limitées" aux capacités du serveur physique). Ou est-ce uniquement pour que les opérations de sauvegarde prennent moins de ressources ? D'ailleurs, qu'appelle t'on "opérations de maintenance" ? D'autres tâches que la sauvegarde ?

Désolé si mes questions paraissent bêtes, mais ma spécialité reste l'automatisme industriel alors ...

Merci encore, bonne soirée.

gleu

Administrateur

Re : [PG10] Stockage de fichiers

Ce qui est intéressant de conserver dans la base, ce sont des données qu'il faudra rechercher. Ma définition est certes un peu restrictive mais elle est assez juste. La base de données n'est pas un stockage bête et méchant, c'est un stockage permettant de retrouver rapidement une info. Vous ne pourrez pas faire de recherches dans vos PDF, donc ce n'est pas intéressant en soi de les avoir dans la base. Mais en plus, cela va poser un ensemble de problème de maintenance et de sauvegarde. Pour rappel, avec PostgreSQL, un UPDATE revient à dupliquer la ligne. Donc vous mettez à jour n'importe quel information dans une ligne, et paf, vous vous retrouvez avec deux lignes (une seule visible par votre transaction, l'autre visible par les autres transactions tant que votre transaction n'est pas commitée). Et du coup, cette ligne prend double de place. Ajoutez une colonne, et mettez à jour la valeur pour y coller par exemple une valeur par défaut. Paf, vous doublez la taille de la table. Les 500 Go dont on parlait tout à l'heure ne concernaient qu'une table... pouf, 1 To maintenant. Alors, oui, ce ne sont pas des opérations que l'on fait souvent, oui, les opérations de maintenance permettront de récupérer l'espace, mais oui, on a aussi tendance à oublier ce truc, et se retrouver avec une table fragmentée alors qu'elle contient des documents peut rapidement coûter cher.

Pour répondre rapidement aux autres questions :
1. pendant qu'il envoie le fichier, il ne peut pas traiter d'autre requête.

Si, bien sûr. Mais si la première requête monopolise les disques, les autres requêtes vont en pâtir. Est-ce que ce sera suffisamment lourd pour que les utilisateurs s'en aperçoivent, seuls des tests pourront le montrer (et encore...).

2. Mais alors dans ce cas, mettre un serveur de fichiers sur le même serveur physique ne va pas changer grand chose (les ressources restent "limitées" aux capacités du serveur physique).

Un serveur de fichiers n'a pas besoin de conserver les anciennes versions des documents si une transaction est en cours (ce qui peut aussi être vu comme un avantage pour le stockage en base).

3. Ou est-ce uniquement pour que les opérations de sauvegarde prennent moins de ressources ?

Non, pas uniquement, mais c'est aussi un soucis. Comment comptez-vous sauvegarder 500 Go ?

4. D'ailleurs, qu'appelle t'on "opérations de maintenance" ? D'autres tâches que la sauvegarde ?

Oui. Il existe plusieurs opérations de maintenance, notamment VACUUM, ANALYZE et REINDEX, qui vont parcourir vos données de façon périodique. Plus vous avez de données, plus ces opérations seront lentes.

---

Guillaume.

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Merci beaucoup pour ces informations précises et surtout très bien explicitées.
Je n'avais aucune idée de tout ces détails et j'avoue que cela m'éclaire grandement.

Fort de ces explications, et par rapport à l'utilisation que j'en ai, il est désormais évident qu'il vaut mieux partir sur un serveur de fichiers en parallèle de ma base plutôt que d'enregistrer les fichier directement dans celle-ci.
Je suis également en train de creuser l'extension external_file, qui pourrait bien être le meilleur des 2 mondes : le fichier est sauvegardé sur un espace disque "en clair" et PostgreSQL sert de "passerelle" : pas besoin de serveur de fichier (donc pas de ports supplémentaire ouvert etc ...), droits utilisateurs ...

Je teste et vous dit ce qu'il en est. Si par contre vous avez un REX à partager, je suis également preneur.

Bonne nuit.

gleu

Administrateur

Re : [PG10] Stockage de fichiers

Concernant external_file, je pense en effet que c'est une bonne idée. Enfin, surtout sur Linux. Parce que 1. je suis certain que Gilles (son développeur) ne l'a pas testé sous Windows, 2. il vous faudra le compiler, vu que son développeur ne propose pas de version précompilée (toujours possible à trouver dans les dépôts Linux de la communauté, mais ceci n'existe pas pour Windows).

En parlant de Windows, et loin de moi l'idée de vouloir médire sur cet OS (principalement parce que peu m'importe ce que vous utilisez comme OS... chacun est libre de choisir ce qu'il veut), il faut quand même bien prendre en considération que Windows et PostgreSQL ne sont pas le couple idéal du fait de la conception multi-processus de PostgreSQL. La mémoire partagée est moins bien gérée sous Windows que sous Unix (et PostgreSQL a besoin de beaucoup de mémoire partagée)... il sera donc difficile d'aller bien haut dans la configuration de la mémoire partagée, ce qui sera problématique pour une base à haute volumétrie. De même, n'espérez pas dépasser fortement 100 à 150 connexions avec Windows. Voilà, voilà. En dehors de ça, PostgreSQL sera aussi stable sous Windows que sous Unix, juste moins performant. Mais ça ne sera pas forcément un problème. Encore une fois, tout dépend de l'appli.

---

Guillaume.

dverite

Membre

Re : [PG10] Stockage de fichiers

J'ai regardé un peu external_file, et c'est du plpgsql, il n'y a pas de code C.

Il utilise les large objects comme stockage intermédiaire, malheureusement ça n'est pas économe en accès disques: stockage du bytea en large object, export du large object en fichier externe, effacement du large object.

Une méthode plus efficace serait de faire des fonctions write_bytea() et read_bytea() qui feraient du transfert fichier<->bytea et rien d'autre, mais là effectivement cette efficacité là suppose de l'écrire en C, donc de compiler. En revanche le contenu lui-même des fonctions serait vraiment simple. C'est comparable à ce que fait pg_read_binary_file() pour la lecture
(une fonction intégrée) et pg_file_write du  module adminpack pour la lecture.

On peut aussi utiliser un langage de script untrusted, mais l'efficacité reste à tester. plperlu par exemple ne gère pas les passages de paramètres en binaire, donc une donnée  de X octets va être transformée en 2*X octets de texte en hexa puis reconvertis à l'envers une fois  dans la fonction.

---

@DanielVerite
http://blog-postgresql.verite.pro/

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Hello !

Merci pour toute vos intervention, mais là ça commence à devenir complexe pour moi : script untrusted, compilation C ... vite, une aspirine
Blague à part, j'ai eu l'occasion de tester un peu external_file.
Pour l'instant, j'arrive à envoyer un fichier PDF depuis mon application vers le serveur, qui le stocke bien là ou je lui dit... (sympa le serveur ).
L'ouverture du fichier directement sur le serveur fonctionne bien (le fichier PDF est intègre).
Par contre, le fonctionnement dans l'autre sens est un peu moins ... fonctionnel. Je me retrouve avec quelques NULL qui trainent à côté de chaque "caractères" (une petite ouverture sous notepad++) et la taille n'a rien à voir avec l'original (je perds 99 % des données). Bref, je n'arrive pas à récupérer mon fichier PDF.

En plus, je programme en Windev, ce qui complexifie encore plus la chose

En résumé, Windev n'est certainement pas le langage le plus utilisé, postgreSQL sur Windows Server idem ... j'aime les défis !!!
Ce soir un peu crevé, mais demain je vais y arriver !

Je crois que je vais jeter un oeil quand même à  pg_read_binary_file() et pg_file_write... histoire de voir si cela m'inspire.

Bonne soirée.

dverite

Membre

Re : [PG10] Stockage de fichiers

Un 0 à côté de chaque octet est typique de l'encodage UTF-16 que Windows utilise préférentiellement pour l'Unicode:
https://fr.wikipedia.org/wiki/UTF-16
Ca peut vouloir dire que le binaire aurait été pris à tort pour du texte et passé dans un mauvais filtre.

---

@DanielVerite
http://blog-postgresql.verite.pro/

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Bonjour,

J'ai testé avec pg_read_binary_file() et pg_file_write(). J'obtiens enfin le bon résultat mais cela nécessite que le rôle qui se connecte aie le privilège de super-utilisateur. Cela me pose des problèmes d'ordre "éthique", car même les administrateurs de l'application n'ont pas ce genre de droits ...

J'ai fais des essais avec external_file et ça marche pas trop mal non plus. Tout se fait via external_file et je n'ai pas de soucis au niveau des droits.
Je vais essayer de repartir sur une base vierge et recommencer afin de valider les manipulations (à force de faire des modifs, on n'est plus trop sur de ce qui fonctionne vraiment ), et surtout de l'implanter dans mon application pour voir si l'intégration ne pose pas de problème (en version stand-alone actuellement).

Pour ceux que ça intéresse :

// Requêtes d'écriture du fichier sur le serveur. %1=fichier à transmettre, %2=nom du fichier de destination
gsRequeteSQL = "SELECT external_file.writeEfile({WDMemoBinaire('%1')}, ('<Répertoire_destination>', '%2'));"

// Complétion de la requête avec les valeurs variables (SAI_fichier = chemin + nom + extension du fichier)
gsRequeteSQL = ChaîneConstruit(gsRequeteSQL, SAI_Fichier, fExtraitChemin(SAI_Fichier,fFichier+fExtension))

// Émission de la requête, traitement de l'erreur
SI SQLExec(gsRequeteSQL,gResultatSQL) = Faux ALORS 
	SQLInfoGene(gResultatSQL)
	Erreur(SQL.MesErreur)
	SQLFerme(gResultatSQL)
SINON
	Info("Envoyé")
FIN

//  -------------------------------------------------------------------------------------------
// Requête de lecture
gsRequeteSQL = "SELECT external_file.readefile(('<Repertoire_destination>', '%1'));"

// Là encore complétion de la requête avec les variables 
gsRequeteSQL = ChaîneConstruit(gsRequeteSQL, fExtraitChemin(SAI_Fichier,fFichier+fExtension))

// Émission de la requête et traitement de l'erreur
SI SQLExec(gsRequeteSQL,gResultatSQL) = Faux ALORS 
	SQLInfoGene(gResultatSQL)
	Erreur(SQL.MesErreur)
	SQLFerme(gResultatSQL)
SINON
	Info("Reçu")
	SQLAvance(gResultatSQL)
// Récupération des valeurs en format binaire et envoi dans l'image à afficher
	IMG_image = SQLLitMémo(gResultatSQL,1)
	SQLFerme(gResultatSQL)
FIN

J'espère que cela pourra aider certaines personnes.

Il ne restera plus qu'à gérer l'effacement des fichiers. En effet, il peut arriver qu'un fichier doive être effacé (obsolescence du fichier, erreur ...). Et là, external_file ne propose pas cette fonction. Il faudra voir si je peux octroyer les droits Super-utilisateur aux administrateur de l'application... A voir.

Bonne soirée.

dverite

Membre

Re : [PG10] Stockage de fichiers

Il n'est pas indispensable d'être connecté en tant que super-utilisateur si un super-utilisateur a délégué le droit d'usage via une fonction déclarée avec SECURITY DEFINER.

C'est d'ailleurs ce mécanisme qu'utilise l'extension external_file. Regardez le source:

https://github.com/darold/external_file … e--1.0.sql

CREATE OR REPLACE FUNCTION writeEfile(buffer bytea, e_file efile)
  RETURNS void
AS $$
   etc...
END;
$$ LANGUAGE PLPGSQL SECURITY DEFINER SET search_path = @extschema@, pg_temp;

Quand un super-utilisateur créé cette fonction, cette clause dit que les utilisateurs de cette fonction
auront les droits de super-utilisateur pendant son exécution.

Reste à donner les droits d'exécution via GRANT aux bons rôles, et (très important pour la sécurité), retirer le droit au pseudo-rôle public si ce n'est pas déjà fait globalement (ce pseudo-rôle désigne l'ensemble des utilisateurs):

REVOKE EXECUTE ON FUNCTION nom_de_fonction() FROM public;

---

@DanielVerite
http://blog-postgresql.verite.pro/

dverite

Membre

Re : [PG10] Stockage de fichiers

Il ne restera plus qu'à gérer l'effacement des fichiers. En effet, il peut arriver qu'un fichier doive être effacé (obsolescence du fichier, erreur ...). Et là, external_file ne propose pas cette fonction. Il faudra voir si je peux octroyer les droits Super-utilisateur aux administrateur de l'application... A voir.

Ce n'est pas un hasard ni un oubli il me semble, external_file n'a aucun moyen d'effaçer un fichier parce qu'il utilise l'API large object, spécifiquement  lo_export() pour écrire sur disque et lo_import() pour lire. Il y a bien un lo_unlink(), mais cette fonction effaçe un large object de la base, pas un fichier sur disque.

---

@DanielVerite
http://blog-postgresql.verite.pro/

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Bonjour.

Suite de mes pérégrinations. Je pense abandonner définitivement ce type de transfert.
Je viens de réaliser des tests avec mon application et avec des fichiers PDF de toute tailles (de moins de 1Mo à plus de 20 Mo) et de tout type (vectoriel et raster).
Hélas, les performances ne sont pas au rendez-vous (sachant qu'en plus, durant la phase de développement / test, je suis sur un serveur virtuel sur mon PC via virtualbox. Je suis donc affranchi des lenteurs occasionnées par le réseau...).

Je n'avais pas précisé que la version 1.0 de mon application utilisait une version HFSQL Classic (sorte de SQLite version PCSOFT, en mode fichier). La base de donnée et les données étaient sur un disque partagé sur un réseau RLE. Fonctionnement au poil, mais une crainte de voir des problèmes se pointer dès que plusieurs utilisateurs tentaient d’accéder en écriture en même temps aux enregistrements. D'où le besoin du serveur SQL pour, entre autre, sécuriser tout ça.

Dans la version client-serveur, le transfert vers la base se passe plutôt bien. Pas (trop) de ralentissement par rapport à la version d'avant pour les fichiers jusqu'à 2Mo. Par contre, cela commence à se gâter au delà.
L'opération inverse (lecture depuis la base) est plus problématique : je suis obligé d'enregistrer le fichier sur le disque "local" avant de l'ouvrir avec un ActiveX PDF pour l'afficher.
En effet, je n'ai accès qu'à un activeX adobe accrobat reader, puisqu'il est installé par défaut sur toutes les machines. Je n'ai pas la possibilité d'installer un autre viewer ActiveX car je n'ai pas les droits admin sur les machines clientes. Les fonctions de cet ActiveX sont très peu documentées (je n'ai trouvé que peu de choses sur le Net) et il semble qu'il ne soit possible que d'ouvrir un fichier (et non d'envoyer directement le flux de données dans l'ActiveX pour l'afficher.
Le cumul de ces opérations est là encore pas trop sensible pour les petits fichiers, mais plante lamentablement pour les gros (quand je dis plante, c'est que l'application se fige pendant le temps de chargement, qui est très long). Je pourrais faire un traitement en parallèle pour continuer à travailler sur l'application pendant le chargement du fichier, mais de toute façon, l'utilisateur n'a rien d'autre à faire : s'il a sélectionné un fichier, c'est pour le voir !

Bref, tout ça pour rien (ou presque, le fait d'apprendre est toujours gratifiant). Il ne me reste plus qu'à voir comment mettre en oeuvre un serveur de fichier sur mon Windows Server, et de le blinder au niveau sécurité d'accès.

Il est fort probable que les lenteurs proviennent du passage par un LO dans PostgreSQL. Il faudrait que je teste avec des fonctions plus directes comme pg_read_binary_file() et pg_file_write(), mais j'avoue commencer à perdre un peu en motivation
Allez, un dernier coup de collier

Merci à tous pour vos interventions.

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Un 0 à côté de chaque octet est typique de l'encodage UTF-16 que Windows utilise préférentiellement pour l'Unicode:
https://fr.wikipedia.org/wiki/UTF-16
Ca peut vouloir dire que le binaire aurait été pris à tort pour du texte et passé dans un mauvais filtre.

Rhaaaa ! Je vais pas y arriver

Bon, café, on va reprendre tout depuis le début.
J'ai du mal à envoyer mes données via une requête SQL par Windev. J'utilise l'argument {WDMemoBinaire('<Fichier>')}pour pouvoir envoyer les données "brutes", mais il se passe quelque chose pendant la com'.

Entête fichier PDF 'conforme' (envoyé par le client)
%PDF-1.6
%Þ­¾ï
6 0 obj
<<  /Length 39463 /Filter /FlateDecode /DecodeParms
<<  /Predictor 1

Entête fichier PDF 'non conforme' (reçu par le serveur)
%PDF-1.6\012%\336\255\276\357\0126 0 obj\012<<  /Length 39463 /Filter /FlateDecode /DecodeParms\012<<  /Predictor 

On voit bien que le fichier a été interprété (CR devient \012 par exemple). De plus, la taille du fichier a quasiment triplée. Le fichier est bien sur illisible.

Du coup, j'ai regardé les types de variables en entrée. pg_file_write demande des données sous forme text alors que j'envoie des données binaires. Il y a peu-être quelque chose à voir là dedans. Mais je ne vois pas comment envoyer mes données autrement que sous la forme binaire avec Windev ...

Il existe bien un pg_read_binary_file(), mais pas l'inverse ...
Je creuse ...

Dernière modification par ramirez22 (28/11/2018 11:11:52)

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Suite de mes essais.

Histoire de voir, j'ai quand même essayé de passer directement par un bytea et de stocker directement le(s) fichier(s) dans la base.
L'envoi du fichier est assez lent, mais comparable à ce que j'ai déjà vu.
La lecture du fichier passe par une opération d'enregistrement sur le disque dur local pour pourvoir ensuite l'ouvrir avec l'AtciveX. Tout roule, et c'est assez rapide à mon sens.

Je vais essayer de lancer une saisie multiple d'enregistrements, en variant taille et nombre de fichiers.
Puis je testerai la lecture histoire de voir les performance.

Je vous tiens au jus...

dverite

Membre

Re : [PG10] Stockage de fichiers

%PDF-1.6\012%\336\255\276\357\0126 0 obj\012<<  /Length 39463 /Filter /FlateDecode /DecodeParms\012<<  /Predictor

C'est manifestement du format 'escape', c'est-à-dire que les caractères ASCII sont tels quels et les autres sont sous forme octale précédé d'un antislash. \012  est le code de LF en octal.

https://www.postgresql.org/docs/current … inary.html

En ce qui concerne le chargement "bloquant" c'est un point intéressant, parce qu'effectivement laisser l'utilisateur poireauter devant l'écran sans information sur ce qui se passe,  à partir de quelques secondes, c'est vraiment gênant.

L'idéal c'est d'avoir une API et un stockage qui segmente les données et les renvoie segment par segment. Ce que les large objects font nativement, mais ils ont quelques inconvénients,notamment le fait que les segments sont trop petits (2048 octets max) de nos jours et qu'ils ne sont pas prévus pour des opérations en masse sur plein d'objets dans la même transaction (problème de verrouillage).

Mais une table de ce genre:
CREATE TABLE contenu_binaire(numero_objet bigint references objet(numero), numero_segment int, contenu_segment bytea),
qui ressemble beaucoup à pg_largeobject d'ailleurs, mais dont les segments sont limités à 512 Ko permet d'éviter les problèmes liés à la fois à taille des binaires et à leur nombre.

Avec des fichiers externes ça pourrait être fait aussi mais ça demande de la programmation côté serveur avec un langage "untrusted".

---

@DanielVerite
http://blog-postgresql.verite.pro/

ramirez22

Membre

Re : [PG10] Stockage de fichiers

Bonsoir.

Suite et fin de mes pérégrinations.
Je dis fin, car comme Jacques BREL, je n'irai pas plus loin

L'utilisation de la base en tant que stockage de fichier est un échec (dans mon cas). Pour la majeur partie des fichiers, cela se passe bien. A partir d'une taille (grosso merdo 10-15 Mo), le temps de transfert en écriture devient vraiment trop long. Sans parler de la lecture qui impose un téléchargement complet du fichier avant de pouvoir l'ouvrir par l'ActiveX Adobe. L'utilisation via un partage réseau permet de commencer à afficher les premières pages du fichier alors qu'il n'est pas encore complétement chargé = moins de latence pour l'utilisateur.

J'ai installé un service SMB sur mon serveur avec quelques droits bien sentis (bon OK, je me suis fais aider ) et mon application arrive à afficher les fichiers, même les plus gros, dans des délais raisonnables.

Pour des questions de sécurité, les échanges devront être chiffrés, ce qui implique un temps de chargement plus long. Quand je parle des échanges, je parle des échanges au niveau de SMB, mais également au niveau des requêtes SQL (SSL ? SSH ?)

L'idéal pour les fichiers serait un chiffrement/déchiffrement directement réalisé par l'application cliente : même un piratage du serveur ne servirait pas à grand chose dans ce cas. Mais bon, il faut que je regarde ce que ça donne avec les fonctions intégrées à Windev.

En tout cas, merci de votre soutiens, j'ai appris plein de choses grâce à vous.
Cordialement,
Ramirez