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

Question

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

1. Doit être protégé du vol par une simple copie des répertoires, des fichiers, etc.
2. Doit être sécurisé contre l'infection virale traditionnelle (infection de fichier physique)
3. Doit être rapide pour récupérer
4. Le référentiel ne doit pas être visible pour les utilisateurs occasionnels (répertoires) parcourant, etc.

J'ai décidé de stocker tous les documents (et images numérisées) sous forme de blobs dans la base de données. Jusqu'à présent, mon expérience est merveilleuse et la récupération de documents est extrêmement rapide. Elle répond à tous les critères énumérés ci-dessus. des avantages supplémentaires, tels que l'enregistrement automatique des documents avec l'entité concernée, la recherche simple et rapide de contenu, la suppression de toutes sortes d'activités utilisateur relatives à l'ouverture et à la désignation de documents, etc., etc.

Ma question est la suivante: existe-t-il des risques graves ou des problèmes que j'ai oubliés avec cette conception et cette mise en œuvre?

EDIT Remarque: DB est PostgreSQL, gère très bien les BLOB et évolue exceptionnellement bien. L’environnement est multi-utilisateur.

Answer 1

Lorsque votre base de données devient de plus en plus grande, il devient plus difficile de sauvegarder. Restaurer une sauvegarde d'une table contenant plus de 100 Go de données ne vous rend pas heureux.

Un autre inconvénient est que toutes les fonctions de gestion de table deviennent de plus en plus lentes à mesure que le jeu de données se développe.
Mais ceci peut être surmonté en faisant en sorte que votre table de données ne contienne que 2 champs:  ID et BLOB.

La récupération des données (par clé primaire) ne deviendra probablement un problème que longtemps après que vous ayez heurté un mur en sauvegardant l'ensemble de données.

Answer 2

L’inconvénient principal que j’entends souvent à propos de l’utilisation de blobs est qu’au-delà d’une certaine taille, le système de fichiers est beaucoup plus efficace pour stocker et récupérer des fichiers volumineux. On dirait que vous en avez déjà tenu compte dans votre liste d'exigences.

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

Answer 3

D'après mon expérience, voici quelques problèmes:

1. vitesse vs avoir des fichiers sur le système de fichiers.

2. mise en cache. OMI le serveur web fera un meilleur travail de mise en cache contenu statique. La DB fera un bon travail aussi, mais si le DB est aussi traiter toutes sortes d'autres questions, ne vous attendez pas à ces gros documents rester caché longtemps. Vous essentiellement pour transférer le fichiers deux fois. Une fois de la DB à la Serveur Web, puis serveur Web pour client.

3. Contraintes de mémoire. Lors de mon dernier emploi, nous avions un fichier PDF de 40 Mo dans la base de données et continuions à obtenir Java OutOfMemoryErrors dans le fichier journal. Nous avons finalement réalisé que la totalité du fichier PDF de 80 Mo avait été lue dans le tas, pas seulement une fois, mais DEUX FOIS grâce à un réglage dans Hibernate ORM (si un objet est modifiable, il en fait une copie pour le montage en mémoire). Une fois que le fichier PDF a été renvoyé à l'utilisateur, le tas a été nettoyé, mais il était très difficile d'extraire immédiatement 80 Mo du tas simplement pour diffuser un document. Connaissez votre code et l'utilisation de la mémoire!

Votre serveur Web devrait pouvoir traiter la plupart de vos problèmes de sécurité, mais si les documents sont petits et que la base de données n'est pas déjà surchargée, je ne vois pas vraiment de problème à les avoir dans la base de données. .

Answer 4

Je viens juste de commencer des recherches sur FILESTREAMing pour BLOB de SQL Server 2008 et je rencontre une énorme limitation (IMO) - cela ne fonctionne qu'avec une 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 pouvez pas lire / écrire les objets BLOB. De nombreux environnements d'application ne peuvent pas utiliser l'authentification Windows. Certainement pas dans des environnements hétérogènes.

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

Answer 5

Cet article couvre la plupart des problèmes. Si vous utilisez SQL Server 2008, vérifiez l’utilisation du nouveau type FILESTREAM décrit par Paul Randal ici .

Answer 6

Cela dépend du type de base de données. Oracle ou SQLServer? Soyez conscient d'un inconvénient: la restauration d'un seul document.

Answer 7

Désolé, la réponse que j'ai donnée était basée sur SQL Server. La partie maintenance n'est donc pas appropriée. Mais les entrées / sorties de fichiers sont réalisées au niveau matériel et toute base de données ajoute des étapes de traitement supplémentaires.

La base de données imposera une surcharge lors de la récupération du document. Lorsque le fichier est sur le disque, vous êtes aussi lent ou aussi rapide que les E / S sur le serveur. Vous devez certainement gérer votre méta dans une base de données, mais vous voulez en fin de compte utiliser l’UNC du fichier et indiquer à l’utilisateur la source et éloignez-vous.

Du point de vue de la maintenance et de l’administration, vous vous limitez à un réseau de stockage lorsque vous utilisez MS SQL Server. Des solutions telles que Documentum adoptent une approche différente avec un stockage simple sur le disque et vous permettent de mettre en œuvre une solution de stockage à votre guise.

MODIFIER

Permettez-moi de clarifier ma déclaration. Avec SQL Server, les options sont limitées lorsque vous dépassez la capacité de stockage physique de la boîte. C’est en fait l’une des grandes faiblesses de Sharepoint, qui vous empêche de connecter simplement un type de stockage réseau.

Answer 8

D'après ce que j'ai pu constater, stocker des fichiers de contenu sous forme de blobs, à la fois dans SQL Server et Oracle, fonctionne correctement avec une petite base de données et un faible nombre d'utilisateurs connectés. Le système ECM les sépare et utilise des services distincts pour la diffusion en continu de contenu. Selon la taille des fichiers, les ressources du serveur peuvent être affectées par la récupération simultanée de fichiers volumineux. L’archivage des bases de données contenant de grands ensembles de fichiers devient problématique en raison du temps nécessaire pour la restauration et de l’impossibilité de récupérer les documents de l’archive.

Si ces fichiers sont des enregistrements d'entreprise et qu'il s'agit d'une copie faisant autorité, vous pouvez rencontrer des problèmes de gestion de la conformité et de la conservation, en particulier si vous archivez les fichiers. De même, la recherche et le contrôle de version pourraient devenir un énorme problème pour l'avenir.

Vous voudrez peut-être étudier un système ECM avec une API, plutôt que de réinventer la roue.