Testen der Kompressionskodierungen - Amazon Redshift
Beispiel

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.

Testen der Kompressionskodierungen

Wenn Sie die Spaltenkodierungen manuell angeben, sollten Sie die verschiedenen Kodierungen mit Ihren Daten testen.

Anmerkung

Wir empfehlen, den COPY Befehl wann immer möglich zum Laden von Daten zu verwenden und es dem COPY Befehl zu überlassen, die optimalen Kodierungen auf der Grundlage Ihrer Daten auszuwählen. Alternativ können Sie den ANALYZE COMPRESSION-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.

Um einen relevanten Test der Datenkomprimierung ausführen zu können, müssen Sie über eine große Zahl von Zeilen verfügen. In diesem Beispiel erstellen wir eine Tabelle und fügen Zeilen ein, indem wir eine Anweisung verwenden, die aus zwei Tabellen auswählt; VENUE undLISTING. Wir lassen die WHERE Klausel weg, die normalerweise die beiden Tabellen verbinden würde. Das Ergebnis ist, dass jede Zeile in der VENUE Tabelle mit allen Zeilen in der LISTING Tabelle verknüpft wird, was insgesamt über 32 Millionen Zeilen ergibt. 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. Wir füllen jede Spalte mit exakt denselben Daten, indem wir einen INSERT Befehl ausführen, 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;

  2. 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);

  3. Fügen Sie mithilfe einer INSERT Anweisung mit einer SELECT Klausel dieselben Daten in alle Spalten 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;

  4. Überprüfen Sie die Anzahl der Zeilen in der neuen Tabelle. 

    select count(*) from encodingvenue

  count
----------
 38884394
(1 row)

  5. Führen Sie eine Abfrage für die Systemtabelle STV_BLOCKLIST aus, um die Zahl der Datenträgerblöcke mit 1 MB zu vergleichen, die von den einzelnen Spalten verwendet werden.

    Die MAX Aggregatfunktion gibt die höchste Blocknummer für jede Spalte zurück. Die BLOCKLIST Tabelle STV _ enthält Details für drei vom System generierte Spalten. In diesem Beispiel werden col < 6 in der WHERE Klausel die vom System generierten Spalten ausgeschlossen. 

    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 können sehen, dass die BYTEDICT Kodierung der zweiten Spalte zu den besten Ergebnissen für diesen Datensatz geführt hat. Dieser Ansatz hat ein Komprimierungsverhältnis von mehr als 20:1. LZOund die ZSTD Kodierung führte ebenfalls zu hervorragenden Ergebnissen. Andere Datensätze liefern natürlich andere Ergebnisse. Wenn eine Spalte längere Textzeichenfolgen enthält, werden LZO häufig die besten Komprimierungsergebnisse erzielt.

     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-Befehl verwenden, um die für die Tabelle vorgeschlagenen Kodierungen anzuzeigen. Das folgende Beispiel zeigt beispielsweise die empfohlene Kodierung für eine Kopie der VENUE Tabelle CARTESIAN _VENUE, die 38 Millionen Zeilen enthält. Beachten Sie, dass die LZO Kodierung für die VENUENAME Spalte ANALYZE COMPRESSION empfohlen wird. ANALYZECOMPRESSIONwählt die optimale Komprimierung auf der Grundlage mehrerer Faktoren, zu denen auch die prozentuale Reduzierung gehört. In diesem speziellen Fall BYTEDICT sorgt diese Option für eine bessere Komprimierung, aber LZO auch für eine Komprimierung 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

Im folgenden Beispiel wird eine CUSTOMER Tabelle erstellt, die Spalten mit verschiedenen Datentypen enthält. Diese CREATE TABLE Anweisung zeigt eine von vielen möglichen Kombinationen von Komprimierungskodierungen 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 für die CUSTOMER Tabelle ausgewählten Spaltenkodierungen und gibt eine Erläuterung der Auswahlmöglichkeiten:

Spalte Datentyp Codierung Erklärung
CUSTKEY int DELTA CUSTKEYbesteht aus eindeutigen, aufeinanderfolgenden Ganzzahlwerten. Da die Unterschiede ein Byte betragen, DELTA ist das eine gute Wahl.
CUSTNAME varchar(30) RAW CUSTNAMEhat eine große Domäne mit wenigen wiederholten Werten. Jede Kompressionskodierung wäre wahrscheinlich ineffektiv.
GENDER varchar(7) Text255 GENDERist eine sehr kleine Domäne mit vielen wiederholten Werten. Text255 funktioniert gut mit VARCHAR Spalten, in denen dieselben Wörter wiederkommen.
ADDRESS varchar(200) Text255 ADDRESSist eine große Domäne, enthält aber viele sich wiederholende Wörter wie Straße, Allee, Norden, Süden usw. Text 255 und Text 32k eignen sich zum Komprimieren von VARCHAR Spalten, in denen sich dieselben Wörter wiederholen. Die Spaltenlänge ist kurz. Daher ist Text255 eine gute Wahl.
CITY varchar(30) Text255 CITYist eine große Domäne mit einigen sich wiederholenden Werten. Bestimmte Namen von Städten werden häufiger als andere verwendet. Text255 ist aus den gleichen Gründen wie ADDRESS eine gute Wahl.
STATE char(2) RAW In den Vereinigten Staaten STATE ist dies eine präzise Domäne mit 50 zweistelligen Werten. 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 ZIPCODEist eine bekannte Domäne mit weniger als 50.000 Einzelwerten. 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_DATE date Delta32K Delta-Kodierungen sind für Datum-/Uhrzeitspalten sehr nützlich, besonders, wenn die Zeilen in der Reihenfolge des Datums geladen werden.