Compression des données
Il s'agit de compresser les données à la volée, la perte en CPU consommé étant largement compensée par le gain en entrées sorties disque et en consommation RAM.
Cette fonctionnalité est disponible pour les différentes éditions à partir de SQL Server 2008. (SQL Server 2008R2 et SQL Server 2012)
Deux types de compression sont disponibles :
· Par ligne de table
· Par page
L'idée générale est de réduire les ios disque et la mémoire en consommant un peu de CPU; ce qui a du sens quand on sait que SQL Server est surtout ralenti par les accès disque.
La mise en oeuvre peut se faire au moyen d'un assistant de Management Studio ou de l'instrcution DDL ALTER TABLE.
ALTER TABLE NomTable
REBUILD
WITH (DATA_COMPRESSION = { NONE | ROW | PAGE} )
L'assistant se trouve dans le menu Table -> Stockage
Un des avantages de l'assistant est qu'il peut estimer le gain avant de lancer la compression :
La même table avec un algorithme au niveau page donnant :
Cette fois le gain est 23 Mo ce qui divise la table par deux ce qui est non négligeable.
Méthodes de compression par ligne
Compression des types de données entières
Le principe est de réduire le stockage au nombre d'octets minimum pour stocker le nombre; par exemple, le nombre 1 peut être stocké sur 1 octet, le nombre 549 sur 2 octets, etc.
Voici une table de ce type avant compression :
La page qui nous intéresse est la 1:89 :
La ligne 1 est visible dans le slot 0 :
Sans surprise, cette ligne occupe 22 octets (8 + 4 + 2 + 1 + les octets de NULL et les pointeurs)
De même la ligne 2 est visible dans le slot 1 :
Toujours 22 octets...
Insérons des null values pour toutes ces colonnes :
Le slot 2 fait toujours 22 octets !
Eh oui, en taille fixe les valeurs NULL prennent la place de leur type, un simple booléen donnant le fait que la colonne est NULL ou pas.
Appliquons maintenant la compression de type ligne sur cette table :
L'algorithme de compression a alloué des nouvelles pages ce qui ne me surprend guère, vu la complexité de l'opération au niveau des méta données.
Que sont devenus nos slots ?
Le slot 0 est passé de 22 octets à 9 : on est effectivement dans le cas le plus favorable !
Le slot 1 est passé de 22 octets à 14, ce qui reste tout de même appréciable !
On voit que les gains sont sur le bigint et le int et sans doute un peu de méta données moins nombreuses.
Le slot 3 , plein de valeurs NULL, passe également de 22 octets à 9 :
Conclusion
Le taux de compression sera d'autant plus intéressant si :
· Il y a beaucoup de petites valeurs par rapport au potentiel du type
· Il y a beaucoup d e NULL
