Stocker des Documents sous forme de Blobs dans une base de données - quels sont les inconvénients?
les exigences pour mon système de gestion de documents étaient:
- doit être protégé contre le vol par simple copie de répertoires, fichiers, etc.
- Doit être sécurisé contre les virus infection (infection de fichier physique)
- Doit être rapide pour récupérer
- le dépôt ne doit pas être visible par les utilisateurs occasionnels (répertoires) qui parcourent le site, etc.
j'ai décidé de stocker tous les documents (et les images scannées) comme des blobs dans le base de données et jusqu'à présent mon expérience est magnifique et la récupération de documents est aveuglément rapide aussi bien - il répond à tous les critères d'en haut et il ya même un couple d'avantages supplémentaires, tels que l'autoctorage des documents avec l'entité qu'il se rapporte, la saisie facile et rapide des contenus, la suppression de toutes sortes d'activités de l'utilisateur autour de l'ouverture et la dénomination des documents, etc. etc.
ma question Est: y a - t-il des risques ou des choses graves que j'ai négligés avec ce design et la mise en œuvre?
MODIFIER la Note: base de données PostgreSQL, poignées de GOUTTES très bien et échelles exceptionnellement bien. L'environnement est multi-utilisateurs.
8 réponses
quand votre DB devient de plus en plus grand il deviendra plus difficile de sauvegarder. Restaurer une sauvegarde d'une table avec plus de 100 Go de données n'est pas quelque chose qui vous rend heureux.
une autre chose qui se produit est que toutes les fonctions de gestion de la table deviennent de plus en plus lentes à mesure que l'ensemble de données croît.
Mais cela peut être surmonté en faisant votre table de données juste contenir 2 champs:
ID et BLOB.
extraire des données (par clé primaire) ne sera probablement qu'un problème de longue durée après avoir frappé un mur avec la sauvegarde de l'ensemble de données.
le principal inconvénient que j'entends souvent de l'utilisation de blobs est que, au-delà d'une certaine taille, le système de fichiers est beaucoup plus efficace pour stocker et extraire de gros fichiers. On dirait que vous avez déjà pris cela en compte par votre liste d'exigences.
il y a un bonne référence (PDF) ici qui couvre les avantages et les inconvénients de blobs.
D'après mon expérience, certains problèmes étaient les suivants:
ViTESSE vs avoir des fichiers sur le système de fichiers.
mise en cache. IMO le serveur web va faire un meilleur travail de mise en cache contenu statique. Le DB va faire bon travail aussi, mais si le DB est aussi la remise de toutes sortes d'autres requêtes, ne vous attendez pas à ces gros documents pour rester en cache pour longtemps. Vous essentiellement doivent transférer le fichiers deux fois. Une fois de la DB à la Serveur Web, puis serveur web de client.
contraintes de mémoire. Lors de mon dernier travail, nous avions un PDF de 40 Mo dans la base de données, et avons continué à obtenir Java OutOfMemoryErrors dans le fichier journal. Nous avons finalement réalisé que la totalité du PDF de 80 Mo a été lu dans le tas non seulement une fois, mais deux fois grâce à un réglage dans L'Orme D'hibernation (si un objet est mutable, il fait une copie pour l'édition en mémoire). Une fois que le PDF a été redirigé vers l'utilisateur, le tas a été nettoyé, mais il a été un grand succès de sucer 80Mo du tas à la fois 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 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, alors je ne vois pas vraiment de problème à les avoir dans la base de données.
je viens de commencer la recherche de fichiers SQL Server 2008 pour les BLOBs et j'ai rencontré une énorme limitation (IMO)--cela ne fonctionne qu'avec une sécurité intégrée. Si vous n'utilisez pas Windows Authentication pour vous connecter au serveur DB, vous êtes incapable de lire/écrire les BLOBs. 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 BLOBs doit exister. Quelles sont les pratiques exemplaires?
article couvre la plupart des questions. Si vous utilisez SQL Server 2008, vérifiez l'utilisation du nouveau type FILESTREAM comme discuté par Paul Randal ici.
cela dépend du type de base de données. Oracle ou SQLServer? Être conscient d'un inconvénient - la restauration d'un document unique.
désolé - la réponse que j'ai proposée était basée sur SQL Server, donc la partie maintenance n'est pas appropriée. Mais les entrées/sorties de fichiers sont effectuées au niveau matériel et toute base de données ajoute des étapes de traitement supplémentaires.
la base de données imposera des frais supplémentaires lors de la récupération du document. Lorsque le fichier est sur le disque, vous êtes seulement aussi longtemps que l'I/O sur le serveur. Vous devez certainement gérer votre meta dans une base de données, mais à la fin vous voulez L'UNC du fichier et pointer l'utilisateur à la source et de sortir de la voie.
du point de vue de la maintenance et de l'administration, vous vous limiterez à un SAN lorsque vous traitez avec MS SQL Server. Les Solutions comme Documentum adoptent une approche différente avec un stockage simple sur le disque et vous permet de mettre en œuvre une solution de stockage comme vous le souhaitez.
EDIT
Permettez - moi de clarifier ma déclaration-avec SQL Server vous avez des 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 n'importe quel type de stockage réseau.
de ce que j'ai expérimenté stocker des fichiers de contenu comme blobs, à la fois dans SQL Server et Oracle, fonctionne bien avec une petite base de données et avec un petit nombre d'utilisateurs connectés. Le système ECM les sépare et utilise des services distincts pour le contenu en continu. Selon la taille des fichiers, les ressources du serveur peuvent être affectées par la récupération simultanée de gros fichiers. Archiver des bases de données avec de grands ensembles de fichiers devient problématique en raison du temps de restaurer et de l'incapacité de récupérer les documents forment les archives.
si ces fichiers sont des documents d'entreprise, et qu'il s'agit de la copie faisant autorité des documents, vous pourriez avoir des problèmes de gestion de la conformité et de la conservation, surtout si vous archivez les fichiers. De plus, le contrôle de la recherche et de la version peut devenir un énorme problème à l'avenir.
vous voudrez peut-être étudier un système ECM avec une API quelconque, plutôt que de réinventer la roue.