Options de stockage d'objets BLOB Lorsque des données structurées et semi-structurées peuvent facilement être stockées dans une base de données relationnelle, le choix de l'emplacement de stockage des données non structurées ou des données BLOB est plus compliqué. Lorsque vous décidez de l'emplacement de stockage des données BLOB, prenez connaissance des spécifications suivantes :
Performances : la façon dont les données vont être utilisées est un facteur essentiel. Si l'accès en continu est nécessaire, le stockage des données dans une base de données SQL Server peut être plus lent que le stockage externe dans un emplacement tel que le système de fichiers NTFS. Avec le stockage du système de fichiers, les données sont lues dans le fichier et transmises à l'application cliente (directement ou avec mise en mémoire tampon supplémentaire). Lorsque les données blob sont stockées dans une base de données SQL Server, elles doivent d'abord être lues dans la mémoire de SQL Server (le pool de mémoires tampons), puis être retransmises via une connexion cliente à l'application cliente. Cela signifie non seulement que les données passent par une étape de traitement supplémentaire, mais également que la mémoire de SQL Server est inutilement « polluée » par des données BLOB, ce qui peut entraîner d'autres problèmes de performances pour les opérations SQL Server.
Sécurité : les données sensibles dont l'accès doit être étroitement géré peuvent être stockées dans une base de données et la sécurité peut être contrôlée en utilisant les contrôles d'accès SQL Server habituels. Si les mêmes données sont stockées dans le système de fichiers, différentes méthodes de sécurité, telles que les listes de contrôle d'accès (ACL), doivent être implémentées.
Taille des données : selon l'étude mentionnée plus loin dans ce livre blanc, les objets blob d'une taille inférieure à 256 kilo-octets (Ko) (tels que des icônes de widget) sont mieux adaptés au stockage dans une base de données, et les objets blob d'une taille supérieure à 1 Mo sont plus adaptés au stockage en dehors de la base de données. Pour ceux dont la taille est comprise entre 256 Ko et 1 Mo, la solution de stockage la plus efficace dépend du rapport lecture/écriture des données et de la fréquence de « remplacement ». Le stockage des données BLOB uniquement dans la base de données (par exemple, en utilisant le type de données varbinary (max)) est limité à 2 gigaoctets (Go) par BLOB.
Accès du client : le protocole utilisé par le client pour accéder aux données SQL Server, tel qu'ODBC, peut ne pas être adapté aux applications telles que les fichiers volumineux de flux vidéo. Cela peut nécessiter le stockage des données dans le système de fichiers.
Sémantique transactionnelle : si les données BLOB possèdent des données structurées associées qui sont stockées dans la base de données, les modifications apportées aux données BLOB doivent respecter la sémantique transactionnelle de façon à ce que les deux ensembles de données restent synchronisés. Par exemple, si une transaction crée des données BLOB et une ligne dans une table de base de données, puis annule l'opération, la création des données BLOB doit être annulée, ainsi que la création de la ligne dans la table. Cela peut s'avérer très complexe si les données BLOB sont stockées dans le système de fichiers sans lien vers la base de données.
Fragmentation des données : les mises à jour et remplacements fréquents entraînent le déplacement des objets blob, dans les fichiers de base de données SQL Server ou dans le système de fichiers, en fonction de l'emplacement de stockage des données. Dans ce cas, si les objets blob sont volumineux, ils peuvent être fragmentés. (c.-à-d., ne pas être stockés dans une partie contiguë du disque). Cette fragmentation est plus aisément traitée à l'aide du système de fichiers qu'à l'aide de SQL Server.
Simplicité de gestion : une solution utilisant différentes technologies qui ne sont pas intégrées sera plus complexe et coûteuse à gérer qu'une solution intégrée.
Coût : le coût de la solution de stockage varie selon la technologie utilisée.
Les explications ci-dessus concernant la taille et la fragmentation reposent sur le document Microsoft Research intitulé Utiliser ou non des objets blob : stockage d'objets blob dans une base de données ou dans un système de fichiers ? (en anglais) (Gray, Van Ingen et Sears). Le document comporte davantage d'informations sur les compromis impliqués et peut être téléchargé à l'adresse suivante :
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
Il existe une multitude de solutions pour le stockage d'objets blob, chacune ayant des avantages et des inconvénients en fonction des spécifications ci-dessus. Le tableau suivant compare trois options communes pour stocker des données blob, notamment FILESTREAM, dans SQL Server 2008.
Point de comparaison
| Solution de stockage
| Serveur de fichiers/ Système de fichiers
| SQL Server (avec varbinary(max)
| FILESTREAM
| Taille maximale des objets blob
| Taille du volume NTFS
| 2 Go – 1 octet
| Taille du volume NTFS
| Performances de diffusion en continu des objets blob
| Excellente
| Médiocre
| Excellente
| Sécurité
| Listes de contrôle d'accès manuelles
| Intégrées
| Intégrées + automatiques
| Coût par Go
| Faible
| Élevé
| Faible
| Simplicité de gestion
| Difficile
| Intégrée
| Intégrée
| Intégration avec les données structurées
| Difficile
| Cohérence au niveau des données
| Cohérence au niveau des données
| Développement et déploiement d'applications
| Plus complexes
| Plus simples
| Plus simples
| Récupération suite à la fragmentation des données
| Excellente
| Médiocre
| Excellente
| Performances de petites mises à jour fréquentes
| Excellentes
| Modérées
| Médiocres
| Tableau 1 : Comparaison des technologies de stockage d'objets blob avant SQL Server 2008
FILESTREAM est la seule solution qui assure la cohérence transactionnelle des données structurées et non structurées, ainsi que la gestion intégrée, la sécurité, un faible coût et d'excellentes performances de diffusion en continu. Cela est possible en stockant les données structurées dans les fichiers de base de données et les données BLOB non structurées dans le système de fichiers, tout en maintenant la cohérence transactionnelle entre les deux banques de données. Des informations supplémentaires sur l'architecture FILESTREAM sont disponibles dans la section « Présentation de FILESTREAM » plus loin dans ce document.
|