Considérations sur le lieu de stockage des documents - sur le serveur de fichiers ou dans la base de données ?

Question

Je dois prendre une décision concernant les documents téléchargés sur mon site web : Je peux soit les stocker sur mon serveur de fichiers quelque part, soit les stocker sous forme de blob dans ma base de données (MSSQL 2005). Si cela peut faire une différence pour la décision de conception, ces documents sont confidentiels et doivent bénéficier d'un certain degré de protection.

Les considérations auxquelles j'ai pensé sont les suivantes :

1. Le stockage sur le serveur de fichiers se traduit par un nombre HUUUUUUUGE de fichiers tous déversés dans un seul répertoire, et donc par un accès plus lent, à moins que je ne parvienne à trouver une définition sémantique raisonnable pour une structure arborescente de répertoires.
2. Par ailleurs, je suppose que le serveur de fichiers peut gérer la compression un peu mieux que la base de données... ou est-ce que je me trompe ?
3. Mon instinct me dit que la sécurité de la base de données est plus forte que celle du serveur de fichiers, mais je ne suis pas sûr que ce soit nécessairement vrai.
4. Je ne sais pas comment le fait d'avoir des téraoctets de blobs dans ma base de données affectera les performances.

J'aimerais beaucoup recevoir des recommandations à ce sujet. Merci de votre compréhension.

Answer 1

Dans SQL Server 2005, vous avez seulement le choix d'utiliser VARBINARY(MAX) de stocker les fichiers dans la table de la base de données ou de les conserver à l'extérieur.

L'inconvénient évident de les laisser en dehors de la base de données est que la base de données ne peut pas vraiment contrôler ce qui leur arrive ; ils peuvent être déplacés, renommés, supprimés.....

Serveur SQL 2008 introduit le FILESTERAM sur l'attribut VARBINARY(MAX) qui vous permet de laisser les fichiers en dehors de la table de la base de données, mais toujours sous le contrôle transactionnel de la base de données - par exemple, vous ne pouvez pas simplement supprimer les fichiers du disque, les fichiers font partie intégrante de la base de données et sont donc copiés et sauvegardés en même temps qu'elle. C'est très bien si vous en avez besoin, mais cela pourrait donner lieu à des sauvegardes énormes ! :-)

Le lancement de SQL Server 2008 a présenté quelques "meilleures pratiques" pour savoir quand stocker des données directement dans la base de données et quand utiliser FILESTREAM. Ces pratiques sont les suivantes :

• si la taille des fichiers est généralement inférieure à 256 Ko, la table de la base de données est la meilleure option.
• si les fichiers ont généralement une taille supérieure à 1 Mo, ou peuvent atteindre plus de 2 Go, FILESTREAM (ou dans votre cas : un simple système de fichiers) est le meilleur choix.
• pas de recommandation pour les fichiers situés entre ces deux marges

En outre, afin de ne pas nuire aux performances de vos requêtes, il est souvent judicieux de placer les fichiers volumineux dans une table distincte. Ne laissez pas ces énormes blocs faire partie des tables ordinaires que vous interrogez, mais créez plutôt une table distincte que vous n'interrogez que si vous avez vraiment besoin de ces mégaoctets de documents ou d'images.

Cela peut donc vous donner une idée du point de départ !

Answer 2

Je vous suggère fortement d'envisager la solution du système de fichiers. Les raisons en sont les suivantes :

• vous avez un meilleur accès aux fichiers (précieux en cas de débogage), ce qui signifie que vous pouvez utiliser les outils habituels basés sur la console
• vous pouvez rapidement et facilement tirer parti du système d'exploitation pour répartir la charge, par exemple en utilisant un système de fichiers distribué, en ajoutant une redondance via un RAID matériel, etc.
• vous pouvez utiliser les listes de contrôle d'accès du système d'exploitation pour faire respecter les autorisations.
• vous n'encombrez pas votre base de données

Si vous craignez que vos répertoires contiennent un grand nombre d'entrées, vous pouvez toujours créer un schéma de branchement, par exemple :

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

Answer 3

Il y a beaucoup de "ça dépend" derrière ce sujet populaire. Puisque vous dites que les documents sont sensibles et confidentiels, j'opterais d'emblée pour le stockage dans la base de données. Voici quelques raisons :

• Une sécurité potentiellement meilleure. Il est souvent plus facile de pirater un système de fichiers qu'une base de données.
• Meilleur contrôle du volume. Des milliers de fichiers dans un dossier peuvent mettre à rude épreuve un système d'exploitation, alors qu'une base de données peut accepter des millions de lignes dans une table sans sourciller.
• Amélioration de la recherche et de la numérisation. Ajoutez des colonnes de catégorisation lorsque vous chargez les données, ou essayez l'indexation plein texte pour numériser les documents eux-mêmes.
• Les sauvegardes peuvent être plus efficaces : il suffit d'ajouter une autre base de données à votre plan de sauvegarde, et vous êtes couvert (une fois que vous avez réglé les détails relatifs à l'espace, bien sûr). De plus, ces fichiers de sauvegarde constituent une couche supplémentaire d'obscurcissement pour quiconque tente de s'emparer de vos documents sensibles.
• SQL Server 2008 dispose d'options de compression des données qui peuvent s'avérer utiles dans ce cas. Cela, ou demander à l'application de le faire ? (Plus de sécurité grâce à l'obscurcissement, peut-être)

SQL Server 2008 dispose également du type de données filestream, qui peut s'avérer utile dans ce cas, mais je ne le connais pas suffisamment pour vous donner une recommandation dans votre situation.