> Uncategorized > Quelles données compresser ?

Quelles données compresser ?

Uncategorized - Par iTPro - Publié le 14 mars 2013

Maintenant que nous savons comment le moteur applique la compression, nous pouvons passer à l’étape suivante qui consiste à définir ce que nous pouvons compresser.

Deux éléments majeurs sont à prendre en compte : l’impact potentiel sur les performances et le gain en espace disque espéré.

Impact sur les performances

Nous devons comprendre quand la donnée est décompressée pour mesurer à quel moment la compression aura un impact négatif sur les performances. La donnée n’est décompressée que lorsque qu’elle prend part à un ordre de tri (ORDER BY), à un filtre (WHERE), à un pivot de jointure (JOIN) ou encore lorsqu’elle est modifiée. Dans les autres cas, les données restent compressées. Plusieurs conclusions concernant les performances se posent dès lors :

-    Les données lues sur disque et chargées en mémoire sont compressées : l’impact sur les performances sera positif car moins d’IO physiques seront générées, moins de pages étant lues.

-    Qui plus est, les données restent compressées en mémoire (sauf dans les cas précédemment évoqués) ce qui nous autorise à imaginer moins de lecture logique et donc moins de consommation CPU. Cette baisse de la consommation de CPU peut même dans certain cas contre balancer l’augmentation de la consommation  générée par les opérations de compression / décompression.

-    En revanche, l’impact sera négatif dès que le moteur devra décompresser la données pour la traiter avant de la recompresser pour la stocker, sur les opérations d’UPDATE par exemple, ou sur les requêtes complexes, multipliant les jointures.

-    Et donc, à partir de ces conclusions, on privilégiera la compression sur les données massivement accédées (scan de table générant beaucoup d’IO, activité de reporting etc..) et très peu modifiées.

Nous avançons : nous savons maintenant comment choisir les données à compresser : reste à les trouver. En effet, d’après ma propre expérience, nous autres DBA ne connaissons pas toujours le type de données contenu dans nos bases, et la façon dont elles sont utilisées. Heureusement, nous allons être aidés dans notre tâche par les DMV, qui vont nous aider à déterminer le type d’accès effectuées sur les tables & index de notre base. En effet, la Dmv sys.dm_db_operationnal_stats tient des statistiques d’accès aux tables et index d’une base de données. Grâce à elle, nous allons pouvoir définir la cartographie des accès qui sont fait sur nos tables, en séparant les update des select, voir en identifiant les tables scan. Il sera alors facile de dresser la liste des tables étant essentiellement accédées en lecture, qui font l’objet de scan, et qui seront donc candidates à la compression.

Attention néanmoins, gardons à l’esprit certain type de données n’autorise pas la compression : d’être exhaustif, je vous renvoie vers cet article qui liste les effets de la compression pour chaque type de données.

Gains attendus

Nous avons maintenant la liste des tables candidates à la compression. Je rappel quand même que l’objectif premier est bien évidemment de réduire l’espace disque nécessaire au stockage de ces données. A ce stade, il serait bon d’avoir une estimation du gain espéré, d’autant plus que le taux de compression obtenu dépend essentiellement, on l’a vu précédemment, des données elles-mêmes. Là encore, nous ne sommes pas dépourvus. Nous allons être aidés par une procédure stockée : sp_estimate_data_compression_savings (je vous laisse consulter la documentation en ligne quant à sa syntaxe).

Cette procédure stockée va en effet prendre un échantillon de données de la table ciblée en tempDB (la taille de l’échantillon correspondra à la totalité de la table si elle comporte 5000 pages ou moins, ou sera basée sur la formule de calcul suivante sinon :  100.0 * 5000 / used_page_count, avec  used_page_count le nombre total de pages utilisé dans la table. ), et va y appliquer le mode de compression souhaité. Son travail terminé, elle nous donnera l’espace occupé avant et après l’application de la compression pour l’échantillon ainsi qu’une estimation pour la table (ou l’index) dans sa totalité, basée sur une extrapolation du résultat obtenu sur l’échantillon.

Exemple :

Soit une table Catalog (10 millions de lignes, 4GB de données et 1GB d’index), contenant un index cluster et deux index non cluster. En appliquant la procédure stockée à la table dans son ensemble, pour les niveaux de compression ROW et PAGE, nous obtenons : figure 1 (voir Club Abonné).
 
Dans mon exemple, le taux de compression ROW obtenue n’est pas très élevé (5,5 %), ce qui sous entends que mes données sont correctement typées et qu’il n’y a pas beaucoup de valeur NULL. La compression au niveau PAGE est quant à elle beaucoup plus intéressante (37,3%) ce qui met en avant une certaine redondance dans les données.

Téléchargez gratuitement cette ressource

Guide de services Azure pour le développement d’applications

Guide de services Azure pour le développement d’applications

Ce guide détaille divers scénarios adaptés au cloud, et plus particulièrement au développement d'applications à l'aide des services de plateforme disponibles sur Microsoft Azure. Découvrez l'étendue de la plateforme Azure et de ses services et apprenez comment l’utiliser rapidement selon le type d’application.

Uncategorized - Par iTPro - Publié le 14 mars 2013