Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Spaltenkomprimierung zur Reduzierung der Größe der gespeicherten Daten *Komprimierung* ist eine Operation auf Spaltenebene, die die Speichergröße von Daten reduziert. Die Komprimierung bewahrt Speicherplatz und reduziert die Größe der Daten, die aus dem Speicher gelesen werden. Dies reduziert die Menge der Datenträger-I/O und verbessert damit die Abfrageleistung. ENCODE AUTO ist die Standardeinstellung für Tabellen. Wenn für eine Tabelle ENCODE AUTO festgelegt wird, verwaltet Amazon Redshift automatisch die Kompressionskodierung für alle Spalten in der Tabelle. Weitere Informationen erhalten Sie unter [CREATE TABLE](r_CREATE_TABLE_NEW.md) und [ALTER TABLE](r_ALTER_TABLE.md). Wenn Sie jedoch die Komprimierungskodierung für eine Spalte in der Tabelle angeben, wird die Tabelle nicht mehr auf ENCODE AUTO festgelegt. Amazon Redshift verwaltet nicht mehr automatisch die Komprimierungskodierung für alle Spalten in der Tabelle. Sie können einen Komprimierungstyp oder *encoding* manuell auf die Tabellen anwenden, wenn Sie sie erstellen. Sie können auch den Befehl COPY verwenden, um die Komprimierung automatisch zu analysieren und anzuwenden. Weitere Informationen finden Sie unter [Lassen Sie COPY die Kompressionskodierungen auswählen](c_best-practices-use-auto-compression.md). Details zur Anwendung der automatischen Kompression finden Sie unter [Laden von Tabellen mit automatischer Kompression](c_Loading_tables_auto_compress.md). **Anmerkung** Es wird nachdrücklich empfohlen, den COPY-Befehl zu verwenden, um die automatische Kompression anzuwenden. Sie können die Komprimierungskodierung manuell anwenden, wenn die neue Tabelle dieselben Datenmerkmale wie eine andere Tabelle aufweist. Sie können dies auch tun, wenn Sie während Tests feststellen, dass die während der automatischen Komprimierung angewendeten Kompressionskodierungen für Ihre Daten nicht optimal geeignet sind. Wenn Sie Kompressionskodierungen manuell anwenden, können Sie den Befehl [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) für eine bereits ausgefüllte Tabelle ausführen und die Ergebnisse verwenden, um die Kompressionskodierungen zu wählen. Um die Kompression manuell anzuwenden, geben Sie die Kompressionskodierungen für einzelne Spalten als Teil der Anweisung CREATE TABLE an. Die Syntax ist wie folgt. ``` CREATE TABLE table_name (column_name data_type ENCODE encoding-type)[, ...] ``` Wobei *encoding-type* der Schlüsselworttabelle im folgenden Abschnitt entnommen ist. Die folgende Anweisung erstellt beispielsweise eine Tabelle mit zwei Spalten, PRODUCT. Wenn Daten in die Tabelle geladen werden, wird nicht die Spalte PRODUCT\$1ID komprimiert, sondern die Spalte PRODUCT\$1NAME. Dabei wird die Byte-Verzeichnis-Kodierung (BYTEDICT) verwendet. ``` create table product( product_id int encode raw, product_name char(20) encode bytedict); ``` Sie können die Kodierung für eine Spalte angeben, wenn sie einer Tabelle mittels des Befehls ALTER TABLE hinzugefügt wird. ``` ALTER TABLE table-name ADD [ COLUMN ] column_name column_type ENCODE encoding-type ``` **Topics** + [Kompressionskodierungen](c_Compression_encodings.md) + [Testen der Kompressionskodierungen](t_Verifying_data_compression.md) # Kompressionskodierungen Eine *Komprimierungskodierung* gibt die Art der Komprimierung an, die auf eine Spalte von Datenwerten angewendet wird, während einer Tabelle Zeilen hinzugefügt werden. ENCODE AUTO ist die Standardeinstellung für Tabellen. Wenn für eine Tabelle ENCODE AUTO festgelegt wird, verwaltet Amazon Redshift automatisch die Kompressionskodierung für alle Spalten in der Tabelle. Weitere Informationen erhalten Sie unter [CREATE TABLE](r_CREATE_TABLE_NEW.md) und [ALTER TABLE](r_ALTER_TABLE.md). Wenn Sie jedoch die Komprimierungskodierung für eine Spalte in der Tabelle angeben, wird die Tabelle nicht mehr auf ENCODE AUTO festgelegt. Amazon Redshift verwaltet nicht mehr automatisch die Komprimierungskodierung für alle Spalten in der Tabelle. Bei Verwendung von CREATE AUTO wird ENCODE AUTO deaktiviert, wenn Sie für eine Spalte in der Tabelle die Kompressionskodierung festlegen. Wenn ENCODE AUTO deaktiviert ist, weist Amazon Redshift den Spalten, für die Sie keinen ENCODE-Typ angeben, automatisch wie folgt eine anfängliche Kompressionskodierung zu: + Spalten, die als Sortierschlüssel definiert sind, wird die RAW-Kompression zugewiesen. + Spalten, die als die Datentypen BOOLEAN, REAL oder DOUBLE PRECISION definiert sind, wird die RAW-Kodierung zugewiesen. + Spalten, die als SMALLINT-, INTEGER-, BIGINT-, DECIMAL-, DATE-, TIMESTAMP- oder TIMESTAMPTZ-Datentypen definiert sind, wird Komprimierung zugewiesen. AZ64 + Spalten, die als CHAR- oder VARCHAR-Datentypen definiert sind, wird LZO-Komprimierung zugewiesen. Sie können die Kodierung einer Tabelle nach der Erstellung ändern, indem Sie ALTER TABLE verwenden. Wenn Sie ENCODE AUTO mithilfe von ALTER TABLE deaktivieren, verwaltet Amazon Redshift die Kompressionskodierungen für Ihre Spalten nicht mehr automatisch. Alle Spalten behalten so lange die Kompressionskodierungstypen bei, die sie bei der Deaktivierung von ENCODE AUTO aufwiesen, bis Sie sie ändern oder ENCODE AUTO erneut aktivieren. Amazon Redshift unterstützt die folgenden Kompressionskodierungen: ------ #### [ Raw ] 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 ] AZ64 ist 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 mit mehreren Daten (SIMD) für die Parallelverarbeitung. Wird verwendet AZ64, um erhebliche Speichereinsparungen und eine hohe Leistung für numerische, Datums- und Uhrzeitdatentypen zu erzielen. Sie können die Kodierung AZ64 als Komprimierung verwenden, wenn Sie Spalten mit den Anweisungen CREATE TABLE und ALTER TABLE mit den folgenden Datentypen definieren: + SMALLINT + INTEGER + BIGINT + DECIMAL + DATUM + 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 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 Zeichenfolgenspalten erheblich beschleunigt. Die Byte-Dictionary-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. **Anmerkung** Leerzeichen am Ende werden im Fall von Zeichenspalten mit fester Länge gespeichert. Daher spart in einer CHAR(30)-Spalte jeder komprimierte Wert 29 Bytes an Speicher, wenn Sie die Byte-Verzeichnis-Kodierung verwenden. Die folgende Tabelle stellt das Verzeichnis für die Spalte COUNTRY dar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) Die folgende Tabelle stellt die Werte in der Spalte COUNTRY dar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) Die gesamte komprimierte Größe in diesem Beispiel wird wie folgt berechnet: Im Verzeichnis sind 6 verschiedene Einträge gespeichert (6 \$1 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: + DELTA zeichnet die Unterschiede als 1-Byte-Werte auf (8-Bit-Ganzzahlen). + DELTA32K zeichnet Unterschiede als 2-Byte-Werte (16-Bit-Ganzzahlen) auf 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ LZO ] 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 ] 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 Spalte, auf einen INT2 8-Bit-Speicher komprimieren. Im Allgemeinen funktionieren Mostly-Kodierungen mit den folgenden Datentypen: + SMALLINT/ INT2 (16-Bit) + INTEGER/INT (32-Bit) + INT8 BIGINT/ (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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) **Anmerkung** 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 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 das Neuerstellen und Neuladen dieser Tabelle mit der MOSTLY16 Kodierung für VENUEID die Speicherung aller Werte 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 MOSTLY8, MOSTLY16 und verwendet werden: MOSTLY32 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ 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. 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 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 die Spalte COLOR verwendet, um zu zeigen, wie die Run-length-Kodierung funktioniert: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Text255 and Text32k ] 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). ------ #### [ ZSTD ] 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. ------ In der folgenden Tabelle werden die unterstützten Kompressionskodierungen und die Datentypen, die die Kodierung unterstützen, aufgelistet. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_Compression_encodings.html) # Testen der Kompressionskodierungen Wenn Sie die Spaltenkodierungen manuell angeben, sollten Sie die verschiedenen Kodierungen mit Ihren Daten testen. **Anmerkung** Es wird empfohlen, den COPY-Befehl zu verwenden, um Daten wann immer möglich zu laden, und dem COPY-Befehl zu gestatten, die optimalen Kodierungen basierend auf Ihren Daten zu wählen. Alternativ können Sie den [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md)-Befehl verwenden, um die für vorhandene Daten vorgeschlagenen Kodierungen anzuzeigen. Details zur Anwendung der automatischen Kompression finden Sie unter [Laden von Tabellen mit automatischer Kompression](c_Loading_tables_auto_compress.md). Um einen relevanten Test der Datenkomprimierung ausführen zu können, müssen Sie über eine große Zahl von Zeilen verfügen. Für die Zwecke dieses Beispiels erstellen wir eine Tabelle, in die unter Verwendung einer Anweisung, die Daten aus den beiden Tabellen VENUE und LISTING auswählt, Zeilen eingefügt werden. Wir lassen die WHERE-Klausel aus, die normalerweise die beiden Tabellen verbinden würde. Daher wird für *jede* Zeile in der Tabelle VENUE ein Join für *alle* Zeilen in der Tabelle LISTING ausgeführt, insgesamt mehr als 32 Millionen Zeilen. Diese Art von Join ist als kartesischer Join bekannt und wird normalerweise nicht empfohlen. Für die vorliegenden Zwecke ist dies jedoch eine praktische Methode, um eine große Zahl von Zeilen zu erstellen. Wenn Sie bereits eine Tabelle mit Daten besitzen, die Sie testen möchten, können Sie diesen Schritt überspringen. Nachdem wir eine Tabelle mit Beispieldaten erhalten, erstellen wir eine Tabelle mit sieben Spalten. Jede Komprimierungskodierung hat eine andere Komprimierungskodierung: raw, bytedict, lzo, run length, text255, text32k und zstd. Jede Spalte wird mit genau den gleichen Daten ausgefüllt, indem ein INSERT-Befehl ausgeführt wird, der die Daten aus der ersten Tabelle auswählt. Führen Sie zum Testen von Komprimierungskodierungen folgende Schritte aus: 1. (Optional) Verwenden Sie einen kartesischen Join, um eine Tabelle mit einer großen Zahl von Zeilen zu erstellen. Sie können diesen Schritt überspringen wenn Sie eine bereits vorhandene Tabelle testen möchten. ``` create table cartesian_venue( venueid smallint not null distkey sortkey, venuename varchar(100), venuecity varchar(30), venuestate char(2), venueseats integer); insert into cartesian_venue select venueid, venuename, venuecity, venuestate, venueseats from venue, listing; ``` 1. Erstellen Sie als Nächstes eine Tabelle mit den Kodierungen, die Sie vergleichen möchten. ``` create table encodingvenue ( venueraw varchar(100) encode raw, venuebytedict varchar(100) encode bytedict, venuelzo varchar(100) encode lzo, venuerunlength varchar(100) encode runlength, venuetext255 varchar(100) encode text255, venuetext32k varchar(100) encode text32k, venuezstd varchar(100) encode zstd); ``` 1. Fügen Sie die gleichen Daten in alle Spalten mithilfe einer INSERT-Anweisungen mit einer SELECT-Klausel ein. ``` insert into encodingvenue select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd from cartesian_venue; ``` 1. Überprüfen Sie die Anzahl der Zeilen in der neuen Tabelle. ``` select count(*) from encodingvenue count ---------- 38884394 (1 row) ``` 1. Führen Sie eine Abfrage für die Systemtabelle [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) aus, um die Zahl der Datenträgerblöcke mit 1 MB zu vergleichen, die von den einzelnen Spalten verwendet werden. Die MAX-Aggregationsfunktion gibt für jede Spalte die höchste Blockzahl zurück. Die Tabelle STV\$1BLOCKLIST enthält Details für drei systemgenerierte Spalten. Dieses Beispiel verwendet `col < 6` in der WHERE-Klausel, um die systemgenerierten Spalten auszuschließen. ``` select col, max(blocknum) from stv_blocklist b, stv_tbl_perm p where (b.tbl=p.id) and name ='encodingvenue' and col < 7 group by name, col order by col; ``` Die Abfrage gibt die folgenden Ergebnisse zurück. Die Spalten sind nummeriert, beginnend mit null. Je nach Konfiguration Ihres Clusters unterscheiden sich die Zahlen in Ihrem Ergebnis möglicherweise. Die relativen Größen sollten jedoch ähnlich sein. Sie sehen, dass die BYTEDICT-Kodierung in der zweiten Spalte die besten Ergebnisse für diesen Datensatz generiert. Dieser Ansatz hat ein Komprimierungsverhältnis von mehr als 20:1. Die LZO und ZSTD-Kodierungen führten ebenfalls zu herausragenden Ergebnissen. Andere Datensätze liefern natürlich andere Ergebnisse. Wenn eine Spalte längere Textzeichenfolgen enthält, generiert LZO häufig die besten Kompressionsergebnisse. ``` col | max -----+----- 0 | 203 1 | 10 2 | 22 3 | 204 4 | 56 5 | 72 6 | 20 (7 rows) ``` Wenn Sie über Daten in einer vorhandenen Tabelle verfügen, können Sie den [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md)-Befehl verwenden, um die für die Tabelle vorgeschlagenen Kodierungen anzuzeigen. Die folgende Tabelle zeigt beispielsweise die empfohlene Kodierung für eine Kopie der Tabelle VENUE mit dem Namen CARTESIAN\$1VENUE, die 38 Millionen Zeilen enthält. Beachten Sie, dass ANALYZE COMPRESSION die LZO-Kodierung für die Spalte VENUENAME empfiehlt. ANALYZE COMPRESSION wählt die optimale Kompression auf der Basis mehrerer Faktoren aus. Zu diesen gehört der Prozentsatz der Reduktion. In diesem spezifischen Fall bietet BYTEDICT eine bessere Kompression, LZO führt jedoch ebenfalls zu einer Kompression von mehr als 90 Prozent. ``` analyze compression cartesian_venue; Table | Column | Encoding | Est_reduction_pct ---------------+------------+----------+------------------ reallybigvenue | venueid | lzo | 97.54 reallybigvenue | venuename | lzo | 91.71 reallybigvenue | venuecity | lzo | 96.01 reallybigvenue | venuestate | lzo | 97.68 reallybigvenue | venueseats | lzo | 98.21 ``` ## Beispiel Die folgende Anweisung erstellt die Tabelle CUSTOMER, die Spalten mit verschiedenen Datentypen enthält. Diese CREATE TABLE-Anweisung zeigt eine der zahlreichen möglichen Kombinationen von Kompressionskodierungen für diese Spalten. ``` create table customer( custkey int encode delta, custname varchar(30) encode raw, gender varchar(7) encode text255, address varchar(200) encode text255, city varchar(30) encode text255, state char(2) encode raw, zipcode char(5) encode bytedict, start_date date encode delta32k); ``` Die folgende Tabelle zeigt die Spaltenkodierungen, die für die Tabelle CUSTOMER gewählt wurden, und erklärt, warum die betreffende Kodierungen gewählt wurden: | Spalte | Datentyp | Codierung | Erklärung | | --- | --- | --- | --- | | CUSTKEY | int | DELTA | CUSTKEY besteht aus eindeutigen Ganzzahlwerten in Folge. Da die Unterschiede nur ein Byte betragen, stellt DELTA eine gute Wahl dar. | | CUSTNAME | varchar(30) | RAW | CUSTNAME ist eine große Domäne, in der nur wenige Werte wiederholt werden. Jede Kompressionskodierung wäre wahrscheinlich ineffektiv. | | GENDER | varchar(7) | Text255 | GENDER ist eine sehr kleine Domäne, in der zahlreiche Werte wiederholt werden. Text255 funktioniert gut mit VARCHAR-Spalten, in denen dieselben Wörter wiederholt werden. | | ADDRESS | varchar(200) | Text255 | ADDRESS ist eine große Domain, enthält jedoch zahlreiche Wörter, die sich wiederholen, wie Straße, Nord, Süd usw. Text255 und Text32k sind für die Komprimierung von VARCHAR-Spalten nützlich, in denen dieselben Wörter wiederholt werden. Die Spaltenlänge ist kurz. Daher ist Text255 eine gute Wahl. | | CITY | varchar(30) | Text255 | CITY ist eine große Domäne, in der einige Werte wiederholt werden. Bestimmte Namen von Städten werden häufiger als andere verwendet. Text255 ist aus den gleichen Gründen wie bei ADDRESS eine gute Wahl. | | STATE | char(2) | RAW | In den Vereinigten Staaten ist STATE eine präzise Domäne mit 50 Werten, die aus zwei Zeichen bestehen. Eine Bytedict-Kodierung würde zu etwas Kompression führen. Da die Größe der Spalte jedoch nur zwei Zeichen beträgt, ist die Kompression wahrscheinlich den Aufwand nicht wert, der durch die Entkomprimierung der Daten entsteht. | | ZIPCODE | char(5) | Bytedict | ZIPCODE ist eine bekannte Domäne mit weniger als 50.000 eindeutigen Werten. Bestimmte Postleitzahlen treten sehr viel häufiger auf als andere. Die Bytedict-Kodierung ist sehr effektiv, wenn eine Spalte eine begrenzte Zahl eindeutiger Werte enthält. | | START\$1DATE | date | Delta32K | Delta-Kodierungen sind für Datum-/Uhrzeitspalten sehr nützlich, besonders, wenn die Zeilen in der Reihenfolge des Datums geladen werden. |