Stockage de 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 les suivantes:
- Doit être protégé du vol par une simple copie des répertoires, des fichiers, etc.
- Doit être sécurisé contre l'infection virale traditionnelle (infection du fichier physique)
- Doit être rapide pour récupérer
- Le référentiel ne doit pas être visible par les utilisateurs occasionnels (répertoires), etc.
J'ai décidé de stocker tous les documents (et les 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 et offre même quelques avantages supplémentaires. telles que l'enregistrement automatique des documents avec l'entité concernée, la recherche de contenu facile et rapide, la suppression de toutes sortes d'activités utilisateur relatives à l'ouverture et à la désignation des documents, 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 BLOBS et s’adapte exceptionnellement bien. L'environnement est multi-utilisateur.
Lorsque votre base de données devient de plus en plus grande, la sauvegarde devient de plus en plus difficile .... La restauration d'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 avec la sauvegarde du jeu de données.
Le principal inconvénient que j'entends souvent au sujet 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 y a une bonne référence (PDF) ici qui couvre les avantages et les inconvénients des blobs.
D'après mon expérience, voici quelques problèmes:
vitesse vs avoir des fichiers sur le système de fichiers.
la mise en cache. Le serveur Web IMO Fera un meilleur travail de mise en cache du contenu statique La base de données fera également un bon travail, mais si elle est également responsable de toutes les autres requêtes, Ne vous attendez pas à ce que les documents volumineux.__ restent en cache longtemps. Vous devez essentiellement transférer les fichiers .__ deux fois. Une fois de la base de données au serveur Web , Puis serveur Web au client
Contraintes de mémoire. Lors de mon dernier emploi, nous avions un fichier de 40 Mo PDF dans la base de données, et nous n'arrivions pas à obtenir Java OutOfMemoryErrors dans le fichier journal. Nous avons finalement réalisé que l'ensemble des 80 Mo PDF avait été lu dans le tas, pas une fois, mais DEUX FOIS grâce à un réglage dans Hibernate ORM (si un objet est mutable, il en copie une copie à éditer en mémoire). Une fois que le fichier PDF a été renvoyé à l’utilisateur, le segment de mémoire a été nettoyé, mais c’est un grand succès que de pouvoir extraire immédiatement 80 Mo du segment de mémoire simplement pour diffuser un document. Connaissez votre code et comment la mémoire est utilisée!
Votre serveur Web devrait pouvoir gérer 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.
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?
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.
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 devriez 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 l’écarter.
Du point de vue de la maintenance et de l’administration, vous vous limitez à un SAN 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 comme bon vous semble.
MODIFIER
Permettez-moi de clarifier ma déclaration - avec SQL Server, vous disposez d'options 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 que vous ne pouvez pas simplement attacher un type de stockage réseau.
D'après ce que j'ai pu constater, stocker des fichiers de contenu sous forme de blobs, 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 de 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é d'extraire des 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.