Alternativ zur in Teil 1 vorgestellten Tabellenkompression bietet sich die Index Key Compression an. Auf dieses Verfahren treffen die Einschränkungen wie etwa die Nutzung nur bei Read-Only-Tabellen nicht zu. Zunächst mag man annehmen, dass die Kompression der Indextabellen wenig Platzeinsparung bringen könnte. Doch belegen beispielsweise in SAP-Systemen die Indizes rund ein Drittel des Speicherplatzes, sodass hier ein erhebliches Einsparpotenzial besteht.
Die Index Key Compression steht für B Tree Indizes und vor allem für indexorganisierte Tabellen (IOT) zur Verfügung. IOTs sind dadurch charakterisiert, dass es dort keine Zweiteilung in einen Indexbereich und einen Datenbereich gibt. Die Daten liegen gemeinsam mit dem Index in einem Segment. Im Unterschied zur normalen Tabelle mit Index gibt es in den Leaf-Blöcken des Indexbaums keine Zeiger auf die Daten, sondern die Datensätze selbst sind dort gespeichert – sortiert nach den Kriterien des Primärschlüssels.
Eine IOT bietet sich immer dann an, wenn die Spalten des Primärschlüssels einen deutlichen Anteil am gesamten Datensatz ausmachen, beispielsweise in einfachen Adressentabellen. Dann ist in vielen Fällen schon alleine durch die Verwendung einer IOT eine Platzersparnis gegenüber der Verwendung einer normalen Tabelle mit Index zu erwarten.
In SQL wird das Anlegen einer IOT über die Option ORGANIZATION INDEX initiiert:
CREATE TABLE tab-name (......) ORGANIZATION INDEX;
Dabei ist der Primärschlüssel zwingend notwendig, weil er das Ordnungskriterium für die Datensätze ist.
So funktioniert Index Key Compression
Die Index Key Compression beruht auf der Eliminierung von sich wiederholenden Schlüsselwerten in zusammengesetzten Schlüsseln. Zusammengesetzte Schlüssel in einem Index werden in einen Präfix- und Suffix-Teil untergliedert. Das Suffix repräsentiert dabei den eindeutigen Teil des Indexschlüssels.
Wiederholen sich Schlüsselwerte im Präfix-Teil des Index, werden sie nur einmal gespeichert und vom Suffix referenziert. Beide Teile befinden sich dabei im gleichen Datenblock. Dadurch wird eine Reduzierung der Index Leaf Pages erreicht und damit die Anzahl der I/O-Operationen bei einem Indexzugriff. Die folgende Grafik verdeutlicht das Prinzip:
In der nicht komprimierten IOT links sind die vollständigen Adressdatensätze gespeichert. Für die Key Compression werden die Spalten des Index – in der Abbildung rot – in Präfix und Suffix aufgeteilt. Die letzten beiden Spalten in der Tabelle links bilden dabei das Präfix (zum Beispiel Hamburg Nordenstrasse). Diese Indexteile sind nicht eindeutig. Die übrigen Spalten bilden das Suffix.
Bei der Key Compression werden nun Präfix und Suffix getrennt gespeichert. Mehrfach vorkommende Präfix-Teile werden dabei genau einmal gespeichert. Die Suffix-Einträge werden in einem Block zu allen Datensätzen abgespeichert. Im Beispiel sind die dritte und achte Zeile von oben die Präfix-Teile und die restlichen die Suffix-Teile. Aus der Tatsache, dass die Präfix-Einträge nur einmal gespeichert werden, ergibt sich die Platzersparnis – im Beispiel etwa 30 Prozent.
Index Compression einrichten
Bei der Index Key Kompression gibt es nicht die Einschränkung auf Blockoperationen wie bei der Tabellenkompression. Sie wird also bei jeder einzelnen Einfügeoperation angewendet.
Um eine komprimierte IOT zu generieren, muss man beim Erzeugen des Index die Option COMPRESS angeben. Hinter COMPRESS kann die Anzahl der Präfix-Spalten angegeben werden, die komprimiert werden:
CREATE INDEX ... ON t1(spalte1, spalte2, spalte3, spalte4) COMPRESS 2
Alternativ kann die komprimierte IOT gleich beim Anlegen der Tabelle erstellt werden:
CREATE TABLE .... ORGANIZATION INDEX COMPRESS 2
Die Umwandlung einer bestehenden IOT erfolgt mit dem Befehl:
ALTER TABLE tab-name MOVE COMPRESS 2;
Der umgekehrte Vorgang, die Umwandlung einer komprimierten IOT in eine normale IOT, erfolgt mit:
ALTER TABLE tab-name MOVE NOCOMPRESS;
Bei Durchführung der Kompression wird eine neue IOT mit der Eigenschaft COMPRESS angelegt. Danach erfolgt das Einfügen der Daten, das Löschen der alten IOT und das Umbenennen der neuen IOT.
Indexkompression – Effekt Speicherplatzreduktion
Auch bei der Index Key Compression hängen die Auswirkungen der Kompression von der jeweiligen Tabelle ab. Im Allgemeinen lohnt sich die Key Compression aber bei einem zusammengesetzten Primärschlüssel.
Konkret ist die Höhe der Kompressionsrate des Index abhängig von der richtigen Anzahl der komprimierten Spalten, den Werteausprägungen und der Anordnung der Spalten im Index. Höhere Komprimierungsraten können unter Umständen durch Umsortieren der Spalten im Index erreicht werden.
Wie groß die Platzersparnis konkret ist, und welches der optimale Parameter für die Kompression ist, lässt sich mit folgenden Befehlen herausfinden. Der erste Befehl analysiert den Index:
ANALYSE INDEX index-name VALIDATE STRUCTURE;
Die optimale Compress-Einstellung lässt sich durch Verifizieren der Spalten OPT_CMPR_COUNT herausfinden. OPT_CMPR_PCTSAVE liefert Angaben über die prozentuale Platzeinsparung aus der Tabelle INDEX_STATS.
Hier ein Beispiel:
SELECT name
opt_cmpr_count,
opt_cmpr_pctsave,
FROM index_stats;
Ein mögliches Ergebnis könnte folgender Output sein:
NAME OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
________ ______________ ________________
USR_ADDR 3 55
Der Output besagt, dass bei der Einstellung COMPRESS 3 eine Einsparung von 55 Prozent erzielt werden kann. Die ermittelten Werte für die Platzersparnis sind in der Regel sehr zuverlässig.
Indexkompression – Effekt Performancegewinn
Im Gegensatz zur Tabellenkompression unterscheidet sich das Einfügen von Daten in eine komprimierte IOT nur wenig von den Vorgängen ohne Kompression. Die CPU wird nicht zusätzlich belastet. Dadurch kann beim Einfügen von Massendaten durch die Platzersparnis sogar eine Verkürzung der Zeiten erreicht werden.
Ein Test des IT-Dienstleisters Ordix AG zeigt für eine Beispieltabelle eine Reduktion der Antwortzeiten für typische Abfragen um rund 50 Prozent bei Daten, die vollständig von der Festplatte geladen werden mussten. Bei Daten, die sich schon im Puffer befanden, reduzierten sich die Zeiten dagegen nur minimal.
Im Vergleich zur Tabellenkompression hat die Index Key Compression den Vorteil, dass sie sich praktisch nicht von der Verwendung einer IOT ohne Kompression unterscheidet. Bei der Tabellenkompression trifft dies nicht zu.
Die Key Kompression ist damit wesentlich einfacher zu handhaben als die Tabellenkompression. Entscheidend für den Einsatz der Key Compression sollte ausschließlich der Platzgewinn sein, den man durch die Kompression erreicht.
Weitere Kompressionstechniken
Indexkompression gibt es auch für Bitmap-Indizes, das sind Indizes aus Nullen und Einsen. Die Bezeichnung kommt daher, dass der Bitmap-Index Attribute in Form eines Bitmusters speichert.
Mit einem Bitmap-Index lassen sich mehrdimensionale Daten, wie sie in Data-Warehouse-Systemen üblich sind, sehr effizient indizieren. Der Bitmap-Index wird äußerst kompakt und platzsparend angelegt und bringt für bestimmte Queries deutliche Performance-Vorteile. Die Grafik veranschaulicht das Prinzip von Bitmap-Indizes.
Neben der Komprimierung der Daten in Datenbanken lassen sich auch Backups komprimieren. Oracle setzt hierfür den Recovery Manager (RMAN) und Data Pump ein.
Mit RMAN können Daten blockweise physisch gesichert werden. Im Fehlerfall lässt sich ein Recovery auf Datenbank-, Tablespace- oder Blockebene durchführen. Ab Oracle 10g werden mit RMAN nur die Blöcke gesichert, die auch tatsächlich Daten enthalten. Oracle 11g erlaubt optional die ZLIP-Kompression. Der Industriestandard steigert die Kompressionsrate um zusätzliche 40 Prozent und senkt so den Backup-Storage-Bedarf weiter ab.
Für den Export von Daten kann unter Oracle die Data Pump eingesetzt werden. Data Pump erhöht die Performance des Exports durch die Möglichkeit der Parallelisierung. Dabei kann der Grad der Parallelisierung „on demand“ gewählt werden. Die Daten werden dabei komprimiert, bevor sie auf die Platten geschrieben werden. Untersuchungen haben eine Platzeinsparung von etwa 75 Prozent gezeigt.
Unterstützte Kompressionstechnologien bei Datenbank-Anbietern
Die aktuellen Oracle-Datenbanken unterstützen alle vorgestellten Technologien. Das ist weiter nicht erstaunlich, weil viele der Verfahren erstmals in Oracle-Datenbanken implementiert wurden. Tabellenkompression wurde bereits mit Oracle 9/Release 2 eingeführt. Die Möglichkeit, Indizes zu komprimieren, gibt es seit Oracle 8i. In Oracle 11g wurde die bestehende Tabellenkompression um OLTP-Fähigkeiten erweitert.
Andere Datenbank-Systeme unterstützen ebenfalls Kompressionstechniken. Sie verwenden zum Teil aber modifizierte oder ganz andere Verfahren. IBM DB2 setzt beispielsweise bei Tabellen die sogenannte Value Compression (Wertkompression) und Row Compression (Zeilenkompression) ein.
Bei der Wertkomprimierung werden NULL-Werte und Daten der Länge 0 vom Typ VAR, BLOB und CLOB lediglich mit zwei bis drei Bytes gespeichert, die der internen Verwaltung dienen. Dadurch wird weniger Speicherplatz verbraucht als ohne Wertkomprimierung. Werte mit variabler Länge belegen ebenfalls weniger Platz, dafür wachsen aber alle anderen Datentypen um zwei Byte an.
Noch bessere Komprimierungsraten für DB2 liefert die Zeilenkomprimierung, die auch vom SQL-Server verwendet wird. Sie wird auf einzelne Zeilen in Datenbanken angewendet, basiert auf einem Wörterbuch und nutzt den Lempel-Ziv-Algorithmus. Dabei werden für die Komprimierung und Dekomprimierung von Daten symbolische Tabellen eingesetzt.
Von Vorteil ist diese Komprimierungsmethode allerdings nur, wenn sie auf Tabellen mit vielen Sätzen angewendet wird. Darüber hinaus sollte die Tabelle Zeilen mit sich wiederholenden Mustern enthalten. Im Gegensatz zur Value Compression verbraucht die Row Compression auch CPU-Leistung und benötigt eine zusätzliche Lizenz. Nähere Details zu Value und Row Compression finden Sie hier.
Effiziente Speicher- und Kompressionsverfahren von Datenbank-Systemen
Die folgende Tabelle gibt Ihnen einen Überblick, wie die vorgestellten Verfahren bzw. Modifikationen bei den Datenbank-Systemen DB2, MS SQL Server, MySQL, Oracle, PostgreSQL und SAP Max DB realisiert sind.
|
IBM DB2 |
Microsoft SQL Server |
MySQL |
Oracle |
PostgreSQL |
SAP MaxDB |
|
|
Unicode UTF-8: Effiziente Speicherung von Unicode-Zeichenketten |
ja |
SQL Server 2005/2008 unterstützt Unicode 3.2. SQL Server 2005 speichert Unicode-Daten mit UCS-2. |
nein |
ab 7.0 |
siehe TOAST |
7.7 teilweise, ab 7.8f vollständig |
|
Number Datentyp: Effiziente Speicherung von numerischen Daten z.B. durch variable Feldgrößen |
Neben numerischen Datentypen unterschiedlicher Länge (SMALLINT, BIGINT) mit DECIMAL und DECFLOAT auch Datentypen mit variabler Länge |
SQL Server 2005 unterstützt seit SP2 den Datentyp vardecimal(), der numerischer Werte mit variabler Länge ermöglicht |
nein bei 5.x; ja in MySQL 6.0 (FALCON Storage Engine) |
unterstützt von allen Oracle-Versionen |
siehe unter CREATE TYPE |
ja |
|
Table Compression: Komprimierung von redundanten Werten in Tabellen |
Drei Arten: Default-Wert-Komprimierung, NULL-Wert-Komprimierung, Row-Compression. |
SQL Server 2008 Enterprise Edition : Row Compression und Page Compression für Tabellen. Details finden Sie hier. |
ja (packed MyISAM-Tables, ARCHIVE-Engine, InnoDB-plugin) |
Für Data-Warehouse-Systeme ab 9i, OLTP-Unterstützung ab 11g |
New ALTER TABLE tabname ALTER COLUMN colname SET STORAGE controls TOAST storage, compression |
teilweise, auf Basis von Datentyp oder Attribut (ab 7.6) |
|
Index Compression: Eliminierung von redundanten Indexwerten |
Bei Indizes mit Duplikaten wird jeder Wert nur einmal gespeichert. |
SQL Server 2008 Enterprise Edition: Row Compression und Page Compression für Indizes. Details finden Sie hier. |
ja |
Ab 8.0 |
HOT (Heap Only Tupels) verhindert redundante Indexeiträge und gibt den Speicher von gelöschten Daten frei. Weiter Informationen hier. |
ja |
|
Bitmap-Index: Hochkomprimierte, persistente Bitmap-Indexes |
dynamisch komprimierte Bitmaps (Index-ANDing und Index-ORing) |
SQL Server verwendet sowohl Bitmap- wie Hash-Indizes. |
nein |
Ab 8.0 |
PostgreSQL unterstützt Bitmap-Indizes nur im Speicher während einer Abfrage |
nein |
|
Backup-Compression: Komprimierung von Backup-Dateien |
ja |
SQL Server 2008 Enterprise Edition unterstützt native Komprimierung von Backups. Details finden Sie hier. |
nein bei 5.x, aber mit ext. Tools (gzip) kombinierbar; ja (Online Backup in MySQL 6.0) |
ab 10g/11g |
mit pg_dump, nähere Infos hier. |
ja |
|
Export Compression: Komprimierung von Export-Dateien |
nein, aber mit ext. Tools (gzip) kombinierbar |
Das BCP Utility führt implizit eine Komprimierung durch. |
nein, aber mit ext. Tools (gzip) kombinierbar |
ab 11g |
mit pg_dump, nähere Infos hier. |
nein |
|
Weitere Kompressionstechnologien |
XML-Komprimierung, Tags werden über ein Dictionary komprimiert. |
in Planung |
COMPRESS() Stringfunktion, zlib-Kompression f. Client-/Server-Protokoll |
Komprimierung unstrukturierter Daten vom Typ XML, CLOB und BLOB |
TOAST, nähere Details hier. Infos zu TOAST in Deutsch finden Sie hier. |
nicht dokumentiert |
Fazit
Die Einsparung von Plattenplatz ist ein komplexes Thema mit vielen Aspekten. Neben Strategien für das sparsame Speichern von textuellen und numerischen Daten stehen heute vor allem Kompressionstechniken im Mittelpunkt.
Dabei gilt: Datenkompression ist kein Schweizer Taschenmesser und nicht für alle Datenbanken tauglich. Sie kann jedoch in geeigneten Fällen zu enormer Platzersparnis führen und die Performance von Datenbank-Applikationen erhöhen. Vor der Anwendung eines Kompressionsverfahrens sollte jedoch immer eine Analyse der Auswirkungen und der Ausführungszeiten von typischen Abfragen erfolgen.
Die beiden wichtigsten Kompressionsansätze sind die Tabellen- und Index-Key-Kompression. Die Index Key Kompression ist breiter anwendbar, eignet sich aber nur für indexorganisierte Tabellen. Tabellenkompression ist gut einsetzbar bei hoch redundanten Tabellen, wenn die Daten nur einmal geschrieben, nicht mehr geändert, aber oft gelesen werden.
Die zentrale Anwendung für Kompression, insbesondere Tabellenkompression, sind Data Warehouses. Dort bringt Komprimierung eine merkliche Einsparung von Diskspace und eine Verbesserung der Abfrage-Performance. (ala)