Le stockage dans SharePoint

Il s’agit également des éléments de liste, de la structure des sites, des éléments système… tout un ensemble d’éléments qui sont nativement stockés dans les bases de contenu et prennent de plus en plus de place durant la vie d’un site.

L’augmentation de la taille des bases de contenu, des architectures / infrastructures et des usages de  SharePoint s’est donc naturellement accompagnée d’une évolution de la façon de stocker le contenu.

Dans MOSS 2007, le processus est simple : lorsqu’un utilisateur télécharge un fichier dans une bibliothèque, le fichier est stocké dans la base de données. Si par la suite il souhaite modifier ce fichier, c’est le fichier entier qui va transiter à travers le réseau, sur l’ensemble de la chaine utilisateur / Web Front End / Base de donnée, lors de l’ouverture du fichier puis lors de son enregistrement. Puis, quelle que soit la nature de la modification effectuée (modification du contenu ou simple modification des métadonnées), le fichier sera dupliqué dans la base de contenu.

Dans SharePoint 2010, l’implémentation du protocole Cobalt améliore un peu les choses. En effet, lorsque qu’un fichier est téléchargé dans une bibliothèque, une ligne est créée dans la table AllDocStreams pour gérer le BLOB associé à ce téléchargement. Ensuite, lorsqu’une modification est apportée (sur un document ouvert depuis SharePoint par un client Office), le différentiel des changements est envoyé sur le réseau lors de l’enregistrement. Si cela permet de gagner sur le trafic entre le client et le frontal Web, c’est cependant encore l’intégralité du fichier qui va être transmise entre ce dernier et le serveur de base de données : le fichier y sera également dupliqué.

En améliorant Cobalt pour SharePoint 2013, Microsoft introduit le « Shredded Storage », qui va permettre de morceler un fichier en plusieurs BLOBs au lieu d’un seul Chaque BLOB, stocké dans la table DocStreams, va contenir un identifiant numérique faisant référence au fichier d’origine. Lorsqu’une modification va être apportée, seul le BLOB sur lequel porte la modification va être mis à jour.

Ce qu’apporte techniquement ce mode opératoire est une diminution des opérations de lecture/écriture d’un facteur deux, plus une nette réduction du stockage.

Prenons un exemple concret pour comparer SharePoint 2010 et 2013 : un site avec une bibliothèque de documents, dans laquelle un unique document PowerPoint de 4468Ko est uploadé. J’édite ensuite ce document pour créer trois nouvelles versions en dupliquant à chaque fois le même slide. Ensuite, je regarde la taille de la base de contenu. Le tableau ci-dessous compile les résultats :

Que nous montrent ces mesures ? Tout d’abord qu’il n’y a aucune différence de traitement pour la première version du fichier téléchargé, en termes de volume de données, entre SharePoint 2010 et 2013. Ensuite, que les modifications enregistrées sur les versions sont traitées largement différemment, avec seulement 126Ko de données pour SharePoint 2013 contre 9216Ko pour SharePoint 2010.

On pourrait donc légitimement se demander si l’utilisation d’une solution RBS est toujours à étudier compte tenu de cette amélioration. Le fait est que les premières versions d’un fichier sont toujours aussi volumineuses : dans un scenario où SharePoint est beaucoup utilisé pour stocker du contenu plutôt que de collaborer activement sur des documents, les « gros » fichiers seront toujours présents en quantité non négligeable. Un autre point à prendre en considération est que, lors d’une migration vers SharePoint 2013, ce traitement n’est pas rétroactivement appliqué aux différentes versions d’un fichier migré.