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.
# Aktivieren automatischer Tabellenoptimierung
Die automatische Tabellenoptimierung ist eine Selbstoptimierungsfunktion, die automatisch das Design von Tabellen optimiert, indem Sortier- und Verteilungsschlüssel ohne Eingreifen eines Administrators angewendet werden. Durch die Automatisierung zur Optimierung des Designs von Tabellen können Sie loslegen und die schnellste Leistung erzielen, ohne Zeit investieren zu müssen, um Tabellenoptimierungen manuell zu erstellen und zu implementieren.
Die automatische Tabellenoptimierung beobachtet kontinuierlich, wie Abfragen mit Tabellen interagieren. Es verwendet fortschrittliche Methoden der künstlichen Intelligenz, um Sortier- und Verteilungsschlüssel auszuwählen, um die Leistung für den Workload des Clusters zu optimieren. Wenn Amazon Redshift feststellt, dass die Anwendung eines Schlüssels die Clusterleistung verbessert, werden Tabellen automatisch innerhalb von Stunden ab der Erstellung des Clusters geändert. Dies hat minimale Auswirkungen auf Abfragen.
Um diese Automatisierung nutzen zu können, erstellt ein Amazon-Redshift-Administrator eine neue Tabelle oder ändert eine vorhandene Tabelle, um die automatische Optimierung zu ermöglichen. Bestehende Tabellen mit einem Verteilungsstil oder einem `AUTO`-Sortierschlüssel sind bereits für die Automatisierung aktiviert. Wenn Sie Abfragen in diesen Tabellen ausführen, ermittelt Amazon Redshift, ob ein Sortierschlüssel oder ein Verteilungsschlüssel die Leistung verbessert. Wenn dies der Fall ist, ändert Amazon Redshift die Tabelle automatisch, ohne dass der Administrator eingreifen muss. Wenn eine Mindestanzahl von Abfragen ausgeführt wird, werden Optimierungen innerhalb von Stunden nach dem Start des Clusters angewendet.
Wenn Amazon Redshift feststellt, dass ein Verteilungsschlüssel die Leistung von Abfragen verbessert, kann der Verteilungsstil in Tabellen, in denen der Verteilungsstil `AUTO` lautet, zu `KEY` geändert werden.
**Topics**
+ [Aktivieren, Deaktivieren und Überwachen der automatischen Tabellenoptimierung](c_ato-enabling-disabling-monitoring.md)
+ [Verwaltung von Workload-Ausschlüssen aus Autonomics](t_Manage_workload_exclusion.md)
+ [Spaltenkomprimierung zur Reduzierung der Größe der gespeicherten Daten](t_Compressing_data_on_disk.md)
+ [Datenverteilung zur Abfrageoptimierung](t_Distributing_data.md)
+ [Sortierschlüssel](t_Sorting_data.md)
+ [Tabelleneinschränkungen](t_Defining_constraints.md)
# Aktivieren, Deaktivieren und Überwachen der automatischen Tabellenoptimierung
Standardmäßig wird für Tabellen, die ohne explizite Definition von Sortierschlüsseln oder Verteilungsschlüsseln erstellt wurden, `AUTO` festgelegt. Zum Zeitpunkt der Tabellenerstellung können Sie auch explizit eine Sortierung oder einen Verteilungsschlüssel manuell festlegen. Wenn Sie den Sortier- oder Verteilungsschlüssel festlegen, wird die Tabelle nicht automatisch verwaltet.
## Aktivieren automatischer Tabellenoptimierung
Um eine vorhandene Tabelle automatisch zu optimieren, verwenden Sie die ALTER-Anweisungsoptionen, um die Tabelle zu `AUTO` zu ändern. Sie können die Automatisierung für Sortierschlüssel definieren, aber nicht für Verteilungsschlüssel (und umgekehrt). Wenn Sie eine ALTER-Anweisung ausführen, um eine Tabelle in eine automatisierte Tabelle zu konvertieren, werden vorhandene Sortierschlüssel und Verteilungsstile beibehalten.
```
ALTER TABLE table_name ALTER SORTKEY AUTO;
```
```
ALTER TABLE table_name ALTER DISTSTYLE AUTO;
```
Weitere Informationen finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md).
Anfangs hat eine Tabelle keinen Verteilungsschlüssel oder Sortierschlüssel. Der Verteilungsstil wird entweder auf `EVEN` oder `ALL` festgelegt, je nach Tischgröße. Mit zunehmender Größe der Tabelle wendet Amazon Redshift die optimalen Verteilungsschlüssel und Sortierschlüssel an. Optimierungen werden innerhalb von Stunden nach dem Ausführen einer minimalen Anzahl von Abfragen angewendet. Bei der Ermittlung von Sortierschlüsseloptimierungen versucht Amazon Redshift, die Datenblöcke zu optimieren, die während eines Tabellenscans von der Festplatte gelesen wurden. Bei der Bestimmung des Verteilungsstils versucht Amazon Redshift, die Anzahl der zwischen Clusterknoten übertragenen Bytes zu optimieren.
## Entfernen der automatischen Tabellenoptimierung aus einer Tabelle
Sie können eine Tabelle aus der automatischen Optimierung entfernen. Beim Entfernen einer Tabelle aus der Automatisierung müssen Sie einen Sortierschlüssel oder einen Verteilungsstil auswählen. Geben Sie zum Ändern des Verteilungsstils einen bestimmten Verteilungsstil an.
```
ALTER TABLE table_name ALTER DISTSTYLE EVEN;
```
```
ALTER TABLE table_name ALTER DISTSTYLE ALL;
```
```
ALTER TABLE table_name ALTER DISTSTYLE KEY DISTKEY c1;
```
Um einen Sortierschlüssel zu ändern, können Sie einen Sortierschlüssel definieren oder keinen auswählen.
```
ALTER TABLE table_name ALTER SORTKEY(c1, c2);
```
```
ALTER TABLE table_name ALTER SORTKEY NONE;
```
## Überwachung der automatischen Tabellenoptimierung
Die Systemansicht `SVV_ALTER_TABLE_RECOMMENDATIONS` zeichnet die aktuellen Empfehlungen von Amazon Redshift Advisor für Tabellen auf. Diese Ansicht zeigt Empfehlungen für alle Tabellen, für diejenigen, die für die automatische Optimierung definiert sind und für diejenigen, die es nicht sind.
Um anzuzeigen, ob eine Tabelle für die automatische Optimierung definiert ist, führen Sie eine Abfrage für die Systemansicht `SVV_TABLE_INFO` aus. Einträge werden nur für Tabellen angezeigt, die in der Datenbank der aktuellen Sitzung sichtbar sind. Empfehlungen werden zweimal täglich innerhalb von Stunden ab der Erstellung des Clusters in die Ansicht eingefügt. Nachdem eine Empfehlung verfügbar ist, wird sie innerhalb einer Stunde gestartet. Nachdem eine Empfehlung (entweder von Amazon Redshift oder von Ihnen) angewendet wurde, wird sie nicht mehr in der Ansicht angezeigt.
Die Systemansicht `SVL_AUTO_WORKER_ACTION` zeigt ein Überwachungsprotokoll aller von Amazon Redshift durchgeführten Aktionen und den vorherigen Status der Tabelle an.
Die Systemansicht `SVV_TABLE_INFO` listet alle Tabellen im System zusammen mit einer Spalte auf, die angibt, ob der Sortierschlüssel und der Verteilungsstil der Tabelle auf `AUTO` festgelegt ist.
Weitere Informationen zur Verwendung dieser Systemansichten finden Sie unter [Systemüberwachung (nur bereitgestellt)](c_intro_system_views.md).
# Verwaltung von Workload-Ausschlüssen aus Autonomics
Mithilfe einer Denylist-Funktion können Sie bestimmte bereitgestellte Endpunkte oder serverlose Arbeitsgruppen von der Beeinflussung autonomer Entscheidungen wie Verteilungsschlüssel und Sortierschlüssel ausschließen. Auf diese Weise können Sie kontrollieren, welche Workloads Amazon Redshift bei Optimierungsentscheidungen für Ihre Redshift Managed Storage (RMS) -Daten berücksichtigt.
**Verwenden Sie die Denylist**
Sie können die Denylist im Bereich Autonomics in der Amazon Redshift Redshift-Konsole verwalten:
1. **Artikel hinzufügen oder entfernen**
Fügen Sie bestimmte bereitgestellte Endpunkte oder serverlose Arbeitsgruppen zur Denylist hinzu und entfernen Sie sie bei Bedarf.
1. **Ansehen und Suchen**
Alle auf der Liste verweigerten Elemente anzeigen und in der Sperrliste nach bestimmten Endpunkten oder Arbeitsgruppen suchen.
Die Denylist ist besonders nützlich, wenn Sie Datenmarktplätze betreiben, Daten mit externen Benutzern teilen oder mehrere Geschäftsbereiche haben, in denen Sie verhindern möchten, dass bestimmte Nutzungsmuster Optimierungsentscheidungen beeinflussen, die für Ihren Workload geeignet sind. Wenn Arbeitsgruppe A beispielsweise Workload A ausführt und Arbeitsgruppe B Workload B in einer gemeinsam genutzten Tabelle T ausführt, wird der Sortierschlüssel von T durch die Workloads A und B bestimmt. Wenn Sie möchten, dass nur Workload A die Sortierschlüssel-Entscheidung beeinflussen soll, fügen Sie Arbeitsgruppe B zur Ablehnungsliste des Endpunkts oder der Arbeitsgruppe hinzu, der Tabelle T gehört. Standardmäßig berücksichtigt Amazon Redshift Autonomics Abfragemuster vom Hersteller und allen Verbrauchern clusters/workgroups , sofern sie nicht ausdrücklich durch Denthe ausgeschlossen sind. Liste.
**Anmerkung**
Sie können Ressourcen in verschiedenen AWS Regionen innerhalb desselben Kontos von der Liste ausschließen. Kontoübergreifendes Denylisting wird noch nicht unterstützt.
## Verwaltung von Denylist-Ressourcen in der Amazon Redshift Redshift-Konsole
Führen Sie in der Amazon-Redshift-Serverless-Konsole die folgenden Schritte aus:
1. Wählen Sie Cluster oder serverlose Arbeitsgruppen.
1. Navigieren Sie zu einer bestimmten Cluster- oder Arbeitsgruppendetailseite.
1. Wählen Sie im Bereich „Tabs“ die Option Autonomics aus.
1. Auf der Registerkarte Autonomics kannst du deine Denylist einsehen und verwalten.
1. Um eine regionsübergreifende Denylist zu verwalten, wähle die entsprechende Region aus. AWS
## Denylist-Ressourcen hinzufügen
1. Navigieren Sie zur Registerkarte Autonomics des ausgewählten Clusters oder der ausgewählten Arbeitsgruppe, wählen Sie die AWS Region aus und klicken Sie auf Ressourcen hinzufügen.
1. Wählen Sie einen oder mehrere bereitgestellte Cluster oder serverlose Arbeitsgruppen aus, die Sie der Denylist hinzufügen möchten, und klicken Sie auf Hinzufügen.
1. Die Tabelle zeigt die Liste der Denylist-Ressourcen.
## Entfernen Sie Denylist-Ressourcen
1. Navigieren Sie zur Registerkarte Autonomics des ausgewählten Clusters oder der ausgewählten Arbeitsgruppe und wählen Sie die Region aus. AWS
1. Wählen Sie den Cluster oder die Arbeitsgruppe, die Sie löschen möchten, aus der Liste aus und klicken Sie auf Entfernen.
1. Ein Bestätigungsdialogfeld wird geöffnet. Wählen Sie zur Bestätigung Entfernen aus.
# 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. |
# Datenverteilung zur Abfrageoptimierung
Wenn Sie Daten in eine Tabelle laden, verteilt Amazon Redshift die Zeilen der Tabelle entsprechend dem Verteilungsstil der Tabelle an die einzelnen Datenverarbeitungsknoten. Wenn sie eine Abfrage ausführen, führt der Abfrageoptimierer nach Bedarf eine Neuverteilung der Zeilen zu den Datenverarbeitungsknoten durch, um Join- oder Aggregierungsoperationen durchführen zu können. Das Ziel der Auswahl eines Tabellenverteilungsstils besteht darin, die Auswirkungen des Neuverteilungsschritts dadurch zu minimieren, dass die Daten dort platziert sind, wo sie benötigt werden, bevor die Abfrage ausgeführt wird.
**Anmerkung**
In diesem Abschnitt werden die Grundsätze der Datenverteilung in einer Amazon-Redshift-Datenbank vorgestellt. Wir empfehlen, Ihre Tabellen mit `DISTSTYLE AUTO` zu erstellen. Wenn Sie dies tun, verwendet Amazon Redshift die automatische Tabellenoptimierung, um den Datenverteilungsstil auszuwählen. Weitere Informationen finden Sie unter [Aktivieren automatischer Tabellenoptimierung](t_Creating_tables.md). Der Rest dieses Abschnitts enthält Details zu Verteilungsstilen.
**Topics**
+ [Datenverteilungskonzepte](#t_data_distribution_concepts)
+ [Verteilungsstile](c_choosing_dist_sort.md)
+ [Anzeigen von Verteilungsstilen](viewing-distribution-styles.md)
+ [Auswerten von Abfragemustern](t_evaluating_query_patterns.md)
+ [Bezeichnen von Verteilungsstilen](t_designating_distribution_styles.md)
+ [Auswerten des Abfrageplans](c_data_redistribution.md)
+ [Beispiel für einen Abfrageplan](t_explain_plan_example.md)
+ [Verteilungsbeispiele](c_Distribution_examples.md)
## Datenverteilungskonzepte
Einige Datenverteilungskonzepte für Amazon Redshift folgen.
**Knoten und Slices**
Ein Amazon-Redshift-Cluster besteht aus einem Satz von Knoten. Jeder Knoten im Cluster besitzt ein eigenes Betriebssystem, einen eigenen dedizierten Arbeitsspeicher und einen eigenen dedizierten Datenträgerplatz. Ein Knoten ist der *Führungsknoten*, der die Verteilung von Daten- und Abfrageverarbeitungsaufgaben an die Datenverarbeitungsknoten verwaltet. Die *Datenverarbeitungsknoten* stellen Ressourcen bereit, um diese Aufgaben zu erledigen.
Der Datenträgerplatz für einen Datenverarbeitungsknoten ist in verschiedene *Slices* aufgeteilt. Die Anzahl der Slices pro Knoten ist von der Knotengröße des Clusters abhängig. Die Knoten sind alle an der parallelen Abfrageausführung beteiligt und arbeiten mit Daten, die so gleichmäßig wie möglich über die Slices verteilt sind. Weitere Informationen zur Anzahl der Slices für die einzelnen Knotengrößen finden Sie unter [About Clusters and Nodes](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) (Informationen zu Clustern und Knoten) im *Amazon-Redshift-Verwaltungshandbuch*.
**Datenumverteilung**
Wenn Sie Daten in eine Tabelle laden, verteilt Amazon Redshift die Zeilen der Tabelle entsprechend dem Verteilungsstil der Tabelle an die einzelnen Knoten-Slices. Als Teil des Abfrageplans ermittelt der Optimierer die Stellen, an denen die Datenblöcke platziert werden müssen, um die Abfrage optimal ausführen zu können. Die Daten werden anschließend während der Ausführung der Abfrage physisch verschoben bzw. umverteilt. Während der Umverteilung können einzelne Zeilen an Knoten gesendet werden, um einen Join auszuführen, oder eine ganze Tabelle an alle Knoten gesendet werden.
Die Datenumverteilung kann einen wesentlichen Anteil an den Kosten eines Abfrageplans haben und der generierte Netzwerkdatenverkehr kann sich auf andere Datenbankoperationen auswirken und die Systemleistung insgesamt beeinträchtigen. Wenn Sie bereits zu Beginn überlegen, wo die Daten am besten platziert werden sollten, können Sie die Auswirkungen der Datenumverteilung minimieren.
**Ziele der Datenverteilung**
Wenn Sie Daten in eine Tabelle laden, verteilt Amazon Redshift die Zeilen der Tabelle entsprechend dem Verteilungsstil, den Sie während der Erstellung der Tabelle gewählt haben, an die Datenverarbeitungsknoten und Slices. Die Datenverteilung hat zwei primäre Ziele:
+ Gleichmäßige Verteilung des Workloads auf die Knoten im Cluster. Eine ungleichmäßige Verteilung oder Verteilungsverzerrung zwingt einige Knoten, mehr Arbeit zu leisten als andere, was die Abfrageleistung beeinträchtigt.
+ Minimierung der Datenverschiebungen während einer Abfrage. Wenn die Zeilen, die an Joins oder Aggregationen beteiligt sind, auf den Knoten bereits zusammen mit den entsprechenden Join-Zeilen in anderen Tabellen platziert werden, muss der Optimierer während der Abfrage weniger Daten umverteilen.
Die von Ihnen für Ihre Datenbank gewählte Verteilungsstrategie hat wichtige Folgen für die Abfrageleistung, die Speicheranforderungen, das Laden von Daten und die Wartung. Indem Sie für jede Tabelle den optimalen Verteilungsstil auswählen, können Sie Ihre Daten gleichmäßig verteilen und die allgemeine Systemleistung deutlich verbessern.
# Verteilungsstile
Wenn Sie eine Tabelle erstellen, können Sie einen von vier Verteilungsstilen angeben, AUTO, EVEN, KEY oder ALL.
Falls Sie keinen Verteilungsstil angeben, verwendet Amazon Redshift die AUTO-Verteilung.
**AUTO-Verteilung**
Bei der AUTO-Verteilung weist Amazon Redshift auf der Grundlage der Größe der Tabellendaten den optimalen Verteilungsstil aus. Wenn beispielsweise der Verteilungsstil AUTO angegeben ist, weist Amazon Redshift kleinen Tabellen zunächst den Verteilungsstil ALL zu. Wenn die Tabelle größer wird, ändert Amazon Redshift den Verteilungsstil möglicherweise in KEY und wählt den Primärschlüssel (oder eine Spalte des zusammengesetzten Primärschlüssels) als Verteilungsschlüssel. Wenn die Tabelle größer wird und keine der Spalten als Verteilungsschlüssel geeignet ist, ändert Amazon Redshift den Verteilungsstil in EVEN. Die Änderung des Verteilungsstils erfolgt im Hintergrund mit minimalen Auswirkungen auf die Benutzerabfragen.
Informationen zum Anzeigen von Aktionen, die Amazon Redshift automatisch zum Ändern eines Tabellenverteilungsschlüssels ausgeführt hat, finden Sie unter [SVL\$1AUTO\$1WORKER\$1ACTION](r_SVL_AUTO_WORKER_ACTION.md). Informationen zum Anzeigen aktueller Empfehlungen zum Ändern eines Tabellenverteilungsschlüssels finden Sie unter [SVV\$1ALTER\$1TABLE\$1RECOMMENDATIONS](r_SVV_ALTER_TABLE_RECOMMENDATIONS.md).
Um den Verteilungsstil einer Tabelle anzuzeigen, führen Sie eine Abfrage für die Systemkatalogansicht PG\$1CLASS\$1INFO aus. Weitere Informationen finden Sie unter [Anzeigen von Verteilungsstilen](viewing-distribution-styles.md). Falls Sie die CREATE TABLE-Anweisung ohne Verteilungsstil angeben, verwendet Amazon Redshift die AUTO-Verteilung.
**EVEN-Verteilung**
Der Führungsknoten verteilt die Zeilen nacheinander über die Slices, unabhängig von den Werten in einer bestimmten Spalte. EVEN-Verteilung ist angemessen, wenn eine Tabelle nicht an Joins beteiligt ist. Sie ist auch angemessen, wenn keine klare Entscheidung zwischen der KEY-Verteilung und der ALL-Verteilung getroffen werden kann.
**KEY-Verteilung**
Die Zeilen werden entsprechend den Werten in einer einzelnen Spalte verteilt. Der Führungsknoten platziert übereinstimmende Werte auf demselben Knoten-Slice. Wenn Sie ein Paar von Tabellen anhand der Joining-Schlüssel verteilen, platziert der Führungsknoten entsprechend den Werten in den Joining-Spalten die Zeilen in den Slices. Auf diese Weise werden übereinstimmende Werte aus den gemeinsamen Spalten physisch zusammen gespeichert.
**ALL-Verteilung**
An jeden Knoten wird eine Kopie der gesamten Tabelle verteilt. Während die EVEN-Verteilung oder die KEY-Verteilung nur einen Teil der Zeilen einer Tabelle auf den einzelnen Knoten platzieren, stellt die ALL-Verteilung sicher, dass alle Zeilen für alle Joins, an denen die Tabelle beteiligt ist, gemeinsam gespeichert werden.
Die ALL-Verteilung multipliziert den erforderlichen Speicherplatz mit der Zahl der Knoten im Cluster. Daher dauert es sehr viel länger, Daten zu laden, zu aktualisieren oder in mehrere Tabellen einzufügen. Die ALL-Verteilung ist nur für Tabellen geeignet, die sich vergleichsweise wenig verändern, d. h. Tabellen, die nicht häufig oder umfassend aktualisiert werden. Da die Kosten für die Umverteilung kleiner Tabellen während einer Abfrage gering sind, gibt es keinen signifikanten Vorteil, kleine Dimensionstabellen als DISTSTYLE ALL zu definieren.
**Anmerkung**
Nachdem Sie für eine Spalte einen Verteilungsstil angegeben haben, verarbeitet Amazon Redshift die Datenverteilung auf Cluster-Ebene. Amazon Redshift erfordert keine Partitionierung von Daten innerhalb von Datenbankobjekten oder unterstützt dieses Konzept. Sie müssen keine Tabellenräume erstellen oder Partitionierungsschemen für Tabellen definieren.
In bestimmten Szenarien können Sie den Verteilungsstil einer Tabelle nach der Erstellung ändern. Weitere Informationen finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md). In Szenarien, in denen Sie den Verteilungsstil nach der Erstellung nicht ändern können, können Sie die Tabelle neu erstellen und die neue Tabelle mit einer Deep Copy-Operation füllen. Weitere Informationen finden Sie unter [Ausführen einer Deep Copy-Operation](performing-a-deep-copy.md)
# Anzeigen von Verteilungsstilen
Um den Verteilungsstil einer Tabelle anzuzeigen, führen Sie eine Abfrage für die Systemkatalogansichten PG\$1CLASS\$1INFO oder SVV\$1TABLE\$1INFO aus.
Die Spalte RELEFFECTIVEDISTSTYLE in PG\$1CLASS\$1INFO zeigt den Verteilungsstil für die Tabelle an. Wenn die Tabelle die automatische Verteilung verwendet, ist RELEFFECTIVEDISTSTYLE auf 10, 11 oder 12 festgelegt. Diese Werte bezeichnen die verwendeten Verteilungsstile AUTO (ALL), AUTO (EVEN) oder AUTO (KEY). Wenn die Tabelle die automatische Verteilung verwendet, ändert sich der Verteilungsstile von anfänglich AUTO (ALL) in AUTO (EVEN) oder AUTO (KEY), wenn die Tabelle wächst.
In der folgenden Tabelle wird der Verteilungsstil für die einzelnen Werte in der Spalte RELEFFECTIVEDISTSTYLE angegeben:
| RELEFFECTIVEDISTSTYLE | Aktueller Verteilungsstil |
| --- | --- |
| 0 | EVEN |
| 1 | KEY |
| 8 | ALL |
| 10 | AUTO (ALL) |
| 11 | AUTO (EVEN) |
| 12 | AUTO (KEY) |
Die Spalte DISTSTYLE in SVV\$1TABLE\$1INFO zeigt den aktuellen Verteilungsstil für die Tabelle an. Wenn die Tabelle die automatische Verteilung verwendet, ist für DISTSTYLE entweder AUTO (ALL), AUTO (EVEN) oder AUTO (KEY) festgelegt.
Im folgenden Beispiel werden vier Tabellen erstellt, die die drei Verteilungsstile und die automatische Verteilung verwenden, anschließend wird eine Abfrage für PG\$1TABLE\$1INFO ausgeführt, um die Verteilungsstile anzuzeigen.
```
create table public.dist_key (col1 int)
diststyle key distkey (col1);
insert into public.dist_key values (1);
create table public.dist_even (col1 int)
diststyle even;
insert into public.dist_even values (1);
create table public.dist_all (col1 int)
diststyle all;
insert into public.dist_all values (1);
create table public.dist_auto (col1 int);
insert into public.dist_auto values (1);
select "schema", "table", diststyle from SVV_TABLE_INFO
where "table" like 'dist%';
schema | table | diststyle
------------+-----------------+------------
public | dist_key | KEY(col1)
public | dist_even | EVEN
public | dist_all | ALL
public | dist_auto | AUTO(ALL)
```
# Auswerten von Abfragemustern
Die Wahl des Verteilungsstils stellt nur einen Aspekt des Datenbankdesigns dar. Betrachten Sie den Verteilungsstil im Kontext des gesamten Systems und wägen Sie die Verteilung mit anderen wichtigen Faktoren wie Clustergröße, Methoden der Kompressionskodierung, Sortierschlüsseln und Tabelleneinschränkungen ab.
Testen Sie Ihr System mit Daten, die so nahe an den realen Daten wie möglich sind.
Um eine gute Wahl in Bezug auf den Verteilungsstil treffen zu können, müssen Sie die Abfragemuster für Ihre Amazon-Redshift-Anwendung verstehen. Identifizieren Sie aufwändigsten Abfragen in Ihrem System und bauen Sie bei Ihrem anfänglichen Datenbankdesign auf den Anforderungen dieser Abfragen auf. Zu den Faktoren, die die Gesamtkosten einer Abfrage bestimmen, gehören die Dauer der Ausführung der Abfrage und die Zahl der beanspruchten Datenverarbeitungsressourcen. Andere Faktoren, die die Abfragekosten bestimmen, sind die Häufigkeit der Ausführung und die Unterbrechung anderer Abfragen und Datenbankvorgänge.
Identifizieren Sie die Tabellen, die von den kostenintensivsten Abfragen verwendet werden, und werten sie deren Rolle bei der Abfragelaufzeit aus. Betrachten Sie die Joins und Aggregationen für diese Tabellen.
Wählen Sie anhand der Anleitungen in diesem Abschnitt für jede Tabelle einen Verteilungsstil aus. Erstellen Sie anschließend die Tabellen, landen Sie sie mit Daten, die den realen Daten so ähnlich wie möglich sind. Testen Sie dann die Tabellen auf die Abfragetypen, die Sie verwenden möchten. Sie können die Abfragebeschreibungspläne auswerten, um Optimierungsmöglichkeiten zu identifizieren. Vergleichen Sie Ladezeiten, Speicheranforderungen und Abfragelaufzeiten, um die Anforderungen Ihres Systems insgesamt auszugleichen.
# Bezeichnen von Verteilungsstilen
Die Überlegungen und Empfehlungen für die Bezeichnung von Verteilungsstilen in diesem Abschnitt verwenden ein Sternschema als Beispiel. Ihr Datenbankdesign könnte auf einem Sternschema, einer Sternschemavariante oder einem ganz anderen Schema beruhen. Amazon Redshift wurde entwickelt, um effektiv mit jedem Schemadesign zu arbeiten, das Sie wählen. Die Grundsätze in diesem Abschnitt können auf jedes Schemadesign angewendet werden.
1. **Geben Sie die Primär- und Fremdschlüssel für alle Ihre Tabellen an.**
Amazon Redshift setzt keine Einschränkungen für Primär- und Fremdschlüssel durch. Der Abfrageoptimierer verwendet sie jedoch beim Generieren von Abfrageplänen. Wenn Sie Primär- und Fremdschlüssel festlegen, muss Ihre Anwendung die Gültigkeit der Schlüssel wahren.
1. **Verteilen Sie die Faktentabelle und ihre größte Dimensionstabelle anhand ihrer gemeinsamen Spalten.**
Wählen Sie die größte Dimension basierend auf der Größe des Datensatzes aus, der am häufigsten Join beteiligt ist, nicht nur basierend auf der Größe der Tabelle. Wenn eine Tabelle unter Verwendung einer WHERE-Klausel gefiltert ist, ist nur ein Teil ihrer Zeilen am Join beteiligt. Eine solche Tabelle wirkt sich weniger auf die Umverteilung aus als eine kleinere Tabelle, die mehr Daten beiträgt. Bezeichnen Sie den Primärschlüssel der Dimensionstabelle und den entsprechenden Fremdschlüssel der Faktentabelle als DISTKEY. Wenn mehrere Tabellen denselben Verteilungsschlüssel verwenden, werden sie ebenfalls zusammen mit der Faktentabelle platziert. Ihre Faktentabelle kann nur einen Verteilungsschlüssel haben. Alle Tabellen, die auf einem anderen Schlüssel verbunden werden, werden nicht mit der Faktentabelle zusammengestellt.
1. **Bezeichnen Sie die Verteilungsschlüssel für die anderen Dimensionstabellen.**
Verteilt die Tabellen anhand ihrer Primär- oder Fremdschlüssel, abhängig davon wie sie am häufigsten Joins mit anderen Tabellen ausführen.
1. **Überprüfen Sie, ob die Verteilung einiger Dimensionstabellen in eine ALL-Verteilung geändert werden sollte.**
Wenn eine Dimensionstabelle nicht mit der Faktentabelle oder anderen wichtigen Joining-Tabellen zusammengestellt werden kann, können Sie die Abfrageleistung dadurch erheblich verbessern, dass Sie die gesamte Tabelle zu allen Knoten verteilen. Die Verwendung der ALL-Verteilung vervielfacht die Speicheranforderungen, verlängert Ladezeiten und erhöht den Aufwand für Wartungsoperationen. Sie sollten daher alle Faktoren sorgfältig abwägen, bevor Sie die ALL-Verteilung wählen. Im folgenden Abschnitt wird beschrieben, wie Sie Kandidaten für die ALL-Verteilung durch Auswerten des EXPLAIN-Plans identifizieren.
1. **Verwenden Sie die AUTO-Verteilung für die übrigen Tabellen.**
Wenn eine Tabelle zum großen Teil denormalisiert ist und nicht an Joins beteiligt ist oder es keine klare Wahl für einen anderen Verteilungsstil gibt, verwenden Sie die AUTO-Verteilung.
Wenn Sie möchten, dass Amazon Redshift einen geeigneten Verteilungsstil auswählt, geben Sie keinen Verteilungsstil an.
# Auswerten des Abfrageplans
Sie können Abfragepläne verwenden, um Kandidaten für die Optimierung des Verteilungsstils zu identifizieren.
Nachdem Sie Ihre anfänglichen Designentscheidungen getroffen haben, erstellen Sie Ihre Tabellen, laden Daten in sie und testen sie. Verwenden Sie einen Testdatensatz, der so nahe an den realen Daten wie möglich ist. Messen Sie die Ladezeiten, um sie als Ausgangspunkt für Vergleiche verwenden zu können.
Werten Sie Abfragen aus, die repräsentativ für die aufwändigsten Abfragen sind, die Sie voraussichtlich ausführen werden, insbesondere Abfragen, die Joins und Aggregationen verwenden. Vergleichen Sie die Laufzeiten für verschiedene Designoptionen. Wenn Sie die Laufzeiten vergleichen, sollten Sie die erste Ausführung der Abfrage nicht berücksichtigen, da die erste Laufzeit die Kompilierungszeit enthält.
**DS\$1DIST\$1NONE**
Es ist keine Umverteilung erforderlich, da korrespondierende Slices auf den Datenverarbeitungsknoten zusammen platziert werden. In der Regel gibt es nur einen DS\$1DIST\$1NONE-Schritt, den Join zwischen der Faktentabelle und einer einzelnen Dimensionstabelle.
**DS\$1DIST\$1ALL\$1NONE**
Es ist keine Umverteilung erforderlich, da die innere Join-Tabelle bereits DISTSTYLE ALL verwendet hat. Die gesamte Tabelle befindet sich auf jedem Knoten.
**DS\$1DIST\$1INNER**
Die innere Tabelle wird umverteilt.
**DS\$1DIST\$1OUTER**
Die äußere Tabelle wird umverteilt.
**DS\$1BCAST\$1INNER**
Eine Kopie der gesamten inneren Tabelle wird an alle Verarbeitungsknoten gesendet.
**DS\$1DIST\$1ALL\$1INNER**
Die gesamte innere Tabelle wird an eine einzige Slice umverteilt wurde, weil die äußere Tabelle DISTSTYLE ALL verwendet.
**DS\$1DIST\$1BOTH**
Beide Tabellen werden umverteilt.
**DS\$1DIST\$1ERR**
Wenn für die Tabelle kein Verteilungsstil ausgewählt ist.
DS\$1DIST\$1NONE und DS\$1DIST\$1ALL\$1NONE sind gut. Sie zeigen an, dass für diesen Schritt keine Verteilung erforderlich war, da alle Joins zusammen platziert waren.
DS\$1DIST\$1INNER bedeutet, dass der Schritt wahrscheinlich relativ hohe Kosten verursacht, da die innere Tabelle an die Knoten umverteilt wird. DS\$1DIST\$1INNER zeigt an, dass die äußere Tabelle bereits korrekt anhand des Join-Schlüssels verteilt wurde. Legen Sie den Verteilungsschlüssel der inneren Tabelle auf den Join-Schlüssel fest, um dies in DS\$1DIST\$1NONE zu konvertieren. In einigen Fällen ist eine Verteilung der inneren Tabelle auf den Join-Schlüssel nicht möglich, da die äußere Tabelle nicht auf den Join-Schlüssel verteilt ist. Wenn dies der Fall ist, prüfen Sie, ob die ALL-Verteilung für die innere Tabelle verwendet werden soll. Wenn die Tabelle nicht häufig oder umfassend aktualisiert wird, und groß genug ist, um zu hohen Umverteilungskosten zu führen, ändern Sie den Verteilungsschlüssel in ALL und führen den Test erneut aus. Die ALL-Verteilung verursacht höhere Ladezeiten. Berücksichtigen Sie daher die Ladezeit bei Ihrer Auswertung, wenn Sie den Test erneut ausführen.
DS\$1DIST\$1ALL\$1INNER ist nicht gut. Dies bedeutet, dass die gesamte innere Tabelle an einen einzelnen Slice umverteilt wird, da die äußere Tabelle DISTSTYLE ALL verwendet, sodass sich auf jedem Knoten eine Kopie der gesamten äußeren Tabelle befindet. Dies führt zu einer ineffizienten seriellen Laufzeit des Joins auf einem einzelnen Knoten, anstatt die Vorteile einer parallelen Laufzeit unter Verwendung aller Knoten zu nutzen. DISTSTYLE ALL ist nur für die Verwendung für die innere Join-Tabelle vorgesehen. Geben Sie stattdessen einen Verteilungsschlüssel an oder verwenden Sie für die äußere Tabelle die EVEN-Verteilung.
DS\$1BCAST\$1INNER und DS\$1DIST\$1BOTH sind nicht gut. In der Regel erfolgen diese Umverteilungen, da für die Tabellen kein Join anhand ihrer Verteilungsschlüssel ausgeführt wurde. Wenn die Faktentabelle noch nicht über einen Verteilungsschlüssel verfügt, geben Sie für beide Tabellen die Join-Spalte als Verteilungsschlüssel an. Wenn die Faktentabelle bereits über einen Verteilungsschlüssel anhand einer anderen Spalte verfügt, überprüfen Sie, ob eine Änderung des Verteilungsschlüssels, damit dieser Join zusammen platziert werden kann, die Leistung insgesamt verbessert. Wenn die Änderung des Verteilungsschlüssels der äußeren Tabelle keine optimale Wahl darstellt, können Sie eine gemeinsame Platzierung erzielen, indem Sie für die innere Tabelle DISTSTYLE ALL angeben.
Im folgenden Beispiel wird ein Teil eines Abfrageplans mit den Bezeichnungen DS\$1BCAST\$1INNER und DS\$1DIST\$1NONE gezeigt.
```
-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
```
Nach der Änderung des Verteilungsstils der Dimensionstabellen in DISTSTYLE ALL zeigt der Abfrageplan für dieselbe Abfrage DS\$1DIST\$1ALL\$1NONE anstelle von DS\$1BCAST\$1INNER. Es gibt darüber hinaus eine wesentliche Änderung bei den relativen Kosten für die Join-Schritte. Die Gesamtkosten sind `14142.59` verglichen mit `3272334142.59` in der vorherigen Abfrage.
```
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
```
# Beispiel für einen Abfrageplan
In diesem Beispiel wird gezeigt, wie Sie einen Abfrageplan auswerten, um Möglichkeiten für die Optimierung der Distribution zu identifizieren.
Führen Sie die folgende Abfrage mit einem EXPLAIN-Befehl aus, um einen Abfrageplan zu generieren.
```
explain
select lastname, catname, venuename, venuecity, venuestate, eventname,
month, sum(pricepaid) as buyercost, max(totalprice) as maxtotalprice
from category join event on category.catid = event.catid
join venue on venue.venueid = event.venueid
join sales on sales.eventid = event.eventid
join listing on sales.listid = listing.listid
join date on sales.dateid = date.dateid
join users on users.userid = sales.buyerid
group by lastname, catname, venuename, venuecity, venuestate, eventname, month
having sum(pricepaid)>9999
order by catname, buyercost desc;
```
SALES ist in der Datenbank TICKIT eine Faktentabelle und LISTING ist ihre größte Dimension. Um die Tabellen gemeinsam zu platzieren, wird SALES anhand der LISTID verteilt. Dies ist der Fremdschlüssel für LISTING. LISTING wird anhand ihres Primärschlüssels LISTID verteilt. Im folgenden Beispiel werden die CREATE TABLE-Befehle für SALES und LISTING gezeigt.
```
create table sales(
salesid integer not null,
listid integer not null distkey,
sellerid integer not null,
buyerid integer not null,
eventid integer not null encode mostly16,
dateid smallint not null,
qtysold smallint not null encode mostly8,
pricepaid decimal(8,2) encode delta32k,
commission decimal(8,2) encode delta32k,
saletime timestamp,
primary key(salesid),
foreign key(listid) references listing(listid),
foreign key(sellerid) references users(userid),
foreign key(buyerid) references users(userid),
foreign key(dateid) references date(dateid))
sortkey(listid,sellerid);
create table listing(
listid integer not null distkey sortkey,
sellerid integer not null,
eventid integer not null encode mostly16,
dateid smallint not null,
numtickets smallint not null encode mostly8,
priceperticket decimal(8,2) encode bytedict,
totalprice decimal(8,2) encode mostly32,
listtime timestamp,
primary key(listid),
foreign key(sellerid) references users(userid),
foreign key(eventid) references event(eventid),
foreign key(dateid) references date(dateid));
```
Im folgenden Abfrageplan zeigt der Zusammenführungs-Join-Schritt für den Join für SALES und LISTING DS\$1DIST\$1NONE. Dies zeigt, dass für den Schritt keine Umverteilung erforderlich ist. Weiter oben im Abfrageplan sehen Sie jedoch, dass die übrigen inneren Joins DS\$1BCAST\$1INNER zeigen. Dies zeigt an, dass die innere Tabelle als Teil der Abfrageausführung rundgesendet wird. Da nur ein Paar von Tabellen gemeinsam anhand der Schlüsselverteilung platziert werden kann, müssen fünf Tabellen erneut rundgesendet werden.
```
QUERY PLAN
XN Merge (cost=1015345167117.54..1015345167544.46 rows=1000 width=103)
Merge Key: category.catname, sum(sales.pricepaid)
-> XN Network (cost=1015345167117.54..1015345167544.46 rows=170771 width=103)
Send to leader
-> XN Sort (cost=1015345167117.54..1015345167544.46 rows=170771 width=103)
Sort Key: category.catname, sum(sales.pricepaid)
-> XN HashAggregate (cost=15345150568.37..15345152276.08 rows=170771 width=103)
Filter: (sum(pricepaid) > 9999.00)
-> XN Hash Join DS_BCAST_INNER (cost=742.08..15345146299.10 rows=170771 width=103)
Hash Cond: ("outer".catid = "inner".catid)
-> XN Hash Join DS_BCAST_INNER (cost=741.94..15342942456.61 rows=170771 width=97)
Hash Cond: ("outer".dateid = "inner".dateid)
-> XN Hash Join DS_BCAST_INNER (cost=737.38..15269938609.81 rows=170766 width=90)
Hash Cond: ("outer".buyerid = "inner".userid)
-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
-> XN Hash (cost=87.98..87.98 rows=8798 width=25)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25)
-> XN Hash (cost=2.02..2.02 rows=202 width=41)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41)
-> XN Hash (cost=499.90..499.90 rows=49990 width=14)
-> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14)
-> XN Hash (cost=3.65..3.65 rows=365 width=11)
-> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11)
-> XN Hash (cost=0.11..0.11 rows=11 width=10)
-> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10)
```
Eine Lösung besteht darin, die Tabellen zu ändern, sodass sie DISTSTYLE ALL aufweisen.
```
ALTER TABLE users ALTER DISTSTYLE ALL;
ALTER TABLE venue ALTER DISTSTYLE ALL;
ALTER TABLE category ALTER DISTSTYLE ALL;
ALTER TABLE date ALTER DISTSTYLE ALL;
ALTER TABLE event ALTER DISTSTYLE ALL;
```
Führen Sie denselben Abfrageplan mit EXPLAIN erneut aus und untersuchen Sie den neuen Abfrageplan. Die Joins zeigen nun DS\$1DIST\$1ALL\$1NONE. Dies zeigt an, dass keine Umverteilung erforderlich ist, da die Daten mittels DISTSTYLE ALL an alle Knoten verteilt wurden.
```
QUERY PLAN
XN Merge (cost=1000000047117.54..1000000047544.46 rows=1000 width=103)
Merge Key: category.catname, sum(sales.pricepaid)
-> XN Network (cost=1000000047117.54..1000000047544.46 rows=170771 width=103)
Send to leader
-> XN Sort (cost=1000000047117.54..1000000047544.46 rows=170771 width=103)
Sort Key: category.catname, sum(sales.pricepaid)
-> XN HashAggregate (cost=30568.37..32276.08 rows=170771 width=103)
Filter: (sum(pricepaid) > 9999.00)
-> XN Hash Join DS_DIST_ALL_NONE (cost=742.08..26299.10 rows=170771 width=103)
Hash Cond: ("outer".buyerid = "inner".userid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=117.20..21831.99 rows=170766 width=97)
Hash Cond: ("outer".dateid = "inner".dateid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.64..17985.08 rows=170771 width=90)
Hash Cond: ("outer".catid = "inner".catid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
-> XN Hash (cost=87.98..87.98 rows=8798 width=25)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25)
-> XN Hash (cost=2.02..2.02 rows=202 width=41)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41)
-> XN Hash (cost=0.11..0.11 rows=11 width=10)
-> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10)
-> XN Hash (cost=3.65..3.65 rows=365 width=11)
-> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11)
-> XN Hash (cost=499.90..499.90 rows=49990 width=14)
-> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14)
```
# Verteilungsbeispiele
In den folgenden Beispielen wird gezeigt, wie Daten anhand der Optionen verteilt werden, die Sie in der CREATE TABLE-Anweisung definieren.
## Beispiele für DISTKEY
Betrachten Sie das Schema der Tabelle USERS in der Datenbank TICKIT. USERID ist als SORTKEY-Spalte und DISTKEY-Spalte definiert:
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'users';
column | type | encoding | distkey | sortkey
---------------+------------------------+----------+---------+---------
userid | integer | none | t | 1
username | character(8) | none | f | 0
firstname | character varying(30) | text32k | f | 0
...
```
USERID ist eine gute Wahl als Verteilungsspalte für diese Tabelle. Wenn Sie eine Abfrage für die Systemansicht SVV\$1DISKUSAGE ausführen, können Sie sehen, dass die Tabelle sehr gleichmäßig verteilt ist. Die Spaltennummern sind nullbasiert. Daher ist USERID Spalte 0.
```
select slice, col, num_values as rows, minvalue, maxvalue
from svv_diskusage
where name='users' and col=0 and rows>0
order by slice, col;
slice| col | rows | minvalue | maxvalue
-----+-----+-------+----------+----------
0 | 0 | 12496 | 4 | 49987
1 | 0 | 12498 | 1 | 49988
2 | 0 | 12497 | 2 | 49989
3 | 0 | 12499 | 3 | 49990
(4 rows)
```
Die Tabelle enthält 49.990 Zeilen. Die Spalte für Zeilen (num\$1values) zeigt, dass jeder Slice ungefähr dieselbe Zahl von Zeilen enthält. Die Spalten für den Mindest- und Maximalwert (minvalue und maxvalue) zeigen den Bereich der Werte in jedem Slice. Jedes Slice umfasst fast den gesamten Wertebereich, sodass die Wahrscheinlichkeit groß ist, dass jedes Slice an der Ausführung einer Abfrage beteiligt ist, die nach einem bestimmten IDs Benutzerbereich filtert.
Dieses Beispiel zeigt eine Verteilung für ein kleines Testsystem. Die Gesamtzahl der Slices ist in der Regel sehr viel höher.
Wenn Sie häufig Joins oder Gruppierungen anhand der Spalte STATE ausführen, sollten Sie vielleicht eine Verteilung anhand der Spalte STATE wählen. Das folgende Beispiel zeigt das Erstellen einer neuen Tabelle mit denselben Daten wie die Tabelle USERS, bei der der DISTKEY jedoch auf die Spalte STATE festgelegt wird. In diesem Fall ist die Verteilung nicht so gleichmäßig. Slice 0 (13.587 Zeilen) enthält ungefähr 30 % mehr Zeilen als Slice 3 (10.150 Zeilen). In einer sehr viel größeren Tabelle könnte sich diese Verteilungsverzerrung nachteilig auf die Abfrageverarbeitung auswirken.
```
create table userskey distkey(state) as select * from users;
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'userskey' and col=0 and rows>0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 13587 | 5 | 49989
1 | 0 | 11245 | 2 | 49990
2 | 0 | 15008 | 1 | 49976
3 | 0 | 10150 | 4 | 49986
(4 rows)
```
## Beispiel für DISTSTYLE EVEN
Wenn Sie eine neue Tabelle mit denselben Daten wie die Tabelle USERS erstellen, DISTSTYLE jedoch auf EVEN festlegen, werden die Zeilen stets gleichmäßig über die Slices verteilt.
```
create table userseven diststyle even as
select * from users;
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'userseven' and col=0 and rows>0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 12497 | 4 | 49990
1 | 0 | 12498 | 8 | 49984
2 | 0 | 12498 | 2 | 49988
3 | 0 | 12497 | 1 | 49989
(4 rows)
```
Da die Verteilung jedoch nicht auf einer spezifischen Spalte basiert, kann die Leistung der Abfrageverarbeitung nachlassen, besonders, wenn für die Tabelle ein Join mit anderen Tabellen ausgeführt wurde. Eine fehlende Verteilung anhand einer Join-Spalte wirkt sich häufig auf den Typ der Join-Operation aus, der effizient ausgeführt werden kann. Join-, Aggregations- und Gruppierungsoperationen sind optimiert, wenn beide Tabellen anhand der jeweiligen Join-Spalten verteilt und sortiert sind.
## Beispiel für DISTSTYLE ALL
Wenn Sie eine neue Tabelle mit denselben Daten wie die Tabelle USERS erstellen, DISTSTYLE jedoch auf ALL festlegen, werden alle Zeilen an den ersten Slice jedes Knotens verteilt.
```
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'usersall' and col=0 and rows > 0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 49990 | 4 | 49990
2 | 0 | 49990 | 2 | 49990
(4 rows)
```
# Sortierschlüssel
**Anmerkung**
Wir empfehlen, Ihre Tabellen mit `SORTKEY AUTO` zu erstellen. Wenn Sie dies tun, verwendet Amazon Redshift die automatische Tabellenoptimierung, um den Sortierschlüssel auszuwählen. Weitere Informationen finden Sie unter [Aktivieren automatischer Tabellenoptimierung](t_Creating_tables.md). Der Rest dieses Abschnitts enthält Details zur Sortierreihenfolge.
Wenn Sie eine Tabelle erstellen, können Sie alternativ eine oder mehrere ihrer Spalten als *Sortierschlüssel* definieren. Wenn Daten zum ersten Mal in die leere Tabelle geladen werden, werden die Zeilen auf dem Datenträger in sortierter Reihenfolge gespeichert. Die Informationen zu Sortierschlüsselspalten werden an den Abfrageplaner übergeben. Der Planer verwendet diese Informationen zum Erstellen von Plänen, die die Sortierung der Daten nutzen. Weitere Informationen finden Sie unter [CREATE TABLE](r_CREATE_TABLE_NEW.md). Informationen zu bewährten Methoden beim Erstellen eines Sortierschlüssels finden Sie unter [Auswahl des besten Sortierschlüssels](c_best-practices-sort-key.md).
Die Sortierung ermöglicht eine effiziente Verarbeitung von Prädikaten mit eingeschränkten Bereichen. Amazon Redshift speichert Spaltendaten in 1-MB-Blöcken. Die Mindest- und Maximalwerte für jeden Block werden als Teil der Metadaten gespeichert. Wenn eine Abfrage ein Prädikat mit eingeschränktem Bereich verwendet, kann der Abfrageverarbeiter die Mindest- und Maximalwerte verwenden, um während Tabellenscans große Mengen von Blöcken schnell zu überspringen. Angenommen, eine Tabelle speichert Daten aus fünf Jahren, die nach Datum sortiert sind, und eine Abfrage gibt einen Datumsbereich von einem Monat an. In diesem Fall können Sie bis zu 98 Prozent der Festplattenblöcke aus dem Scan entfernen. Wenn die Daten nicht sortiert sind, müssen mehr Datenträgerblöcke (möglicherweise alle) gescannt werden.
Sie können einen zusammengesetzten oder einen überlappenden Sortierschlüssel angeben. Ein zusammengesetzter Sortierschlüssel ist effizienter, wenn Abfrageprädikate ein *Präfix* verwenden, das ein Teilbereich der Sortierschlüsselspalten ihrer Reihenfolge nach ist. Ein überlappender Sortierschlüssel gewichtet jede Spalte im Sortierschlüssel gleich, sodass Abfrageprädikate jeden Teilbereich der Spalten, aus denen der Sortierschlüssel besteht, in jeder beliebigen Reihenfolge verwenden können.
Um die Auswirkungen des gewählten Sortierschlüssels auf die Abfrageleistung zu verstehen, verwenden Sie den Befehl [EXPLAIN](r_EXPLAIN.md). Weitere Informationen finden Sie unter [Workflow der Abfrageplanung und -ausführung](c-query-planning.md).
Um einen Sortiertyp zu definieren, verwenden Sie die Schlüsselwörter INTERLEAVED oder COMPOUND mit Ihrer CREATE TABLE- oder CREATE TABLE AS-Anweisung. Der Standard ist COMPOUND. COMPOUND wird empfohlen, wenn Ihre Tabellen regelmäßig mit INSERT-, UPDATE- oder DELETE-Operationen aktualisiert werden. Ein INTERLEAVED-Sortierschlüssel kann maximal acht Spalten verwenden. Je nach Daten und Cluster-Größe benötigt VACUUM REINDEX deutlich mehr Zeit als VACUUM FULL, da ein zusätzlicher Schritt zur Analyse der überlappenden Sortierschlüssel ausgeführt wird. Die Sortier- und Zusammenführungsoperation für überlappende Tabellen kann länger dauern, weil die überlappende Sortierung möglicherweise mehr Zeilen als eine zusammengesetzte Sortierung neu anordnen muss.
Um die Sortierschlüssel für eine Tabelle anzuzeigen, führen Sie eine Abfrage für die Systemansicht [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) aus.
**Topics**
+ [Multidimensionale Datenlayout-Sortierung](t_Sorting_mutidimensional-sort-key.md)
+ [Zusammengesetzter Sortierschlüssel](t_Sorting_data-compound.md)
+ [Überlappender Sortierungsschlüssel](t_Sorting_data-interleaved.md)
# Multidimensionale Datenlayout-Sortierung
Ein mehrdimensionaler Datenlayout-Sortierschlüssel ist eine Art AUTO-Sortierschlüssel, der auf sich wiederholenden Prädikaten basiert, die in einem Workload vorkommen. Wenn Ihr Workload sich wiederholende Prädikate enthält, kann Amazon Redshift die Tabellen-Scan-Leistung verbessern, indem Datenzeilen, die den sich wiederholenden Prädikaten entsprechen, gekoppelt werden. Anstatt die Daten einer Tabelle in strikter Spaltenreihenfolge zu speichern, speichert ein mehrdimensionaler Datenlayout-Sortierschlüssel Daten, indem er sich wiederholende Prädikate analysiert, die in einem Workload vorkommen. In einem Workload kann es mehr als ein sich wiederholendes Prädikat geben. Je nach Workload kann diese Art von Sortierschlüssel die Leistung vieler Prädikate verbessern. Amazon Redshift bestimmt automatisch, ob diese Sortierschlüsselmethode für Tabellen verwendet werden soll, die mit einem `AUTO`-Sortierschlüssel definiert sind.
Angenommen, Sie haben eine Tabelle, deren Daten in Spaltenreihenfolge sortiert sind. Möglicherweise müssen viele Datenblöcke untersucht werden, um festzustellen, ob sie den Prädikaten Ihres Workloads entsprechen. Wenn die Daten jedoch in Prädikatreihenfolge auf der Festplatte gespeichert sind, müssen weniger Blöcke gescannt werden, um die Abfrage durchzuführen. In diesem Fall ist die Verwendung eines mehrdimensionalen Datenlayout-Sortierschlüssels von Vorteil.
Informationen dazu, ob eine Abfrage einen mehrdimensionalen Datenlayoutschlüssel verwendet, finden Sie in der `step_attribute`-Spalte der [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md)-Ansicht. Wenn der Wert `multi-dimensional` ist, wurde ein mehrdimensionales Datenlayout für die Abfrage verwendet.
Um zu verhindern, dass Amazon Redshift einen mehrdimensionalen Sortierschlüssel für das Datenlayout verwendet, wählen Sie eine andere Tabellen-Sortierschlüsseloption als `SORTKEY AUTO`. Weitere Informationen zu SORTKEY-Optionen finden Sie unter [CREATE TABLE](r_CREATE_TABLE_NEW.md).
# Zusammengesetzter Sortierschlüssel
Ein zusammengesetzter Sortierschlüssel besteht aus allen in der Sortierschlüsseldefinition aufgelisteten Spalten in der Reihenfolge ihrer Auflistung. Ein zusammengesetzter Sortierschlüssel ist dann am nützlichsten, wenn der Filter einer Abfrage Bedingungen wie Filter und Joins anwendet, die ein Präfix der Sortierschlüssel verwenden. Die Leistungsvorteile einer Sortierung mit einem zusammengesetzten Schlüssel nehmen ab, wenn Abfragen ausschließlich von sekundären Sortierspalten abhängig sind, ohne dass die primären Spalten referenziert werden. Der Standardsortiertyp ist COMPOUND.
Zusammengesetzte Sortierschlüssel können Joins, GROUP BY- und ORDER BY-Operationen sowie Fensterfunktionen, die PARTITION BY und ORDER BY verwenden, beschleunigen. Beispielsweise kann ein Zusammenführungs-Join, der häufig schneller als ein Jash-Join ist, ausgeführt werden, wenn die Daten anhand der Join-Spalten verteilt und vorsortiert sind. Zusammengesetzte Sortierschlüssel können auch zur Verbesserung der Kompression beitragen.
Während Sie einer sortierten Tabelle Zeilen hinzufügen, die bereits Daten enthält, wächst die nicht sortierte Region. Dies wirkt sich deutlich auf die Leistung aus. Der Effekt ist größer, wenn die Tabelle eine überlappende Sortierung verwendet, besonders, wenn die Sortierspalten Daten enthalten, die monoton zunehmen, beispielsweise Datums- oder Zeitstempelspalten. Führen Sie regelmäßig eine VACUUM-Operation aus, besonders nach dem Laden großer Mengen von Daten, um die Daten neu zu sortieren und zu analysieren. Weitere Informationen finden Sie unter [Reduzieren der Größe der nicht sortierten Region](vacuum-managing-vacuum-times.md#r_vacuum_diskspacereqs). Nach der Bereinigung der Daten, um sie neu zu sortieren, stellt es eine bewährte Methode dar, einen -Befehl auszuführen, um die statistischen Metadaten für den Abfrageplaner zu aktualisieren. Weitere Informationen finden Sie unter [Analysieren von Tabellen](t_Analyzing_tables.md).
# Überlappender Sortierungsschlüssel
Eine überlappende Sortierung gewichtet alle Spalten oder Teilbereiche von Spalten im Sortierschlüssel gleich. Wenn verschiedene Abfragen verschiedene Spalten als Filter verwenden, können Sie die Leistung dieser Abfragen häufig verbessern, indem Sie einen überlappenden Sortierstil verwenden. Wenn eine Abfrage einschränkende Prädikate für sekundäre Sortierspalten verwendet, wird die Abfrageleistung durch die überlappende Sortierung im Vergleich zur zusammengesetzten Sortierung deutlich verbessert.
**Wichtig**
Verwenden Sie keinen überlappenden Sortierschlüssel in Spalten mit monoton ansteigenden Attributen, wie Identitätsspalten, Daten oder Zeitstempel.
Die Leistungsverbesserungen, die Sie durch die Implementierung eines überlappenden Sortierschlüssels erzielen, sollten mit den längeren Lade- und Bereinigungszeiten abgewogen werden.
Überlappende Sortierungen sind in Verbindung mit hoch selektiven Abfragen, die nach einem oder mehreren Sortierschlüsselspalten in der WHERE-Klausel filtern, am effektivsten, beispielsweise `select c_name from customer where c_region = 'ASIA'`. Die Vorteile der überlappenden Sortierung nehmen mit der Zahl der sortierten Spalten zu, die eingeschränkt wurden.
Eine überlappende Sortierung ist für große Tabellen effektiver. Die Sortierung wird auf jedes Slice angewendet. Daher ist eine überlappende Sortierung am effektivsten, wenn eine Tabelle groß genug ist, um mehrere 1-MB-Blöcke pro Slice zu beanspruchen. Hier kann der Abfrageprozessor einen erheblichen Teil der Blöcke mit restriktiven Prädikaten überspringen. Um die Zahl der von einer Tabelle verwendeten Blöcke anzuzeigen, führen Sie eine Abfrage für die Systemansicht [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) aus.
Beim Sortieren einer einzelnen Spalte kann eine überlappende Sortierung zu einer besseren Leistung als eine zusammengesetzte Sortierung führen, wenn die Spalten ein langes gemeinsames Präfix haben. Beginnen Sie beispielsweise URLs üblicherweise mit "http://www“. Zusammengesetzte Sortierschlüssel verwenden eine begrenzte Zahl von Zeichen aus dem Präfix, was zu zahlreichen duplizierten Schlüsseln führt. Überlappende Sortierungen verwenden ein internes Kompressionsschema für Zonenzuweisungswerte. Daher können sie Spaltenwerte besser unterscheiden, die ein langes gemeinsames Präfix haben.
Bei der Migration von Amazon Redshift bereitgestellter Cluster zu Amazon Redshift Serverless konvertiert Redshift Tabellen mit überlappenden Sortierschlüsseln und DISTSTYLE KEY in zusammengesetzte Sortierschlüssel. Tabellen nur mit verschachtelten Sortierschlüsseln bleiben jedoch unverändert. Weitere Informationen zu Verteilungsstilen finden Sie unter [Arbeiten mit Datenverteilungsstilen](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html).
**VACUUM REINDEX**
Während Sie einer sortierten Tabelle Zeilen hinzufügen, die bereits Daten enthält, kann die Leistung mit der Zeit nachlassen. Diese Verschlechterung tritt sowohl für zusammengesetzte als auch für überlappende Sortierungen auf, wirkt sich jedoch auf überlappende Tabellen stärker aus. Eine VACUUM-Operation stellt die Sortierreihenfolge wieder her. Die Operation kann jedoch im Fall von überlappenden Tabellen länger dauern, da die Zusammenführung neuer überlappender Daten bedeuten kann, dass jeder Datenblock geändert werden muss.
Wenn Tabellen zum ersten Mal geladen werden, analysiert Amazon Redshift die Verteilung der Werte in den Sortierschlüsselspalten und verwendet diese Informationen, um eine optimale Überlappung der Sortierschlüsselspalten zu erzielen. Mit zunehmender Größe der Tabelle kann sich die Verteilung der Werte in den Sortierschlüsselspalten verändern oder verzerren, besonders im Fall von Datums- oder Zeitstempelspalten. Wenn die Verzerrung zu groß wird, wirkt sich dies möglicherweise auf die Leistung aus. Um die Sortierschlüssel neu zu indizieren und die Leistung wiederherzustellen, führen Sie den Befehl VACUUM mit dem Schlüsselwort REINDEX aus. Da ein zusätzlicher Analysedurchgang für die Daten notwendig ist, kann VACUUM REINDEX im Fall überlappender Tabellen länger als eine VACUUM-Standardoperation dauern. Um Informationen zu Verzerrungen der Schlüsselverteilung und zum letzten Neuindizierungszeitpunkt anzuzeigen, führen Sie eine Abfrage für die Systemansicht [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) aus.
Weitere Informationen dazu, wie häufig VACUUM ausgeführt werden sollte und wann VACUUM REINDEX ausgeführt werden sollte, finden Sie unter [Entscheidung über eine Neuindizierung](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex).
# Tabelleneinschränkungen
Einschränkungen hinsichtlich Eindeutigkeit, Primärschlüssel und Fremdschlüssel dienen lediglich Informationszwecken. *Sie werden von Amazon Redshift nicht erzwungen*, wenn Sie eine Tabelle ausfüllen. Wenn Sie beispielsweise Daten in eine Tabelle mit Abhängigkeiten einfügen, kann der Einfügevorgang erfolgreich sein, auch wenn er gegen die Einschränkung verstößt. Dennoch werden Primärschlüssel und Fremdschlüssel als Planungshilfen verwendet und sollten deklariert werden, wenn Ihr ETL-Prozess oder ein anderer Prozess in Ihrer Anwendung ihre Integrität erzwingt.
Beispielsweise verwendet der Abfrageplaner Primär- und Fremdschlüssel in bestimmten statistischen Berechnungen. Dadurch sollen Eindeutigkeit und referentielle Beziehungen abgeleitet werden, die die Entkorrelierung von Unterabfragen beeinflussen. Somit können eine große Anzahl von Joins in Auftrag gegeben und redundante Joins entfernt werden.
Der Planer nutzt diese Schlüsselbeziehungen, nimmt jedoch an, dass alle Schlüssel in Amazon-Redshift-Tabellen wie geladen gültig sind. Wenn Ihre Anwendung ungültige Fremd- oder Primärschlüssel zulässt, könnten einige Abfragen falsche Ergebnisse zurückgeben. Beispielsweise kann eine SELECT DISTINCT-Abfrage duplizierte Zeilen zurückgeben, wenn der Primärschlüssel nicht eindeutig ist. Definieren Sie keine Schlüsseleinschränkungen für Ihre Tabellen, wenn Sie sich hinsichtlich ihrer Gültigkeit nicht sicher sind. Deklarieren Sie Einschränkungen hinsichtlich Primärschlüsseln, Fremdschlüsseln und Eindeutigkeit jedoch immer, wenn Sie wissen, dass sie gültig sind.
Amazon Redshift *erzwingt* NOT NULL-Spalteneinschränkungen.
Weitere Informationen zu diesen Tabelleneinschränkungen finden Sie unter [CREATE TABLE](r_CREATE_TABLE_NEW.md). Hinweise zum Entfernen einer Tabelle mit Abhängigkeiten finden Sie unter [DROP TABLE](r_DROP_TABLE.md).