DB2 - Komprimierung nun auch auf Zeilenebene

In DB2 wurde mit der Komprimierungsmethode auf Zeilenebene eine neue Art der Komprimierung eingeführt [1]. Dies hat vor allem Auswirkungen auf die Performance und die Speicherkapazität. Dieser Artikel veranschaulicht die neue Methode und vermittelt einen Eindruck von deren Funktionalität.

Rückblick zu VALUE COMPRESSION

Bereits in früheren Versionen stellte DB2 eine Möglichkeit der Komprimierung für Datenbanktabellen zur Verfügung. Hierbei handelt es sich um die so genannte Wertkomprimierung (VALUE COMPRESSION).

Bei der Wertkomprimierung werden NULL-Werte und Daten der Länge 0 (vom Typ: VAR, BLOB, CLOB) lediglich mit 2 bzw. 3 Bytes gespeichert, die der internen Verwaltung dienen. Dadurch wird weniger Speicherplatz verbraucht als ohne Wertkomprimierung und der eigentliche Wert wird auf Platte geschrieben.

Ob ein Wert komprimiert wird, hängt somit von der Definition der jeweiligen Tabellenspalte ab. Die Wertkomprimierung ist daher einfach eine andere, kürzere Darstellung des internen Speicherformats.

create table kunde (
  kundennr int,
  name varchar(50),
  adresse varchar(100)
) value compression;

alter table kunde
  activate value compression;

alter table kunde
  deactivate value compression;

Beim Anlegen einer Tabelle wird diese Komprimierungsmethode aktiviert durch die Klausel VALUE COMPRESSION (siehe Abbildung 1). Eine nachträgliche Aktivierung oder Deaktivierung für bereits bestehende Tabellen erfolgt mittels einer ALTER TABLE-Anweisung (siehe Abbildung 2). Standardmäßig ist die Wertkomprimierung beim Anlegen einer Tabelle nicht aktiviert.

ROW COMPRESSION

Die Möglichkeit einer besseren Komprimierung bietet nun die so genannte Zeilenkomprimierung (ROW COMPRESSION), die auf einzelne Zeilen von Datenbanktabellen angewendet werden kann.

Die neue Komprimierungsmethode basiert auf einem Wörterbuch und nutzt den Lempel-Ziv (LZ) Algorithmus. Für die Komprimierung und Dekomprimierung von Daten werden intern symbolische Tabellen verwendet, die gemeinsame Sequenzen von aufeinanderfolgenden Bytes von Zeilen speichern. Dadurch muss ein mehrmals vorkommender Wert innerhalb einer Zeile nur einmal gespeichert werden und kann durch kürzere Zeichenfolgen ersetzt werden.

Von Vorteil ist diese Komprimierungsmethode also nur dann, wenn sie auf Tabellen mit vielen Sätzen angewendet wird. Darüber hinaus sollte die Tabelle Zeilen mit sich wiederholenden Mustern enthalten. Durch die Komprimierung wird die Anzahl der benötigten Datenseiten stark reduziert und Plattenspeicherplatz eingespart.

Die Einsparung, die durch ROW COMPRESSION erreicht werden kann, ist größer, als die Einsparung durch VALUE COMPRESSION. Beide Komprimierungsmethoden können auch gleichzeitig verwendet werden.

Die Daten liegen nach der Komprimierung sowohl auf der Festplatte als auch im Bufferpool in komprimierter Form vor. Daher können mehr Daten in den Bufferpool geladen werden. Der daraus resultierende Vorteil ist, dass weniger I/O-Operationen benötigt werden, um eine bestimmte Anzahl an Daten von der Platte in den Hauptspeicher zu laden.

Bei kleineren Tabellen sollte man allerdings aufpassen. Die Komprimierung muss nicht unbedingt zu einem schnelleren Abfrageergebnis führen, da die Komprimierung und Dekomprimierung selbst mit einem gewissen Aufwand verbunden ist. Somit könnte eine Abfrage mit Komprimierung länger laufen als ohne, da das Ergebnis der Abfrage vorher dekomprimiert werden muss.

ROW COMPRESSION aktivieren

create table kunde (
  kundennr int,
  name varchar(50),
  adresse varchar(100)
) compress yes;

alter table kunde
  compress yes;

alter table kunde
  compress no;

Um die Zeilenkomprimierung zu verwenden, muss diese für die entsprechende Tabelle aktiviert sein. Sofern dies nicht beim Anlegen einer Tabelle mit der CREATE TABLE-Anweisung geschehen ist (siehe Abbildung 3), kann diese Modifikation auch nachträglich mit der ALTER TABLE-Anweisung durchgeführt werden (siehe Abbildung 4).

Wird eine Tabelle ohne die Angabe compress yes/no erstellt, verwendet der Datenbankserver die Standardeinstellung compress no.

Das Wörterbuch

Wie bereits erwähnt, arbeitet die neue Komprimierungsmethode mit einem Wörterbuch. Dieses so genannte Komprimierungswörterbuch (COMPRESSION DICTIONARY) muss vom Datenbankadministrator erstellt und in regelmäßigen Abständen gepflegt werden. Sowohl für die Erstellung als auch für die Pflege steht der Befehl REORG TABLE zur Verfügung. Ursprünglich wurde REORG TABLE nur dazu benutzt, Tabellen zu reorganisieren. Für die ROW COMPRESSION wurde der Befehl nun um die folgenden Optionen erweitert:

• KEEPDICTIONARY
  Das ursprüngliche Wörterbuch wird beibehalten. Existiert noch kein Wörterbuch und compress ist für die Tabelle auf yes gesetzt, wird das Wörterbuch neu erstellt.
• RESETDICTIONARY
  Das ursprüngliche Wörterbuch wird neu erstellt. Ist compress auf no gesetzt, wird das bestehende Wörterbuch gelöscht.

-- Wörterbuch behalten oder erstellen
reorg table kunde keepdictionary;

-- Wörterbuch erstellen oder löschen
reorg table kunde resetdictionary;

Abbildung 5 zeigt den Aufruf von reorg table mit den jeweiligen Optionen.

Während der Erstellung des Wörterbuches wird ein temporärer Buffer von 10 MB für Zwischenspeicherungen im Hauptspeicher benötigt. Alle Datensätze, die sich zum Zeitpunkt der Reorganisation in der entsprechenden Tabelle befinden, nehmen an der Erstellung des Komprimierungswörterbuches teil. Das Wörterbuch selbst wird direkt in der Partition der dazugehörigen Tabelle gespeichert und benötigt eine Größe von ungefähr 74 KB.

Damit ein Wörterbuch letztendlich auch verwendet wird und eine Komprimierung von Zeilen erfolgen kann, muss ROW COMPRESSION für eine Tabelle aktiviert sein (siehe: ROW COMPRESSION aktivieren).

Einschränkungen

Ob ROW COMPRESSION auf den Inhalt einer Spalte angewendet werden kann, ist vom jeweiligen Datentyp abhängig. XML-, LOB-, LF- und Index-Objekte können nicht komprimiert werden.

Systemtabellen

Mit Einführung der Zeilenkomprimierung ist die Systemtabelle sysibm.systables um die Spalte COMPRESSION erweitert worden. Anhand des Wertes dieser Spalte kann festgestellt werden, welche Art der Komprimierung für eine Datenbanktabelle verwendet wird (siehe Abbildung 6). Die möglichen Werte für die Spalte COMPRESSION sind:

• N keine Komprimierung
• V Wertkomprimierung
• R Zeilenkomprimierung
• B Wert- und Zeilenkomprimierung

SELECT TABNAME, COMPRESSION
  FROM sysibm.systables
 WHERE TABNAME = 'KUNDE';

NAME                COMPRESSION
------------------- -----------
KUNDE               R

   1 record(s) selected.

Select tabname, npages
  from syscat.tables
  where tabname = 'KUNDE';

Die Informationen bezüglich der Komprimierung können anstelle der Systemtabelle sysibm.systables auch über die View syscat.tables des Systemkataloges abgerufen werden. Die Syntax entspricht der des Beispiels aus Abbildung 6, wobei allerdings sysibm.systables durch syscat.tables ersetzt werden muss.

Auch um die Anzahl der Datenseiten einer Tabelle zu ermitteln, kann man eine SQL-Abfrage gegen die View syscat.tables ausführen. Interessant ist hier die Spalte NPAGES (siehe Abbildung 7). Dabei sollte allerdings darauf geachtet werden, zuvor das runstat-Kommando auszuführen, um die Statistiken der Systemtabellen zu aktualisieren.

INSPECT

Mit Hilfe des INSPECT-Kommandos können die Struktur und die Konsistenz von Datenbanken, Tablespaces und Tabellen überprüft werden. Dabei betrachtet das Werkzeug die Datenseiten. Ab der Version 9 ist das Kommando um die Option ROWCOMPESTIMATE erweitert worden. Der Datenbankadministrator kann damit zunächst eine Schätzung abgeben, ob sich für eine Tabelle die Zeilenkomprimierung rentiert oder nicht.

Die Daten, die durch das INSPECT-Kommando gesammelt werden, liegen vorerst in binärer Form vor und werden in einer Datei im Home-Verzeichnis des Instanzeigentümers unter sqllib/db2dump gespeichert. Um ein lesbares Ergebnis zu bekommen, muss im nächsten Schritt mit dem Befehl db2inspf die binäre Ausgabedatei analysiert werden (siehe Abbildung 8).

db2 inspect rowcompestimate table name kunde results keep result.out
db2inspf /home/db2/sqllib/db2dump/result.out analyse.out

cat analyse.out

Action: ROWCOMPESTIMATE TABLE
Schema name: DB2
Table name: KUNDE
Tablespace ID: 2 Object ID: 4
Result file name: result.log

Table phase start (ID Signed: 4, Unsigned: 4; Tablespace ID: 2) : DB2.KUNDE

Data phase start. Object: 4 Tablespace: 2
Row compression estimate results:
Percentage of pages saved from compression: 21
Percentage of bytes saved from compression: 21
Percentage of rows ineligible for compression due to small row size: 0
Compression dictionary size: 1792 bytes.
Expansion dictionary size: 2224 bytes.
Data phase end.
Table phase end.
Processing has completed. 2007-06-13-08.33.12.876228

Fazit

Die neue Komprimierungsmethode ist neben der bereits bestehenden eine gute Möglichkeit, um die Größe einer Datenbank zu minimieren. Ob und inwieweit sich eine Komprimierung allerdings lohnt, ist abhängig von der jeweiligen Tabelle (Größe, Schema, Inhalte), die komprimiert werden soll. Es ist auf jeden Fall zu empfehlen, sich die Tabellen vor der Verwendung der Komprimierung etwas genauer anzuschauen, um nicht eventuell einen negativen Effekt zu erzielen.

Thorsten Schuhmacher (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen