Kompressionskodierungen

Die Rohkodierung ist die Standardkodierung für Spalten, die als Sortierschlüssel identifiziert sind, und für Spalten, die als die Datentypen BOOLEAN, REAL oder DOUBLE PRECISION definiert sind. Bei einer Rohkodierung werden die Daten in roher, nicht komprimierter Form gespeichert.

AZ64 ist Amazons eigener Komprimierungscodierungsalgorithmus, der dazu dient, ein hohes Komprimierungsverhältnis zu erzielen und die Abfrageleistung zu verbessern. Im Kern komprimiert der AZ64-Algorithmus kleinere Gruppen von Datenwerten und verwendet SIMD- (Single Instruction, Multiple Data) Anweisungen für die parallele Verarbeitung. Verwenden Sie AZ64 für deutliche Speicherplatzeinsparungen und hohe Leistung bei numerischen, Datums- und Uhrzeitdaten.

Sie können AZ64 als Komprimierungscodierung bei der Definition von Spalten mit den Anweisungen CREATE TABLE und ALTER TABLE für die folgenden Datentypen verwenden:

Bei einer Byte-Verzeichnis-Kodierung wird für jeden Block von Spaltenwerten auf dem Datenträger ein getrenntes Verzeichnis eindeutiger Werte erstellt. (Ein Amazon-Redshift-Datenträgerblock belegt 1 MB.) Das Verzeichnis enthält bis zu 256 Einzelbyte-Werten, die als Indizes für die ursprünglichen Datenwerte gespeichert werden. Wenn in einem einzelnen Block mehr als 256 Werte gespeichert werden, werden die zusätzlichen Werte in roher, nicht komprimierter Form in den Block geschrieben. Dieser Vorgang wird für jeden Datenträgerblock wiederholt.

Diese Kodierung ist bei Zeichenfolgenspalten mit niedriger Kardinalität sehr effektiv. Diese Kodierung ist optimal, wenn die Datendomäne einer Spalte weniger als 256 eindeutige Werte enthält.

Für Spalten mit dem Zeichenfolgendatentyp (CHAR und VARCHAR), die mit BYTEDICT codiert sind, führt Amazon Redshift vektorisierte Scans und Prädikatauswertungen durch, die direkt über komprimierte Daten arbeiten. Diese Scans verwenden hardwarespezifische Anweisungen des Typs Single Instruction and Multiple Data (SIMD) für die parallele Verarbeitung. Dadurch wird das Scannen von Zeichenkettenspalten erheblich beschleunigt. Byte-dictionary Die Kodierung ist besonders platzsparend, wenn eine CHAR/VARCHAR Spalte lange Zeichenketten enthält.

Angenommen eine Tabelle besitzt eine Spalte COUNTRY mit einem Datentyp CHAR(30). Während die Daten geladen werden, erstellt Amazon Redshift das Verzeichnis und füllt die Spalte COUNTRY mit dem Indexwert aus. Das Verzeichnis enthält die indizierten eindeutigen Werte. Die Tabelle selbst enthält nur die Einzelbyte-Subskripts der entsprechenden Werte.

Die folgende Tabelle stellt das Verzeichnis für die Spalte COUNTRY dar.

Die folgende Tabelle stellt die Werte in der Spalte COUNTRY dar.

Die gesamte komprimierte Größe in diesem Beispiel wird wie folgt berechnet: Im Verzeichnis sind 6 verschiedene Einträge gespeichert (6 * 30 = 180) und die Tabelle enthält 10 komprimierte Werte mit 1 Byte. Dies sind insgesamt 190 Bytes.

Delta-Kodierungen sind für Datum-/Uhrzeitspalten sehr nützlich.

Bei der Delta-Kodierung werden Daten komprimiert, indem der Unterschied zwischen Werten aufgezeichnet wird, die in der Spalte aufeinander folgen. Dieser Unterschied wird für jeden Block von Spaltenwerten auf dem Datenträger in einem getrennten Verzeichnis aufgezeichnet. (Ein Amazon-Redshift-Datenträgerblock belegt 1 MB.) Angenommen, die Spalte enthält 10 ganze Zahlen in der Reihenfolge zwischen 1 und 10. Die ersten werden als 4-Byte-Ganzzahl (plus ein 1-Byte-Flag) gespeichert. Die nächsten neun werden jeweils als Byte mit dem Wert 1 gespeichert, was darauf hinweist, dass es um eins größer als der vorherige Wert ist.

Die Delta-Kodierung besitzt zwei Varianten:

Wenn die meisten Werte in der Spalte unter Verwendung eines einzelnen Bytes komprimiert werden könnten, ist die 1-Byte-Variante sehr effektiv. Wenn die Unterschiede größer werden, ist diese Kodierung schlimmstenfalls etwas weniger effektiv als das Speichern der nicht komprimierten Daten. Eine ähnliche Logik gilt für die 16-Bit-Version.

Wenn der Unterschied zwischen zwei Werten den 1-Byte-Bereich (DELTA) oder den 2-Byte-Bereich () überschreitet, wird der ursprüngliche Wert vollständig wiederhergestellt. Ihm wird ein 1-Byte-Flag vorangestellt. Der 1-Byte-Bereich liegt zwischen -127 und 127. Der 2-Byte-Bereich liegt zwischen -32000 und 32000.

Die folgende Tabelle zeigt, wie eine Delta-Kodierung für eine numerische Spalte funktioniert:

Die LZO-Kodierung stellt ein sehr hohes Kompressionsverhältnis mit guter Leistung bereit. Die LZO-Kodierung funktioniert besonders gut für CHAR- und VARCHAR-Spalten, die sehr lange Zeichenfolgen speichern. Sie eignet sich besonders gut für Freiformtexte wie Produktbeschreibungen, Benutzerkommentare oder JSON-Zeichenfolgen.

Mostly-Kodierungen sind nützlich, wenn der Datentyp für eine Spalte größer ist, als es die meisten gespeicherten Werte erfordern. Durch die Angabe einer Mostly-Kodierung für diese Art von Spalten können Sie die Mehrzahl der Werte in der Spalte zu einer kleineren Standardspeichergröße komprimieren. Die übrigen Werte, die nicht komprimiert werden können, werden in ihrer rohen Form gespeichert. Sie können beispielsweise eine 16-Bit-Spalte wie eine INT2-Spalte zu einer 8-Bit-Speichergröße komprimieren.

Im Allgemeinen funktionieren Mostly-Kodierungen mit den folgenden Datentypen:

Wählen Sie die Variante der Mostly-Kodierung, die der Größe des Datentyps für die Spalte am besten entspricht. Sie können beispielsweise MOSTLY8 auf eine Spalte anwenden, die als 16-Bit-Ganzzahlspalte definiert ist. Die Anwendung von MOSTLY16 auf eine Spalte mit einem 16-Bit-Datentyp oder MOSTLY32 auf eine Spalte mit einem 32-Bit-Datentyp ist nicht zulässig.

Mostly-Kodierungen sind möglicherweise weniger effektiv als keine Kompression, wenn eine vergleichsweise große Zahl der Werte in der Spalte nicht komprimiert werden kann. Bevor Sie eine dieser Kodierungen auf eine Spalte anwenden, führen Sie eine Überprüfung durch. Die meisten Werte, die Sie jetzt (und wahrscheinlich in der Zukunft) laden, sollten in die in der folgenden Tabelle gezeigten Bereiche passen.

Die Spalte VENUEID in der Tabelle VENUE ist beispielsweise als nicht komprimierte Ganzzahlspalte definiert. Das bedeutet, dass ihre Werte 4 Bytes Speicher verbrauchen. Der aktuelle Bereich von Werten in der Spalte ist 0 bis 309. Daher würde der Speicherplatz für jeden Wert in dieser Spalte auf 2 Bytes reduziert werden, wenn diese Tabelle mit MOSTLY16-Kodierung für VENUEID neu erstellt und geladen würde.

Wenn die VENUEID-Werte, die in einer anderen Tabelle referenziert werden, überwiegend zwischen 0 und 127 liegen, wäre es sinnvoll, diese Fremdschlüsselspalte als MOSTLY8 zu kodieren. Bevor Sie diese Wahl treffen, führen Sie mehrere Abfragen für die referenzierenden Tabellendaten aus, um festzustellen, ob die Werte überwiegend im 8-Bit-, 16-Bit- oder 32-Bit-Bereich liegen.

Die folgende Tabelle zeigt komprimierte Größen für spezifische numerische Werte, wenn die MOSTLY8-, MOSTLY16- und MOSTLY32-Kodierungen verwendet werden:

Die Run-length-Kodierung ersetzt einen Wert, der in Folge wiederholt wird, durch ein Token, das aus dem Wert und einer Zahl für die Anzahl der Wiederholungen in Folge (der Länge des Laufs) besteht. Für jeden Block von Spaltenwerten auf dem Datenträger wird ein getrenntes Verzeichnis eindeutiger Werte erstellt. (Ein Amazon-Redshift-Datenträgerblock belegt 1 MB.) Diese Kodierung ist am besten für eine Tabelle geeignet, in der Datenwerte häufig in Folge wiederholt werden, beispielsweise, wenn die Tabelle nach diesen Werten sortiert ist.

Angenommen, eine Spalte in einer großen Dimensionstabelle hat eine vorhersehbare kleine Domäne, wie eine COLOR-Spalte mit weniger als 10 möglichen Werten. Diese Werte werden wahrscheinlich in langen Sequenzen in der gesamten Tabelle angezeigt, auch wenn die Daten nicht sortiert sind.

Es wird nicht empfohlen, die Lauflängenkodierung auf Spalten anzuwenden, die als Sortierschlüssel vorgesehen sind. Range-restricted Scans schneiden besser ab, wenn Blöcke eine ähnliche Anzahl von Zeilen enthalten. Wenn Sortierschlüsselspalten sehr viel stärker als andere Spalten in derselben Abfrage komprimiert werden, zeigen Scans mit eingeschränkten Bereichen möglicherweise eine schlechte Leistung.

In der folgenden Tabelle wird die Spalte COLOR verwendet, um zu zeigen, wie die Run-length-Kodierung funktioniert:

Text255- und Text32k-Kodierungen sind für die Komprimierung von VARCHAR-Spalten nützlich, in denen dieselben Wörter häufig wiederholt werden. Für jeden Block von Spaltenwerten auf dem Datenträger wird ein getrenntes Verzeichnis eindeutiger Wörter erstellt. (Ein Amazon-Redshift-Datenträgerblock belegt 1 MB.) Das Verzeichnis enthält die ersten 245 eindeutigen Wörter in der Spalte. Diese Wörter werden auf dem Datenträger durch einen Einzelbyte-Indexwert ersetzt, der einen der 245 Werte darstellt. Wörter, die im Verzeichnis nicht dargestellt werden, werden nicht komprimiert gespeichert. Dieser Vorgang wird für jeden Datenträgerblock von 1 MB wiederholt. Wenn die indizierten Wörter in der Spalte häufig vorkommen, führt dies zu einem hohen Komprimierungsverhältnis für die Spalte.

Für die Text32k-Kodierung gilt dasselbe Prinzip. Das Verzeichnis für die einzelnen Blöcke erfasst jedoch keine bestimmte Anzahl von Wörtern. Stattdessen indiziert das Verzeichnis jedes gefundene eindeutige Wort, bis die kombinierten Einträge eine Länge von 32K abzüglich etwas Overhead erreichen. Die indizierten Werte werden in zwei Bytes gespeichert.

Betrachten Sie beispielsweise die Spalte VENUENAME in der Tabelle VENUE. Wörter wie Arena, Center und Theatre wiederholen sich in dieser Spalte und befinden sich wahrscheinlich unter den ersten 245 Wörtern in jedem Block, wenn die Text255-Kompression angewendet wird. Wenn ja, profitiert diese Spalte von der Komprimierung. Jedes Mal, wenn diese Wörter erscheinen, belegen sie nur 1 Byte Speicher (anstatt 5, 6 bzw. 7 Bytes).

Die Zstandard (ZSTD)-Kodierung stellt ein hohes Kompressionsverhältnis mit sehr guter Leistung über unterschiedliche Datensätze hinweg bereit. ZSTD funktioniert besonders gut für CHAR- und VARCHAR-Spalten, die eine große Vielzahl langer und kurzer Zeichenfolgen speichern, wie Produktbeschreibungen, Benutzerkommentare, Protokolle und JSON-Zeichenfolgen. Während Algorithmen wie die Delta-Kodierung oder die Mostly-Kodierung möglicherweise mehr Speicherplatz belegen als die entsprechenden nicht komprimierten Daten, ist es sehr unwahrscheinlich, dass ZSTD die Datenträgernutzung erhöht.

ZSTD unterstützt die Datentypen SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP und TIMESTAMPTZ.