- Raw
-
Die Rohkodierung ist die Standardcodierung für Spalten, die als Sortierschlüssel bezeichnet werden, und für Spalten, die als BOOLEANREAL, oder DOUBLE PRECISION Datentypen definiert sind. Bei einer Rohkodierung werden die Daten in roher, nicht komprimierter Form gespeichert.
- AZ64
-
AZ64ist ein proprietärer Komprimierungscodierungsalgorithmus, der von Amazon entwickelt wurde, um eine hohe Komprimierungsrate und eine verbesserte Abfrageverarbeitung zu erreichen. Im Kern komprimiert der AZ64 Algorithmus kleinere Gruppen von Datenwerten und verwendet Einzelbefehle und mehrere data (SIMD) -Befehle für die parallel Verarbeitung. Wird verwendetAZ64, um erhebliche Speichereinsparungen und eine hohe Leistung für numerische, Datums- und Uhrzeitdatentypen zu erzielen.
Sie können die Kodierung AZ64 als Kompressionskodierung verwenden, wenn Sie Spalten mithilfe von CREATE TABLE ALTER TABLE AND-Anweisungen mit den folgenden Datentypen definieren:
SMALLINT
INTEGER
BIGINT
DECIMAL
DATE
TIMESTAMP
TIMESTAMPTZ
- Byte-dictionary
-
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 Zeichenkettendatentyp (CHARundVARCHAR), der mit codiert istBYTEDICT, führt Amazon Redshift vektorisierte Scans und Prädikatauswertungen durch, die direkt komprimierte Daten verarbeiten. Diese Scans verwenden hardwarespezifische Einzelbefehle und mehrere data (SIMD) -Befehle für die parallel Verarbeitung. Dadurch wird das Scannen von Zeichenfolgenspalten erheblich beschleunigt. Die Kodierung mit einem Bytewörterbuch ist besonders platzsparend, wenn eine CHAR VARCHAR /-Spalte lange Zeichenketten enthält.
Angenommen, eine Tabelle hat eine COUNTRY Spalte mit dem Datentyp CHAR (30). Beim Laden der Daten erstellt Amazon Redshift das Wörterbuch und füllt die COUNTRY Spalte mit dem Indexwert. Das Verzeichnis enthält die indizierten eindeutigen Werte. Die Tabelle selbst enthält nur die Einzelbyte-Subskripts der entsprechenden Werte.
Leerzeichen am Ende werden im Fall von Zeichenspalten mit fester Länge gespeichert. Daher spart in einer Spalte CHAR (30) jeder komprimierte Wert 29 Byte Speicherplatz, wenn Sie die Byte-Wörterbuchcodierung verwenden.
Die folgende Tabelle stellt das Wörterbuch für die COUNTRY Spalte dar.
| Eindeutiger Datenwert |
Verzeichnisindex |
Größe (feste Länge, 30 Bytes pro Wert) |
| England |
0 |
30 |
| United States of America |
1 |
30 |
| Venezuela |
2 |
30 |
| Sri Lanka |
3 |
30 |
| Argentina |
4 |
30 |
| Japan |
5 |
30 |
| Gesamtsumme |
|
180 |
Die folgende Tabelle stellt die Werte in der COUNTRY Spalte dar.
| Ursprünglicher Datenwert |
Ursprüngliche Größe (feste Länge, 30 Bytes pro Wert) |
Komprimierter Wert (Index) |
Neue Größe (Bytes) |
| England |
30 |
0 |
1 |
| England |
30 |
0 |
1 |
| United States of America |
30 |
1 |
1 |
| United States of America |
30 |
1 |
1 |
| Venezuela |
30 |
2 |
1 |
| Sri Lanka |
30 |
3 |
1 |
| Argentina |
30 |
4 |
1 |
| Japan |
30 |
5 |
1 |
| Sri Lanka |
30 |
3 |
1 |
| Argentina |
30 |
4 |
1 |
| Gesamtsumme |
300 |
|
10 |
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
-
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 die Differenz zwischen zwei Werten den 1-Byte-Bereich (DELTA) oder den 2-Byte-Bereich (DELTA32K) überschreitet, wird der vollständige Originalwert mit einem führenden 1-Byte-Flag gespeichert. 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:
| Ursprünglicher Datenwert |
Ursprüngliche Größe (Bytes) |
Unterschied (Delta) |
Komprimierter Wert |
Komprimierte Größe (Bytes) |
| 1 |
4 |
|
1 |
1+4 (Flag + tatsächlicher Wert) |
| 5 |
4 |
4 |
4 |
1 |
| 50 |
4 |
45 |
45 |
1 |
| 200 |
4 |
150 |
150 |
1+4 (Flag + tatsächlicher Wert) |
| 185 |
4 |
-15 |
-15 |
1 |
| 220 |
4 |
35 |
35 |
1 |
| 221 |
4 |
1 |
1 |
1 |
| Gesamt |
28 |
|
|
15 |
- LZO
-
LZODie Kodierung bietet ein sehr hohes Kompressionsverhältnis bei guter Leistung. LZODie Kodierung funktioniert besonders gut für CHAR VARCHAR Spalten, die sehr lange Zeichenketten speichern. Sie eignen sich besonders gut für Freiformtext wie Produktbeschreibungen, Benutzerkommentare oder JSON Zeichenketten.
- Mostly
-
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, z. B. eine INT2 Spalte, auf 8-Bit-Speicher komprimieren.
Im Allgemeinen funktionieren Mostly-Kodierungen mit den folgenden Datentypen:
-
SMALLINT/INT2(16-Bit)
-
INTEGER/INT(32-Bit)
-
BIGINT/INT8(64 Bit)
-
DECIMAL/NUMERIC(64 Bit)
Wählen Sie die Variante der Mostly-Kodierung, die der Größe des Datentyps für die Spalte am besten entspricht. Wenden Sie dies beispielsweise auf eine Spalte MOSTLY8 an, die als 16-Bit-Integer-Spalte definiert ist. Das MOSTLY16 Anwenden 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.
| Codierung |
Komprimierte Speichergröße |
Bereich von Werten, die komprimiert werden können (Werte außerhalb des Bereichs werden nicht komprimiert gespeichert). |
| MOSTLY8 |
1 Byte (8 Bits) |
-128 bis +127 |
| MOSTLY16 |
2 Bytes (16 Bits) |
-32768 bis +32767 |
| MOSTLY32 |
4 Bytes (32 Bits) |
-2147483648 bis +2147483647 |
Ignorieren Sie bei Dezimalwerten das Dezimalzeichen, um zu ermitteln, ob der Wert dem Bereich entspricht. Beispielsweise wird 1.234,56 als 123.456 behandelt und kann in einer Spalte komprimiert werden. MOSTLY32
Beispielsweise ist die VENUEID Spalte in der VENUE Tabelle als unformatierte Ganzzahlspalte definiert, was bedeutet, dass ihre Werte 4 Byte Speicherplatz beanspruchen. Der aktuelle Bereich von Werten in der Spalte ist 0 bis 309. Daher VENUEID würde das Neuerstellen und Neuladen dieser Tabelle mit der MOSTLY16 Kodierung für den die Speicherung jedes Werts in dieser Spalte auf 2 Byte reduzieren.
Wenn die VENUEID Werte, auf die in einer anderen Tabelle verwiesen wird, größtenteils im Bereich von 0 bis 127 lägen, könnte es sinnvoll sein, diese Fremdschlüsselspalte als zu codieren. MOSTLY8 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 bestimmte numerische Werte, wenn die Kodierungen MOSTLY8MOSTLY16, und MOSTLY32 verwendet werden:
| Ursprünglicher Wert |
Original INT oder BIGINT Größe (Byte) |
MOSTLY8komprimierte Größe (Byte) |
MOSTLY16komprimierte Größe (Byte) |
MOSTLY32komprimierte Größe (Byte) |
| 1 |
4 |
1 |
2 |
4 |
| 10 |
4 |
1 |
2 |
4 |
| 100 |
4 |
1 |
2 |
4 |
| 1000 |
4 |
Identisch mit der Größe der nicht komprimierten Daten |
2 |
4 |
| 10000 |
4 |
2 |
4 |
| 20000 |
4 |
2 |
4 |
| 40000 |
8 |
Identisch mit der Größe der nicht komprimierten Daten |
4 |
| 100000 |
8 |
4 |
| 2000000000 |
8 |
4 |
- Run length
-
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.
Nehmen wir beispielsweise an, dass eine Spalte in einer großen Dimensionstabelle eine vorhersehbar kleine Domäne hat, z. B. 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 Run-length-Kodierung auf eine Spalte anzuwenden, die als Sortierschlüssel definiert ist. Scans mit eingeschränkten Bereichen funktionieren besser, wenn Blöcke ähnliche Zahlen 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 anhand des COLOR Spaltenbeispiels veranschaulicht, wie die Lauflängenkodierung funktioniert.
| Ursprünglicher Datenwert |
Ursprüngliche Größe (Bytes) |
Komprimierter Wert (Token) |
Komprimierte Größe (Bytes) |
| Blue |
4 |
{2,Blau} |
5 |
| Blue |
4 |
0 |
| Green |
5 |
{3,Grün} |
6 |
| Green |
5 |
0 |
| Green |
5 |
0 |
| Blue |
4 |
{1,Blue} |
5 |
| Yellow |
6 |
{4,Yellow} |
7 |
| Yellow |
6 |
0 |
| Yellow |
6 |
0 |
| Yellow |
6 |
0 |
| Gesamtsumme |
51 |
|
23 |
- Text255 and Text32k
-
Die Kodierungen Text255 und Text32k eignen sich zum Komprimieren von VARCHAR Spalten, in denen dieselben Wörter häufig vorkommen. 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 zum Beispiel die Spalte in der VENUENAME 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).
- ZSTD
-
Die Zstandard (ZSTD) -Kodierung bietet ein hohes Kompressionsverhältnis mit sehr guter Leistung bei unterschiedlichen Datensätzen. ZSTDfunktioniert besonders gut mit VARCHAR Spalten CHAR und, die eine Vielzahl langer und kurzer Zeichenketten speichern, wie Produktbeschreibungen, Benutzerkommentare, Logs und JSON Zeichenketten. Während einige Algorithmen, wie Delta-Kodierung oder Mostly Encoding, potenziell mehr Speicherplatz als keine Komprimierung beanspruchen können, ZSTD ist es unwahrscheinlich, dass sie die Festplattennutzung erhöhen.
ZSTDunterstütztSMALLINT,INTEGER,BIGINT,DECIMAL,REAL, DOUBLE PRECISIONBOOLEAN,CHAR,VARCHAR,DATE,TIMESTAMP, und TIMESTAMPTZ Datentypen.
