Dans l’une de mes missions récentes, mon client m’a demandé une solution pour réduire l’espace disque requis par la base de données de staging dans une charge de travail ETL. Cela m’a amené à étudier et comparer la fonctionnalité de compression de table de SQL Server. Dans cet article, je discuterai des aspects de stockage et de performance des tables compressées et non compressées.

Avant d’entrer dans les détails, il est important de noter que cet article suppose une compréhension de base de SQL Server et de ses fonctionnalités. Si vous êtes nouveau dans SQL Server, je vous recommande de vous familiariser avec les bases avant de continuer.

La compression de table dans SQL Server vous permet de réduire l’espace de stockage requis par vos tables en compressant les données. Cela peut être particulièrement utile dans les scénarios où l’espace disque est limité ou lorsqu’il s’agit de grandes quantités de données.

Pour ma preuve de concept (POC), j’ai utilisé un package SSIS avec deux flux de données. Les deux flux de données avaient la même structure de table et de fichier, mais l’un avait la compression de table activée tandis que l’autre ne l’avait pas. La table et le fichier contenaient environ 100 colonnes avec uniquement le type de données VARCHAR, car la POC était destinée à une base de données de staging pour contenir temporairement des données brutes provenant de fichiers plats.

La POC impliquait également de travailler sur la conversion des colonnes de sortie de la source de fichiers plats pour les rendre compatibles avec la structure de table SQL Server de destination. De plus, nous avons effectué la POC avec différentes tailles de fichiers pour identifier la valeur optimale de la taille du fichier. Cela nous a permis de comparer la compression et de trouver la taille de fichier optimale pour le processus ETL dans une seule POC.

Après avoir réalisé la POC, nous avons enregistré les résultats suivants:

• Économie d’espace: Une économie d’environ 87% d’espace a été réalisée avec la compression de table activée.
• Temps d’exécution d’écriture: Aucune différence significative n’a été observée entre les tables compressées et non compressées.
• Temps d’exécution de lecture: Une légère/négligeable différence a été observée. La requête SELECT simple a pris de 10 à 20 secondes de plus pour la table compressée, ce qui représente environ moins de 2% du temps d’exécution global. Étant donné l’espace disque significatif économisé, ce léger surcoût a été jugé acceptable dans notre charge de travail.

Il est important de noter que ces résultats sont spécifiques à notre charge de travail et peuvent varier en fonction de votre cas d’utilisation spécifique. Avant de mettre en œuvre la compression dans votre environnement, il est recommandé d’examiner attentivement votre cas et de prendre en compte les avantages et les compromis potentiels.

En conclusion, la compression de table dans SQL Server peut être une fonctionnalité précieuse pour réduire les besoins en espace disque dans les charges de travail ETL. Elle offre des avantages significatifs en termes d’économie d’espace avec un impact minimal sur les temps d’exécution d’écriture et de lecture. Cependant, il est crucial d’évaluer votre charge de travail spécifique et de prendre en compte les compromis potentiels avant de mettre en œuvre la compression.

Merci de votre lecture! Si vous avez des questions ou si vous souhaitez partager vos expériences avec la compression de table dans SQL Server, n’hésitez pas à laisser un commentaire ci-dessous.