50 votes

Stocker des documents en tant que blobs dans une base de données - des inconvénients?

Les exigences pour mon système de gestion de documents étaient :

  1. Doit être protégé contre le vol par simple copie de répertoires, fichiers, etc.
  2. Doit être protégé contre l'infection virale traditionnelle (infection de fichier physique)
  3. Doit être rapide à récupérer
  4. Le dépôt ne doit pas être visible pour les utilisateurs parcourant les répertoires de manière occasionnelle, etc.

J'ai décidé de stocker tous les documents (et images scannées) en tant que blobs dans la base de données et jusqu'à présent, mon expérience est merveilleuse et la récupération de documents est extrêmement rapide - cela répond à tous les critères mentionnés ci-dessus et présente même plusieurs avantages supplémentaires, tels que le stockage automatique des documents avec l'entité à laquelle ils se rapportent, une recherche facile et rapide du contenu, la suppression de toutes sortes d'activités des utilisateurs autour de l'ouverture et de la dénomination des documents, etc.

Ma question est - y a-t-il des risques sérieux ou des choses que j'aurais négligés avec cette conception et cette implémentation ?

Note de modification : La base de données est PostgreSQL, gère très bien les BLOBS et s'adapte exceptionnellement bien. L'environnement est multi-utilisateurs.

35voto

Jacco Points 12528

Lorsque votre BD devient de plus en plus grande, il devient de plus en plus difficile de la sauvegarder. Restaurer une sauvegarde d'une table avec plus de 100 Go de données n'est pas quelque chose qui vous rendra heureux.

Autre chose qui se produit est que toutes les fonctions de gestion de table deviennent de plus en plus lentes à mesure que l'ensemble de données augmente.
Cependant, cela peut être surmonté en faisant en sorte que votre table de données ne contienne que 2 champs : ID et BLOB.

Récupérer des données (par clé primaire) ne posera probablement problème que longtemps après avoir atteint une limite lors de la sauvegarde de l'ensemble de données.

29voto

Bill the Lizard Points 147311

Le principal inconvénient que j'entends souvent concernant l'utilisation de blobs est que, au-dessus d'une certaine taille, le système de fichiers est beaucoup plus efficace pour stocker et récupérer de grands fichiers. Il semble que vous avez déjà pris cela en compte par votre liste des exigences.

Il y a une bonne référence (PDF) ici qui couvre les avantages et les inconvénients des blobs.

13voto

CodingWithSpike Points 17720

De mon expérience, voici quelques problèmes rencontrés :

  1. la vitesse par rapport au fait d'avoir des fichiers sur le système de fichiers.

  2. le cache. À mon avis, le serveur web fera un meilleur travail en mettant en cache les contenus statiques. La base de données fera également un bon travail, mais si la base de données gère également toutes sortes d'autres requêtes, ne vous attendez pas à ce que ces gros documents restent mis en cache longtemps. Vous devez essentiellement transférer les fichiers deux fois. Une fois de la base de données vers le serveur web, puis du serveur web vers le client.

  3. Les contraintes de mémoire. Dans mon dernier emploi, nous avions un PDF de 40 Mo dans la base de données et nous recevions constamment des erreurs Java OutOfMemory dans le fichier journal. Nous avons finalement réalisé que le PDF entier de 80 Mo était lu dans le tas non pas une fois, mais DEUX fois grâce à un réglage dans Hibernate ORM (si un objet est mutable, il en fait une copie pour l'édition en mémoire). Une fois que le PDF a été renvoyé en streaming à l'utilisateur, le tas a été nettoyé, mais c'était un gros coup de devoir aspirer 80 Mo du tas d'un coup juste pour diffuser un document. Connaissez votre code et comment la mémoire est utilisée !

Votre serveur web devrait être capable de gérer la plupart de vos préoccupations en matière de sécurité, mais si les documents sont petits et que la base de données n'est pas déjà sous une charge importante, je ne vois pas vraiment de gros problème à les avoir dans la base de données.

4voto

tggagne Points 400

Je viens juste de commencer à étudier le FILESTREAMing de SQL Server 2008 pour les BLOBs et j'ai rencontré une ÉNORME limitation (à mon avis) - cela ne fonctionne qu'avec la sécurité intégrée. Si vous n'utilisez pas l'authentification Windows pour vous connecter au serveur de base de données, vous ne pourrez pas lire/écrire les BLOBs. De nombreux environnements d'application ne peuvent pas utiliser l'authentification Windows. Surtout pas dans des environnements hétérogènes.

Une meilleure solution pour stocker les BLOBs doit exister. Quelles sont les meilleures pratiques?

3voto

user175667 Points 196

En se basant sur mon expérience, il est plus sain de garder les fichiers sur le système de fichiers, car il est plus facile de sauvegarder la base de données et le système de fichiers séparément. Avoir les documents sur des fichiers externes vous permet de migrer facilement d'un moteur de base de données à un autre sans avoir à vous soucier de recoder les requêtes et le code pour accéder aux documents stockés en tant que blobs. La plupart des systèmes de gestion de documents adoptent cette approche, par exemple Owl ou Logicaldoc

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X