Die zweitschönste Nebensache der Welt

Meine Tabelle zum Experimentieren mit der Venom-Komprimierung hat einige Design-Schwächen, die zu der überraschend hohen Kompressionsrate geführt haben.

Die Unachtsamkeit beim der Definition des Tabellen-Layouts lag darin, dass die meisten Spalten als char mit konstanter Länge vorgegeben wurden. Darunter sind Felder für die Aufnahme von Namens- und Adressdaten, deren Längen so gewählt wurde, dass der längste Nachname oder der längste Straßenname komplett aufgenommen werden konnte.

Damit wird viel Speicherplatz mit rechtsbündig auffüllenden Leerstellen verschwendet. Die Mehrzahl dieser Spalten sind mit weniger als 20% Sinn tragender Daten gefüllt. Ein Defizit, das durch die neue Zeilenkomprimerung ohne großen Aufwand gut kaschiert werden konnte.

Aber es geht doch auch anders, auf klassischem Weg: sorgfältigeres Design. So konsumiert z.B. eine als varchar(50) statt char(50) definierte Spalte im vorliegenden Fall 80% weniger Speicherplatz.

Zusammen mit entsprechenden Änderungen für Spalten mit stark unterschiedlich langen Zeichenketten ergibt das eine Reduktion der durchschnittlichen Zeilenlänge um 56% (select avgrowsize from sysibm.systables where name=tabellename). Für die absolute Größe der beiden Tabellen bedeutet das 244026 4K-Pages der Originaltabelle gegenüber 107541 Pages der Tabelle mit den geänderten Datentypen.

Manchmal macht eben eine Komprimierung per Hand noch vor Einsatz aufwändiger Algorithmen Sinn.