> Tech > Le stockage dans SharePoint

Le stockage dans SharePoint

Tech - Par iTPro - Publié le 12 juin 2014
email

Le contenu, dans SharePoint, n’est pas limité aux seuls documents qui peuvent être stocké dans l’outil.

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 :

 

Version

Bibliothèque dans SharePoint 2010 (Ko)

Bibliothèque dans SharePoint 2013 (Ko)

Taille initiale de la DB

23 616

38 976

Taille après upload du fichier

28 736

44 096

Taille après enregistrement de trois  versions

37 952

45 120

Delta fichier original

5 120

5 120

Delta après enregistrement des versions

9 216

126

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é.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 12 juin 2014