SQL-Datenbanken

Wann sich Datenkomprimierung lohnt

Dr. Klaus Manhart hat an der LMU München Logik/Wissenschaftstheorie studiert. Seit 1999 ist er freier Fachautor für IT und Wissenschaft und seit 2005 Lehrbeauftragter an der Uni München für Computersimulation. Schwerpunkte im Bereich IT-Journalismus sind Internet, Business-Computing, Linux und Mobilanwendungen.

Tabellenkompression – Effekt Performance-Gewinn

Auch der Performance-Gewinn lässt sich nicht allgemein beziffern, sondern hängt von den Besonderheiten der Datenbank ab. Grundsätzlich gilt: Zum Komprimieren und Dekomprimieren der Daten braucht es einerseits CPU-Leistung. Andererseits müssen weniger Datenblöcke auf die Festplatten geschrieben und von dort geholt werden.

Die Trivadis-Studie beziffert die CPU-Belastung beim Schreiben genauer anhand einer Data-Warehouse-Beispielapplikation im Terabytebereich mit Tabellen bis zu 100 Millionen Zeilen. So wird durch Komprimierung bei Einfügeoperationen rund doppelt so viel CPU-Zeit benötigt wie ohne. Bei Änderungsoperationen beträgt der CPU-Bedarf etwa 40 Prozent mehr, bei Löschoperationen wird die CPU nicht zusätzlich belastet. Der IO-Bedarf verringert sich beim Einfügen und Löschen je nach Kompressionsfaktor um etwa 30 Prozent.

Ein Performance-Gewinn ergibt sich besonders beim Zugriff, also beim Lesen der komprimierten Daten. Die CPU wird hier kaum mehr belastet, die Abfrage-Performance verbessert sich laut Trivadis um etwa 10 Prozent. Doch es sind auch deutlich höhere Werte erzielbar.

Ein Projekt des IT-Dienstleisters Ordix AG hat beispielsweise gezeigt, dass die Antwortzeit in einer für Kompression gut geeigneten Tabelle deutlich sank. Für den Fall, dass die Daten vollständig von der Platte geladen werden mussten, reduzierte sich die Abfragezeit beispielsweise von 22 auf 5 Sekunden; für den Fall, dass sich die Daten schon im Puffer befinden, von 40 auf 33 Sekunden.

Ob eine Tabelle für Komprimierung gut geeignet ist, lässt sich anhand folgender Richtlinien prüfen.

  • Kandidaten für eine Komprimierung sind Tabellen mit vielen redundanten Informationen.

  • Dabei sollten die Daten mit Blockoperationen eingefügt werden.

  • Die Daten sollten weiter möglichst nur einmal geschrieben und dann nur noch gelesen werden.

Alle diese Kriterien werden idealerweise von Data-Warehouse-Datenbanken erfüllt. Nicht geeignet für Kompression sind Tabellen, bei denen die Daten über Einzeloperationen eingefügt oder durch Updates häufig verändert werden. Hier schadet die Kompression in ungünstigen Fällen mehr, als dass sie nützt. Auch auf indexorganisierte Tabellen ist das Kompressionsverfahren nicht anwendbar. Ärgerlich ist auch, dass die Struktur einer komprimierten Tabelle nicht mehr geändert werden kann.

Zur Startseite