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.
ap127
Nachdem meine erste Zeilenkomprimierung einer Tabelle eine hohe Verdichtungsrate aufgrund suboptimalen Designs erbrachte, fragt sich nun, ob der Tabelle mit verbesserter Definition ein ähnlich hohes Sparpotenzial innewohnt. Natürlich konnte ich nicht
Aufgenommen: Dec 26, 15:07
Man kann eben nicht alles haben. Die gleichen Performance-Vergleiche, die ich für die Original-Tabelle und ihr komprimiertes Abbild durchgeführt habe, habe ich auf die beiden umdefinierten Tabellen angewandt. Ich konnte keinen signifikanten Unterschi
Aufgenommen: Dec 26, 22:34
Und hier ist die Theorie zur Praxis: DB2 Explain schätzt für das teuerste Test-Select auf die umdefinierte Tabelle in unkomprimierter bzw. komprimierter Form folgende den Aufwände: unkomprimiertzeilenkomprimiertGesamtaufwand111.757,9453125000 Ti
Aufgenommen: Dec 28, 11:59