BLOB ou références dans PostgreSQL


11

J'ai besoin de stocker des fichiers de données binaires dans une base de données PostgreSQL qui fonctionne sur un serveur Ubuntu. Initialement, il y aura quelques dizaines de fichiers d'environ 250 Ko chacun. Cependant, le nombre de fichiers augmentera avec le temps. Je peux parfois avoir besoin d'extraire des données des fichiers pour d'autres analyses en aval.

J'ai fait quelques recherches sur la question séculaire du stockage de données binaires en tant que BLOB ou références. Les deux ont évidemment leurs avantages et leurs inconvénients. Y a-t-il des problèmes spécifiques liés à PostgreSQL que je devrais connaître? Est-ce qu'une méthode ou l'autre est préférable si je veux extraire des données des fichiers, soit via une fonction PostgreSQL, soit via un programme Python externe?

Si je devais stocker les fichiers de données directement dans la base de données, serait-il préférable de les stocker dans une table séparée avec une clé étrangère référençant la table "principale", plutôt que dans la table contenant tous les autres champs?

J'ai lu la question et les réponses ici ; un commentaire suggère que le stockage de fichiers binaires par référence (dans le système de fichiers) sous Linux est préférable. Mes questions ici concernent spécifiquement PostgreSQL et l'extraction des données des fichiers pour diverses analyses.

Mise à jour: question similaire .


Avec PostgreSQl, il est possible de configurer une règle qui supprime automatiquement le fichier dans le système de fichiers lorsque l'enregistrement contenant la référence est supprimé.
jp

Je suis sûr qu'il y avait plus d'une réponse à cette question. Qu'est-ce qui lui est arrivé? Existe-t-il un moyen de le voir si l'affiche l'a supprimé? Qu'en est-il des commentaires?
SabreWolfy

Oui, je l'ai supprimé, car les problèmes de performances avec le bytea dont j'ai parlé peuvent être évités. Les commentaires peuvent être résumés par "Tout va bien avec bytea, vous devez simplement vous assurer que vous n'échappez pas aux caractères non imprimables dans la base de données, puis les rééchapper à nouveau dans votre application. Comme l'araqnid l'a commenté, vous devriez plutôt hex échappement pris en charge par libpq. "
jp

Réponses:


9

Je pense que vous devriez stocker les données dans la base de données comme une byteacolonne normale . De cette façon, vous obtenez tous les avantages d'une base de données et vous pouvez traiter les données à l'aide des fonctions de base de données (et même PL / Python, si vous le souhaitez). Les éléments de données plus volumineux seront automatiquement stockés hors ligne, il n'y aurait donc aucune raison pour vous d'introduire une autre indirection de référence.

Les principales raisons de stocker de gros objets binaires en dehors de la base de données seraient s'ils sont trop volumineux pour pouvoir les stocker et les récupérer dans un délai satisfaisant, s'ils gonflent la base de données au-delà de la fonctionnalité ou si vous devez accéder aux fichiers en tant que fichiers à partir de une application distincte. Pour autant que je sache, rien de tout cela ne s'applique ici.


Merci pour les détails. Votre point sur l'accès aux fichiers à partir d'une application distincte m'a amené à réaliser que je pourrais à l'avenir permettre aux utilisateurs de télécharger le fichier binaire à utiliser localement sur leur machine. Cela pourrait-il être fait si le fichier est stocké dans la base de données?
SabreWolfy

Sûr. Vous devrez écrire un petit morceau de code pour organiser cela (récupérer les données du fichier dans la base de données, organiser le téléchargement HTTP, par exemple), mais ce n'est pas un bloqueur.
Peter Eisentraut
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.