ROW Compression ou PAGE Compression ?

Ces deux niveaux de compression sont complémentaires : il est tout à fait possible de mixer ces types de compressions, et de compresser une table en mode ROW et une autre en mode PAGE, voir même de compresser un ensemble de partitions en mode ROW, un autre ensemble en mode PAGE, et de ne pas compresser le reste de la table. On peut également imaginer avoir une table compressée en PAGE et ses index en ROW. Tous les scénarios sont possibles afin de s’adapter à une variété de situation la plus large possible.

Pour vulgariser le fonctionnement de la compression ROW, je dirais simplement que dans un premier temps les valeurs nulles ou à 0 n’occupent plus d’espace, et qu’ensuite, le moteur considère les champs de longueur fixe comme s’ils étaient des champs de longueur variable. Autrement dit, seuls les octets réellement utilisés dans un champ de longueur fixe occuperont de l’espace. Par exemple, une valeur 1 dans un type INT occupe 4 octets. Une fois compressée, cette valeur n’occupera plus qu’ 1 octet. En parallèle, un overhead de 4 bits par colonne est ajouté à la page afin de stoker la longueur des données dans la dite colonne.

La compression au niveau page quant à elle inclue la compression row, comme nous l’avons dit précédemment, mais ajoute un algorithme de compression des données sur la page entière. Cet algorithme se décompose en deux phases :

–    Traitements des préfixes de chaîne : le but est de positionner les préfixes de chaines de caractères redondants au sein d’une même colonne dans une zone réservée, la Compression Information (CI), située juste après l’entête de page, puis de remplacer tout ou partie de ce préfixe dans chaque ligne par sa référence présente dans la CI. Il y aura donc un préfixe de chaîne par colonne.

–    La deuxième phase consiste à appliquer le même type d’algorithme mais au niveau du corps même de la chaine et dans la page complète résultante de la compression par préfixe et non plus en se limitant à une simple colonne.

Ce niveau de compression sera donc plus consommateur de CPU que le mode ROW. Pour aller plus loin, je vous recommande la lecture de cet excellent article (court mais on ne peut plus clair !) pour mieux appréhender la mécanique de compression.

On le voit très bien, le taux de compression finalement obtenu dépendra directement des données contenues dans la table. Plus les données seront redondantes, plus la compression sera efficace. D’où la question : comment déterminer ce qu’il faut compresser ?