Implémentation de la compression de lignes

  • Article

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Cet article résume la façon dont Moteur de base de données implémente la compression de lignes. 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. Les modifications d’application ne sont pas requises quand 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, leurs longueurs et leurs décalages. 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

NULL et 0 les valeurs de tous les types de données sont optimisées et ne prennent pas d’octets.

Comment la compression des lignes affecte le stockage

Le tableau suivant décrit comment la compression de lignes affecte les types existants dans SQL Server et Azure SQL Database. La table n’inclut pas les économies qui peuvent être réalisées à l’aide de 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 correspond à 1 octet, seuls 1 octets sont utilisés.
int Oui Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée en 1 octet, le stockage ne prend que 1 octet.
bigint Oui Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée en 1 octet, le stockage ne prend que 1 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 en 3 octets, le stockage ne prend que 3 octets. L’empreinte de stockage est exactement identique au 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 en 3 octets, le stockage ne prend que 3 octets. L’empreinte de stockage est exactement identique au 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 les chiffres après la virgule décimale. 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 les chiffres après la virgule décimale. 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 avec 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 avec 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 entières à l’aide de deux entiers de 2 octets et correspond au nombre de jours depuis 1900-01-01. Il n’existe aucun avantage de 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 (cas courant), 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 avec la date de base de 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. Cela représente la date de 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 de données entières à l’aide de 3 à 6 octets. Il existe différentes précisions qui commencent par 0 à 9 qui peuvent prendre 3 à 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. Comme dans le cas précédent, il est peu probable d’obtenir des économies.

Précision = 3. Octets = 4. Étant donné que les 3 premiers octets sont pris par 5AM, cette option réalise peu d’économies.

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 12 heures.

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 aucun changement dans le stockage pour la compression des lignes. Globalement, peu d'économies peuvent être attendues de la compression du type de données time .
datetime2 Oui Utilise la représentation de données entières à l’aide de 6 à 9 octets. Les 4 premiers octets représentent la date. Les octets pris par le temps dépendent de la précision de l’heure spécifiée.

La valeur entière représente le nombre de jours depuis 0001-01-01 lequel une limite supérieure de 12/31/9999 est supérieure. Pour représenter une date de l’année 2005, la compression prend 3 octets.

Il n’y a pas d’économies sur le temps, car il permet de 2 à 4 octets pour différentes précisions de temps. 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 Ressemble à datetime2, sauf qu’il y a 2 octets de fuseau horaire du format (HH:mm).

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

Pour les valeurs de fuseau horaire, la mm valeur peut être 0 pour 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. Le Moteur de base de données insère le même caractère de remplissage, 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. Le Moteur de base de données insère le même caractère de remplissage, 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. Il existe un compteur d’horodatage qui est conservé pour chaque base de données, et sa valeur commence à partir de 0. 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.

La compression Unicode 1 prend en charge les types de données nchar et nvarchar de longueur fixe. Les valeurs de données stockées hors ligne ou dans les 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 elles sont stockées en ligne.

2 Données hors ligne ne sont pas compressées lors de l’activation de la compression des données. Par exemple, un enregistrement XML supérieur à 8 060 octets utilise des pages hors ligne, qui ne sont pas compressées.

Contenu connexe