> Data > Compressez vos données

Compressez vos données

Data - Par Tyler Chessman et John Paul Cook - Publié le 24 juin 2010
email

Les .NET Framework pour étendre la puissance de SQL Server 2005.

Compressez vos données

Pendant des années, les développeurs ont été obligés de créer des solutions personnalisées afin de compresser les données avant de les stocker dans la base de données, puis de les décompresser après leur extraction. (Pour une présentation de la compression, lisez l’encadré « Compression: Notions fondamentales »). Le .NET Framework simplifie grandement ces tâches. La version 1.1 a apporté l’espace de nom java.util.zip, lequel propose des méthodes de compression et de décompression des données. Avec cette version du .NET Framework, vous pouvez, par exemple, créer des classes enveloppe afin d’appeler indirectement java.util.zip à partir de langages .NET tels que VB.NET et C#. Toutefois, le .NET Framework 2.0, qui fait partie intégrante de SQL Server 2005 et de Visual Studio 2005, propose l’espace de nom System.IO.Compression, dont les méthodes fournissent un moyen pratique pour compresser et décompresser les données.

L’espace de nom System.IO.Compression, disponible avec tous les langages .NET, inclut deux classes pour la compression et la décompression des données : DeflateStream et GZipStream. La première classe met en oeuvre l’algorithme DEFLATE (tel que défini dans la RFC (Request for Comments) 1951). La deuxième utilise le format gzip (défini dans la RFC 1952), lequel compresse un seul fichier et est également basé sur l’algorithme DEFLATE. Comme leurs noms le suggèrent, DeflateStream et GZipStream fonctionnement avec des flux de données. Ces flux ne sont pas simplement des séquences d’octets, il s’agit d’objets complets, avec des méthodes permettant de les manipuler.

Avant d’examiner nos exemples de programmes de compression, passons brièvement en revue les principales étapes de la création d’une application de compression. Premièrement, vous devez ajouter du code Imports Visual Basic ou du code C#, au moyen d’instructions pour les espaces de nom System.IO et System.IO.Compression :

‘ VB Imports statements
Imports System.IO _
‘ for Stream object
Imports System.IO.Compression _
‘ for DeflateStream and _ GZipStream

// C# code
using System.IO;
// for Stream object
using System.IO.Compression;
// for DeflateStream and GZipStream

(Remarque : Certaines parties du code sont écrites sur plusieurs lignes en raison de contraintes d’espace.)

Vous devez également employer le type de données SqlBytes, un type SQL Server natif, car un paramètre et une fonction retournent tous deux une valeur. SqlBytes fait parti du nouvel espace de nom System.Data.SqlType, lequel propose des classes pour les types natifs au sein de SQL Server 2005. D’après la documentation .NET, ces classes « fournissent une alternative plus rapide et plus sûre aux types de données proposés par le .NET [CLR] ». A titre d’avantage supplémentaire, les espaces de nom SqlType mettent en oeuvre l’interface INullable, qui leur permet de contenir une valeur null réelle. L’utilisation des types de données SQL Server natifs évite également les problèmes de conversion de types. Bien que vous puissiez employer les types courants .NET, tels que les tableaux d’octets (Byte array), au sein des fonctions SQLCLR, le moteur d’exécution (runtime) convertira implicitement les types .NET vers le SqlType correspondant. Ces conversions de type entraînent une légère baisse des performances et ouvrent la porte à de possibles erreurs de conversion. Par exemple, lorsque nous avons écrit la fonction CompressBytes pour la première fois, nous avons utilisé des tableaux d’octets. Après avoir déployé le code sur SQL Server 2005, nous avons réalisé que le runtime convertissait implicitement les tableaux d’octets en varbinary(8000). Cette conversion inopportune empêchait d’utiliser des documents de plus de 8 Ko.

Pour comprimer les données, vous devez créer une fonction de code géré définie par l’utilisateur (UDF) du type SqlBytes :

Public Shared Function _
CompressBytes(ByVal _
UncompressedBytes As _
SqlBytes) As SqlBytes

Vous employez à la fois un objet MemoryStream et un objet GZipStream pour le processus de compression, comme suit :

Dim outputStream As New _ MemoryStream
‘ Contains the _ compressed data
Dim zipStream As Stream _
‘ The zip stream used for _ compression zipStream = New GZipStream _ (outputStream, _ (CompressionMode.Compress) _
‘ instantiate

La fonction effectue la compression en appelant la méthode Write de l’objet GZipStream, laquelle écrit les octets compressés dans l’objet MemoryStream (outputStream). Comme vous pouvez le voir dans le bloc de code suivant, la méthode Write a besoin du nombre d’octets non compressés (cet aspect sera explicité un peu plus loin) :

zipStream.Write _ (UncompressedBytes.Value, _ 0, CInt(UncompressedBytes. _ Length))

Maintenant que les données compressées sont dans outputStream, il vous suffit de retourner les données à partir de la fonction :

Return New SqlBytes _ (outputStream.ToArray)

La compression des données est aussi simple que cela. Il en va quasiment de même pour la décompression. Vous utilisez la méthode Read de GZipStream pour décompresser les données. Comme avec la méthode Write, la méthode Read a besoin du nombre d’octets compressés qu’elle aura à traiter. Il nous est apparu qu’un suivi du nombre d’octets compressés et décompressés n’était pas pratique lors du développement d’une classe enveloppe de compression et de décompression générique. Nous sommes parvenus à la conclusion qu’il était plus approprié d’adopter une approche orientée blocs, dans laquelle nous compressons et décompressons un bloc d’octets à la fois, car elle s’affranchit des détails du suivi du nombre d’octets.

Téléchargez cette ressource

Livre blanc Sécurité et Stockage des documents

Livre blanc Sécurité et Stockage des documents

Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.

Data - Par Tyler Chessman et John Paul Cook - Publié le 24 juin 2010