Partager via

Implémentation de la compression de ligne

  • Article

S’applique à : SQL Server Base de données Azure SQL Azure SQL Managed Instance

Cet article récapitule la manière dont le moteur de base de données implémente la compression de ligne. Elle fournit des informations de base qui vous aideront à planifier l'espace de stockage dont vous avez besoin pour vos données.

L'activation de la compression modifie uniquement le format de stockage physique des données qui sont associées à un type de données, mais pas leur syntaxe ni leur sémantique. Aucune modification de l'application n'est requise lorsqu'une ou plusieurs tables sont activées pour la compression. Le nouveau format de stockage des enregistrements propose les améliorations suivantes :

  • Il réduit la charge mémoire des métadonnées qui est associée à l'enregistrement. Ces métadonnées sont des informations sur les colonnes, leur longueur et leur décalage. Dans certains cas, la charge mémoire des métadonnées peut être plus importante qu'avec l'ancien format de stockage.

  • Il utilise le format de stockage de longueur variable pour les types de données numériques (par exemple integer, decimalet float) et les types reposant sur le type numérique (par exemple datetime et money).

  • Il stocke les chaînes de caractères de longueur fixe en utilisant le format de longueur variable, mais sans stocker les caractères blancs.

Remarque

Les valeurs NULL et 0 de tous les types de données sont optimisées et n'occupent aucun octet.

Conséquences de la compression de ligne sur le stockage

La table suivante décrit comment la compression de ligne affecte les types existants dans SQL Server et base de données Azure SQL. Elle n'indique pas les économies qui peuvent être réalisées en utilisant la compression de page.

Type de données Le stockage est-il affecté ? Description
tinyint Non 1 octet est la quantité de stockage minimale nécessaire.
smallint Oui Si la valeur rentre dans 1 octet, 1 seul octet est utilisé.
int Oui Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée dans 1 octet, le stockage n'occupe qu'un seul octet.
bigint Oui Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée dans 1 octet, le stockage n'occupe qu'un seul octet.
decimal Oui Utilise uniquement les octets nécessaires, quelle que soit la précision spécifiée. Par exemple, si une valeur peut être stockée dans 3 octets, le stockage n’occupe que 3 octets. L’encombrement du stockage est exactement le même que le format de stockage vardecimal.
Numérique Oui Utilise uniquement les octets nécessaires, quelle que soit la précision spécifiée. Par exemple, si une valeur peut être stockée dans 3 octets, le stockage n’occupe que 3 octets. L’encombrement du stockage est exactement le même que le format de stockage vardecimal.
bit Oui La charge mémoire des métadonnées porte cette valeur à 4 bits.
smallmoney Oui Utilise la représentation des données de type entier sur un entier de 4 octets. La valeur monétaire est multipliée par 10 000 et la valeur entière résultante est stockée en supprimant tous les chiffres après la virgule. L'optimisation du stockage de ce type de données est semblable à celle des types de données entiers.
money Oui Utilise la représentation des données de type entier sur un entier de 8 octets. La valeur monétaire est multipliée par 10 000 et la valeur entière résultante est stockée en supprimant tous les chiffres après la virgule. Ce type a une plus grande plage que smallmoney. L'optimisation du stockage de ce type de données est semblable à celle des types de données entiers.
float Oui Les octets les moins significatifs comprenant des zéros ne sont pas stockés. La compressionfloat est principalement applicable aux valeurs non fractionnaires de la mantisse.
real Oui Les octets les moins significatifs comprenant des zéros ne sont pas stockés. La compressionreal est principalement applicable aux valeurs non fractionnaires de la mantisse.
smalldatetime Non Utilise la représentation des données de type entier sur deux entiers de 2 octets et correspond au nombre de jours écoulés depuis 1900-01-01. Il n’y a pas d’avantage à la compression de ligne pour la partie date de smalldatetime.

L'heure est le nombre de minutes depuis minuit. Les valeurs d'heure situées légèrement après 16h00 commencent à utiliser le deuxième octet.

Si un smalldatetime est utilisé uniquement pour représenter une date (ce qui est souvent le cas), l’heure est 0.0. La compression permet d'économiser 2 octets en stockant l'heure dans le format d'octet le plus significatif pour la compression de ligne.
datetime Oui Utilise la représentation des données de type entier sur deux entiers de 4 octets. La valeur entière représente le nombre de jours depuis la date de base du 1900-01-01. Les 2 premiers octets peuvent représenter jusqu'à l'année 2079. La compression permet toujours d'économiser 2 octets jusqu'à cette date. Chaque valeur entière représente 3,33 millisecondes. La compression épuise les 2 premiers octets dans les cinq premières minutes et a besoin du quatrième octet après 16h00. La compression permet donc d'économiser uniquement 1 octet après 16h00. Lorsque datetime est compressé comme tout autre entier, la compression permet d'économiser 2 octets dans la date.
date Non Utilise la représentation des données de type entier sur 3 octets. Ceci représente la date à compter du 0001-01-01. Pour les dates contemporaines, la compression de ligne utilise les 3 octets. Aucune économie n'est réalisée.
time Non Utilise la représentation des données de type entier sur 3 à 6 octets. Plusieurs précisions démarrent par un chiffre compris entre 0 et 9 et peuvent occuper entre 3 et 6 octets. L'espace compressé est utilisé comme suit :

Précision = 0. Octets = 3. Chaque valeur entière représente une seconde. La compression peut représenter l'heure jusqu'à 6h00 sur 2 octets, ce qui permet d'économiser potentiellement 1 octet.

Précision = 1. Octets = 3. Chaque valeur entière représente 1/10 seconde. La compression utilise le troisième octet avant 2h00. De petites économies sont ainsi réalisées.

Précision = 2. Octets = 3. Semblable au cas précédent, la réalisation d'économies est peu probable.

Précision = 3. Octets = 4. Dans la mesure où les 3 premiers octets sont occupés dès 5h00, peu d'économies sont réalisées par le biais de cette option.

Précision = 4. Octets = 4. Les trois premiers octets sont occupés dans les 27 premières secondes. Aucune économie n'est attendue.

Précision = 5, Octets = 5. Le cinquième octet sera utilisé après midi.

Précision = 6 et 7, Octets = 5. Ne réalise pas d'économies.

Précision = 8, Octets = 6. Le sixième octet sera utilisé après 3h00.

Il n'y a aucune modification dans le stockage pour la compression de ligne. Globalement, peu d'économies peuvent être attendues de la compression du type de données time .
datetime2 Oui Utilise la représentation des données de type entier sur 6 à 9 octets. Les 4 premiers octets représentent la date. Les octets occupés par la date dépendent de la précision de l'heure spécifiée.

La valeur entière représente le nombre de jours depuis le 0001-01-01, avec une date limite située au 31/12/9999. La représentation d'une date de l'année 2005 occupe 3 octets.

Aucune économie n'est réalisée sur les heures car 2 à 4 octets sont nécessaires pour différentes précisions d'heure. Par conséquent, pour une précision de l'heure à la seconde, la compression utilise 2 octets pour l'heure et occupe le deuxième octet après 255 secondes.
datetimeoffset Oui Similaire à datetime2, mais avec 2 octets de fuseau horaire au format (HH:mm).

Comme datetime2, la compression peut permettre d'économiser 2 octets.

Pour les valeurs de fuseau horaire, la valeur mm peut être 0 dans la plupart des cas. Par conséquent, la compression peut permettre d'économiser 1 octet.

Il n'y a aucune modification dans le stockage pour la compression de ligne.
char Oui Les caractères de remplissage à droite sont supprimés. Notez que le moteur de base de données insère le même caractère tampon quel que soit le classement utilisé.
varchar Non Aucun effet.
texte Non Aucun effet.
nchar Oui 1 Les caractères de remplissage à droite sont supprimés. Notez que le moteur de base de données insère le même caractère tampon quel que soit le classement utilisé.
nvarchar Non 1 Aucun effet.
ntext Non Aucun effet.
binary Oui Les zéros de droite sont supprimés.
varbinary Non Aucun effet.
image Non Aucun effet.
cursor Non Aucun effet.
timestamp / rowversion Oui Utilise la représentation des données de type entier sur 8 octets. Un compteur d'horodatage, dont la valeur commence à 0, est maintenu pour chaque base de données. Il peut être compressé comme toute autre valeur entière.
sql_variant Non Aucun effet.
uniqueidentifier Non Aucun effet.
table Non Aucun effet.
xml Non2 Aucun effet.
Types définis par l'utilisateur Non Représentés en interne sous la forme varbinary.
FILESTREAM Non Représentés en interne sous la forme varbinary.

1 La compression Unicode prend en charge les types de données de longueur fixe nchar et nvarchar. Les valeurs de données stockées hors ligne ou dans des colonnes nvarchar(max) ne sont pas compressées. La compression Unicode n’est pas prise en charge pour les données nvarchar(max), même si celles-ci sont stockées dans des lignes.

2 Les données hors ligne ne sont pas compressées lorsque la compression des données est activée. Par exemple, un enregistrement XML de plus de 8 060 octets utilise des pages hors ligne, qui ne sont pas compressées.

Contenu connexe