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.

Empfehlungen für Amazon Redshift Advisor

Amazon Redshift Advisor bietet Empfehlungen über die Optimierung Ihres Amazon-Redshift-Clusters zum Steigern der Leistung und Sparen von Betriebskosten. Sie finden Erläuterungen für jede Empfehlung in der Konsole, wie vorstehend beschrieben. Sie finden weitere Details zu diesen Empfehlungen in den folgenden Abschnitten.

Komprimieren von Amazon-S3-Objekten, die über COPY geladen wurden

Der Befehl COPY nutzt die massive Parallelverarbeitungsarchitektur (Massively Parallel Processing, MPP) in Amazon Redshift, um Daten parallel zu lesen und zu laden. Der Befehl liest Dateien aus Amazon S3, DynamoDB-Tabellen und Textausgaben von einem oder mehreren Remotehosts.

Beim Laden von großen Datenmengen empfehlen wir dringend die Verwendung des COPY-Befehls zum Laden komprimierter Datendateien aus S3. Wenn Sie große Datensätze komprimieren, können Sie die Dateien schneller in Amazon S3 hochladen. COPY kann auch den Ladeprozess durch Dekomprimierung der Dateien während des Lesens beschleunigen.

Analyse

Lange laufende COPY-Befehle, die große, nicht komprimierte Datasets laden, bieten häufig die Möglichkeit einer erheblichen Leistungsverbesserung. Die Advisor-Analyse erkennt COPY-Befehle, die große, nicht komprimierte Datasets laden. In einem solchen Fall generiert Advisor eine Empfehlung zur Implementierung einer Komprimierung in den Quelldateien in Amazon S3.

Empfehlung

Stellen Sie sicher, dass jeder COPY-Vorgang, der eine erhebliche Datenmenge lädt oder über einen längeren Zeitraum ausgeführt wird, komprimierte Datenobjekte aus Amazon S3 übernimmt. Sie können herausfinden, welche COPY-Befehle große, unkomprimierte Datensätze aus Amazon S3 laden, indem Sie den folgenden SQL-Befehl als Superuser ausführen.

SELECT
    wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size) 
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;         
          

Falls die bereitgestellten Daten nach dem Laden in Amazon S3 verbleiben, was in Data-Lake-Architekturen üblich ist, können durch Speichern der Daten in komprimierter Form Ihre Speicherkosten gesenkt werden.

Implementierungstipps

Isolierung mehrerer aktiver Datenbanken

Als bewährte Methode empfehlen wir die Isolierung von Datenbanken in Amazon Redshift von einander. Abfragen werden in einer spezifischen Datenbank ausgeführt und können keine Daten von einer anderen Datenbank im Cluster aufrufen. Die Abfragen, die Sie in allen Datenbanken eines Clusters ausführen, verwenden jedoch denselben zugrunde liegenden Cluster-Speicherplatz und dieselben Datenverarbeitungsressourcen. Wenn ein einzelnes Cluster mehrere aktive Datenbanken enthält, sind ihre Workloads in der Regel nicht miteinander verbunden.

Analyse

Die Advisor-Analyse prüft alle Datenbanken im Cluster auf aktive Workloads, die gleichzeitig ausgeführt werden. Falls aktive Workloads gleichzeitig ausgeführt werden, generiert Advisor eine Empfehlung, über die Migration von Datenbanken in separate Amazon-Redshift-Cluster nachzudenken.

Empfehlung

Denken Sie über das Verschieben jeder aktiv abgefragten Datenbank in ein separates dediziertes Cluster nach. Die Verwendung eines separaten Clusters kann Ressourcenkonflikte reduzieren und die Abfrageleistung verbessern. Dies ist möglich, da Sie die Größe jedes Clusters entsprechend den Speicher-, Kosten- und Leistungsanforderungen des jeweiligen Workloads festlegen können. Zudem profitieren nicht verbundene Workloads häufig von verschiedenen Workload-Management-Konfigurationen.

Sie können den folgenden SQL-Befehl als Superuser ausführen, um zu ermitteln, welche Datenbanken aktiv verwendet werden.

SELECT database,
  COUNT(*) as num_queries,
  AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
  MIN(starttime) as oldest_ts,
  MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;            
         

Implementierungstipps

Neuzuordnung des Workload-Management- (WLM) Arbeitsspeichers

Amazon Redshift leitet Benutzerabfragen zur Verarbeitung an Implementieren von manuellem WLM weiter. Workload Management (WLM) legt fest, wie diese Abfragen zu den Warteschlangen geleitet werden. Amazon Redshift weist jeder Warteschlange einen Teil des verfügbaren Speicherplatzes des Clusters zu. Der Speicher einer Warteschlange wird unter den Abfrageslots der Warteschlange aufgeteilt.

Wenn eine Warteschlange mit mehr Slots konfiguriert ist, als der Workload benötigt, ist der Arbeitsspeicher, der diesen nicht verwendeten Slots zugewiesen ist, nicht ausgelastet. Durch Reduzieren der konfigurierten Slots und Anpassen an die Anforderungen der Spitzenworkloads wird jeglicher nicht ausgelasteter Arbeitsspeicher neu verteilt. Dies kann zu einer verbesserten Abfrageleistung führen.

Analyse

Die Advisor-Analyse prüft die Anforderungen an die Nebenläufigkeit des Workloads, um Abfragewarteschlangen mit ungenutzten Slots zu erkennen. Advisor generiert eine Empfehlung, um die Anzahl der Slots in einer Warteschlange zu reduzieren, wenn Folgendes gefunden wird:

Empfehlung

Durch die Reduzierung der konfigurierten Slots und Anpassung an die Anforderungen des Spitzenworkloads wird ungenutzter Arbeitsspeicher an aktive Slots neu verteilt. Denken Sie über eine Reduzierung der konfigurierten Slot-Anzahl für Warteschlangen nach, bei denen die Slots nie vollständig verwendet wurden. Um diese Warteschlangen zu ermitteln, können Sie die stündlichen Spitzenanforderungen an Slots für jede Warteschlange vergleichen, indem Sie den folgenden SQL-Befehl als Superuser ausführen.

WITH
 generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
 apex AS (
     SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
     FROM
         (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
         FROM stl_wlm_query wq
         JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
         JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
         WHERE wq.userid > 1 AND wq.service_class > 5) iq
     GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
     maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                     from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;            
         

Die max_service_class_slots-Spalte steht für die maximale Anzahl der WLM-Abfrageslots in der Abfragewarteschlange für diese Stunde. Falls nicht ausgelastete Warteschlangen vorhanden sind, implementieren Sie die Optimierung der Slot-Reduzierung durch Ändern einer Parametergruppe wie im Amazon-Redshift-Verwaltungshandbuch beschrieben.

Implementierungstipps

Überspringen der Komprimierungsanalyse während des COPY-Vorgangs

Beim Laden von Daten in eine leere Tabelle mit Komprimierungskodierung, die mit dem Befehl COPY deklariert war, übernimmt Amazon Redshift die Speicherkomprimierung. Diese Optimierung stellt sicher, dass Daten in Ihrem Cluster sogar effizient gespeichert werden, wenn sie von Endbenutzern geladen werden. Die erforderliche Analyse zur Anwendung der Komprimierung kann sehr zeitraubend sein.

Analyse

Die Advisor-Analyse prüft COPY-Operationen, die verzögert wurden, anhand einer automatischen Komprimierungsanalyse. Die Analyse bestimmt die Komprimierungskodierungen durch Analysieren der Daten, während sie geladen werden. Diese Analyse ist ähnlich wie die, die mit dem Befehl ANALYZE COMPRESSION ausgeführt wird.

Wenn Sie Daten als Teil eines strukturierten Prozesses laden, wie etwa bei einem ETL-Batch (Extrahieren, Transformieren, Laden) über Nacht, können Sie die Komprimierung vorab definieren. Sie können Ihre Tabellendefinitionen so optimieren, dass diese Phase dauerhaft ohne negative Auswirkungen übersprungen wird.

Empfehlung

Um die Reaktionsfähigkeit des COPY-Vorgangs durch Überspringen der Komprimierungsanalyse zu verbessern, implementieren Sie eine der folgenden beiden Optionen:

Die beste Lösung allgemein ist die Verwendung der Spaltenkodierung während des Erstellens der Tabelle, da dieser Ansatz auch den Vorteil des Speicherns komprimierter Daten auf dem Datenträger beibehält. Sie können den Befehl ANALYZE COMPRESSION verwenden, um Komprimierungskodierungen vorzuschlagen, aber müssen die Tabelle neu erstellen, um diese Kodierungen zu übernehmen. Um diesen Prozess zu automatisieren, können Sie das AWSColumnEncodingHilfsprogramm verwenden, das Sie unter finden GitHub.

Um die aktuellen COPY-Operationen zu ermitteln, die die automatische Komprimierungsanalyse ausgelöst haben, führen Sie den folgenden SQL-Befehl aus.

  WITH xids AS (
    SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 
    AND querytxt = 'analyze compression phase 1' GROUP BY xid
    INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, 
    a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) 
    starttime, substring(querytxt,1,100) as copy_sql, 
    ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') 
    AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid, 
    ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec 
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt like 'COPY ANALYZE %' 
    OR querytxt like 'analyze compression phase %') 
    GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;
         

Implementierungstipps

Teilen Sie Amazon-S3-Objekte mit dem Befehl COPY auf

Der Befehl COPY nutzt die massive Parallelverarbeitungsarchitektur (Massively Parallel Processing, MPP) in Amazon Redshift, um Daten aus Dateien in Amazon S3 zu lesen und zu laden. Der COPY-Befehl lädt die Daten in paralleler Weise aus mehreren Dateien und teilt dabei den Workload über die Knoten in Ihrem Cluster auf. Um einen optimalen Durchsatz zu erzielen, wird nachdrücklich empfohlen, die Daten in mehrere Dateien aufzuteilen, um die Vorteile der Parallelverarbeitung nutzen zu können.

Analyse

Bei der Advisor-Analyse werden COPY-Befehle erkannt, die große Datensätze laden, die in einer kleinen Anzahl von Dateien enthalten sind, die in Amazon S3 bereitgestellt wurden. Lange laufende COPY-Befehle, die große Datasets aus wenigen Dateien laden, bieten häufig die Möglichkeit einer erheblichen Leistungsverbesserung. Wenn Advisor erkennt, dass diese COPY-Befehle eine erhebliche Menge Zeit in Anspruch nehmen, wird die Empfehlung erstellt, die parallele Ausführung durch Aufteilen der Daten in zusätzliche Dateien in Amazon S3 zu verstärken.

Empfehlung

In diesem Fall empfehlen wir die folgenden Aktionen, aufgelistet in Reihenfolge ihrer Priorität:

Bestimmte COPY-Befehle laden eine erhebliche Datenmenge oder laufen sehr lang. Wir empfehlen, die Anzahl der aus Amazon S3 zu ladenden Datenobjekte so zu wählen, dass sie einem Vielfachen der Anzahl der Slices im Cluster entspricht. Um zu ermitteln, wie viele S3-Objekte der jeweilige COPY-Befehl geladen hat, führen Sie den folgenden SQL-Code als Superuser aus.

SELECT
    query, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;   
            
         

Implementierungstipps

Aktualisieren der Tabellenstatistik

Amazon Redshift verwendet eine kostenbasierte Abfrageoptimierung zur Auswahl eines optimalen Ausführungsplans für Abfragen. Die Kostenschätzungen basieren auf Tabellenstatistiken, die mit dem Befehl ANALYZE erfasst wurden. Wenn die Statistiken nicht mehr aktuell sind oder fehlen, wählt die Datenbank möglicherweise einen weniger effizienten Plan für die Abfrageausführung, insbesondere bei komplexen Abfragen. Wenn die Statistiken aktuell sind, hilft dies dabei, komplexe Abfragen in der kürzestmöglichen Zeit auszuführen.

Analyse

Die Advisor-Analyse verfolgt Tabellen, deren Statistiken vorhanden sind out-of-date oder fehlen. Der Advisor untersucht Metadaten zu Tabellenzugriffen bei komplexen Abfragen. Wenn der Advisor feststellt, dass Tabellen mit komplexen Zugriffsmustern keine Statistiken haben, gibt er eine kritische Empfehlung aus, ANALYZE auszuführen. Wenn Tabellen, auf die häufig mit komplexen Mustern zugegriffen wird, out-of-date Statistiken enthalten, schlägt Advisor vor, ANALYZE auszuführen.

Empfehlung

Immer wenn sich der Inhalt einer Tabelle erheblich ändert, sollten Sie die Statistiken mit ANALYZE aktualisieren. Wir empfehlen die Ausführung von ANALYZE, wenn eine große Anzahl neuer Datenzeilen mit dem COPY- oder dem INSERT-Befehl in eine vorhandene Tabelle geladen wird. Wir empfehlen zudem die Ausführung von ANALYZE, wenn eine erhebliche Anzahl von Zeilen mit dem UPDATE- oder dem DELETE-Befehl modifiziert wird. Um Tabellen mit fehlenden oder out-of-date statistischen Daten zu identifizieren, führen Sie den folgenden SQL-Befehl als Superuser aus. Die Ergebnisse werden von der größten zur kleinsten Tabelle sortiert.

Um Tabellen mit fehlenden oder out-of-date statistischen Daten zu identifizieren, führen Sie den folgenden SQL-Befehl als Superuser aus. Die Ergebnisse werden von der größten zur kleinsten Tabelle sortiert.

SELECT
   ti.schema||'.'||ti."table" tablename,
   ti.size table_size_mb,
   ti.stats_off statistics_accuracy
 FROM svv_table_info ti
 WHERE ti.stats_off > 5.00
 ORDER BY ti.size DESC;          
         

Implementierungstipps

Der Standardschwellenwert für ANALYZE ist 10 Prozent. Dieser Standardwert bedeutet, dass der ANALYZE-Befehl eine vorhandene Tabelle überspringt, wenn weniger als 10 Prozent der Tabellenzeilen seit dem letzten ANALYZE-Vorgang geändert wurden. Daher können Sie am Ende jedes ETL-Prozesses wählen, ob ANALYZE-Befehle ausgeführt werden sollen. Dieser Ansatz beinhaltet, dass der Befehl ANALYZE häufig übersprungen wird, aber sichergestellt ist, dass er bei Bedarf ausgeführt wird.

ANALYZE-Statistiken haben die größten Auswirkungen auf Spalten, die in Joins verwendet werden (Beispiel: JOIN tbl_a ON col_b) oder als Prädikate (Beispiel: WHERE col_b = 'xyz'). Standardmäßig erfasst ANALYZE Statistiken für alle in der Tabelle angegebenen Spalten. Bei Bedarf können Sie die erforderliche Zeit zum Ausführen von ANALYZE reduzieren, indem Sie ANALYZE nur für die Spalten mit den größten Auswirkungen ausführen. Sie können den folgenden SQL-Befehl ausführen, um Spalten zu ermitteln, die als Prädikate verwendet werden. Sie können auch Amazon Redshift wählen lassen, welche Spalten analysiert werden sollen, indem Sie angeben ANALYZE PREDICATE COLUMNS.

WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

Weitere Informationen finden Sie unter Analysieren von Tabellen.

Aktivieren von Short Query Acceleration

Wenn Sie Short Query Acceleration (SQA) verwenden, werden ausgewählte, kurze Abfragen gegenüber Abfragen mit einer höheren Dauer priorisiert. SQA führt kurze Abfragen an einer dedizierten Stelle aus, sodass SQA-Abfragen nicht hinter längeren Abfragen in Warteschlangen eingereiht werden. SQA priorisiert nur Warteschlangen, die über eine kurze Zeit ausgeführt werden und sich in einer benutzerdefinierten Warteschlange befinden. Mit SQA werden kürzere Abfragen schneller ausgeführt und der Benutzer sieht schneller Ergebnisse.

Wenn Sie SQA aktivieren, können Sie dedizierte Workload Management (WLM)-Warteschlangen für kurze Anfragen reduzieren oder ganz abschaffen. Außerdem konkurrieren lange Abfragen nicht mit kurzen Abfragen um Slots in einer Warteschlange, daher können Sie Ihre WLM-Warteschlangen mit weniger Abfrage-Slots konfigurieren. Wenn Sie einen niedrigeren Nebenläufigkeitswert verwenden, wird bei den meisten Arbeitslasten der Abfragedurchsatz erhöht und die gesamte Systemleistung verbessert. Weitere Informationen finden Sie unter Arbeiten mit Short Query Acceleration.

Analyse

Der Advisor sucht nach Workloadmustern und meldet die Anzahl kürzlich ausgeführter Abfragen, bei denen SQA die Latenz und die Tages-Warteschlangendauer für SQA-qualifizierte Abfragen reduzieren würde.

Empfehlung

Ändern Sie die WLM-Konfiguration, um SQA zu aktivieren. Amazon Redshift verwendet einen Machine-Learning-Algorithmus, um berechtigte Abfragen zu analysieren. Voraussagen werden in dem Maße besser, in dem SQA aus den Abfragemustern lernt. Weitere Informationen finden Sie unter Workload-Management-Konfiguration.

Wenn Sie SQA aktivieren, legt WLM die maximale Ausführungszeit für kurze Abfragen standardmäßig als „dynamisch“ fest. Sie sollten die dynamische Einstellung für die maximale SQA-Laufzeit beibehalten.

Implementierungstipps

Führen Sie die folgende Abfrage aus, um zu überprüfen, ob SQA aktiviert ist. Wenn für die Abfrage eine Zeile zurückgegeben wird, ist SQA aktiviert.

select * from stv_wlm_service_class_config 
where service_class = 14;

Weitere Informationen finden Sie unter SQA-Überwachung.

Ändern der Verteilungsschlüssel in Tabellen

Amazon Redshift verteilt Tabellenzeilen im Cluster gemäß des Verteilungsstils der Tabelle. In Tabellen mit KEY-Verteilung muss eine Spalte als Verteilungsschlüssel (DISTKEY) gekennzeichnet sein. Eine Tabellenzeile wird einem Knoten-Slice eines Clusters basierend auf dessen DISTKEY-Spaltenwert zugewiesen.

Ein passender DISTKEY platziert eine vergleichbare Anzahl an Zeilen in jedem Knoten-Slice und wird regelmäßig in Join-Bedingungen referenziert. Ein optimierter Join tritt auf, wenn Tabellen anhand ihrer DISTKEY-Spalten verbunden werden, um die Abfrageleistung zu erhöhen.

Analyse

Advisor analysiert den Workload Ihres Clusters, um den geeignetsten Verteilungsschlüssel für die Tabellen zu finden, der erheblich von einem KEY-Verteilungsstil profitieren kann.

Empfehlung

Advisor stellt ALTER TABLE Anweisungen bereit, die die Werte DISTSTYLE und DISTKEY einer Tabelle basierend auf deren Analyse anpassen. Um einen erheblichen Leistungsvorteil zu erzielen, müssen alle SQL-Anweisungen innerhalb einer Empfehlungsgruppe implementiert werden.

Die Neuverteilung großer Tabellen mit ALTER TABLE verbraucht Cluster-Ressourcen, außerdem muss die Tabelle an verschiedenen Zeitpunkten kurzfristig gesperrt werden. Implementieren Sie die jeweiligen Empfehlungsgruppen, wenn der sonstige Workload im Cluster gering ist. Weitere Informationen zur Optimierung der Tabellenverteilungseigenschaften finden Sie unter Amazon Redshift Engineering's Advanced Table Design Playbook: Distribution Styles and Distribution Keys.

Weitere Informationen zu ALTER DISTSTYLE und DISTKEY finden Sie unter ALTER TABLE.

Ändern der Sortierschlüssel für Tabellen

Amazon Redshift sortiert Tabellenzeilen nach dem Tabellensortierschlüssel. Die Sortierung der Tabellenzeilen basiert auf den Sortierschlüsselspaltenwerten.

Das Sortieren einer Tabelle mit einem geeigneten Sortierschlüssel kann die Leistung von Abfragen beschleunigen, insbesondere solche mit bereichsbeschränkten Prädikaten, da weniger Tabellenblöcke von der Festplatte gelesen werden müssen.

Analyse

Advisor analysiert die Workload Ihres Clusters über mehrere Tage, um einen vorteilhaften Sortierschlüssel für Ihre Tabellen zu identifizieren.

Empfehlung

Advisor stellt zwei Gruppen von ALTER TABLE-Anweisungen bereit, die den Sortierschlüssel einer Tabelle basierend auf ihrer Analyse ändern:

Beim Sortieren einer großen Tabelle mit ALTER TABLE werden Clusterressourcen belegt und zu unterschiedlichen Zeitpunkten sind Tabellensperren erforderlich. Implementieren Sie jede Empfehlung, wenn die Workload eines Clusters moderat ist. Weitere Details zur Optimierung von Tabellensortierschlüsselkonfigurationen finden Sie im Amazon Redshift Engineering's Advanced Table Design Playbook: Compound and Interleaved Sort Keys.

Weitere Informationen zu ALTER SORTKEY finden Sie im Abschnitt ALTER TABLE.

Ändern der Komprimierungskodierungen für Spalten

Komprimierung ist eine Operation auf Spaltenebene, die die Größe von Daten reduziert, wenn sie gespeichert werden. Die Komprimierung wird in Amazon Redshift verwendet, um Speicherplatz zu sparen und die Abfrageleistung zu verbessern, indem die Menge an Festplatten-I/O reduziert wird. Wir empfehlen eine optimale Komprimierungskodierung für jede Spalte basierend auf ihrem Datentyp und auf Abfragemustern. Bei optimaler Komprimierung können Abfragen effizienter ausgeführt werden und die Datenbank beansprucht nur wenig Speicherplatz.

Analyse

Advisor führt kontinuierlich eine Analyse der Workload und des Datenbankschemas Ihres Clusters durch, um die optimale Komprimierungskodierung für jede Tabellenspalte zu ermitteln.

Empfehlung

Advisor stellt ALTER-TABLE-Anweisungen bereit, die die Komprimierungskodierung bestimmter Spalten basierend auf ihrer Analyse ändern.

Ändern der Spaltenkomprimierungskodierungen mit ALTER TABLE verbraucht Clusterressourcen und erfordert Tabellensperren zu verschiedenen Zeitpunkten. Implementieren Sie am besten Empfehlungen, wenn der Workload im Cluster leicht ausfällt.

Als Referenz zeigt Beispiele für ALTER TABLE mehrere Anweisungen an, die die Kodierung für eine Spalte ändern.

Datentyp-Empfehlungen

Amazon Redshift verfügt über eine Bibliothek mit SQL-Datentypen für verschiedene Anwendungsfälle. Dazu gehören ganzzahlige Typen wie INT und Typen zum Speichern von Zeichen wie VARCHAR. Redshift speichert Typen optimiert, um einen schnelleren Zugriff und eine gute Abfrageleistung zu ermöglichen. Redshift bietet außerdem Funktionen für bestimmte Typen, mit denen Sie Berechnungen für Abfrageergebnisse formatieren oder durchführen können.

Analyse

Advisor führt kontinuierlich eine Analyse der Workload und des Datenbankschemas Ihres Clusters durch, um Spalten zu ermitteln, die erheblich von einer Datentypänderung profitieren können.

Empfehlung

Advisor bietet eine ALTER TABLE-Anweisung, die eine neue Spalte mit dem vorgeschlagenen Datentyp hinzufügt. Eine begleitende UPDATE-Anweisung kopiert Daten aus der vorhandenen Spalte in die neue Spalte. Nachdem Sie die neue Spalte erstellt und die Daten geladen haben, ändern Sie Ihre Abfragen und Erfassungsskripte, um auf die neue Spalte zuzugreifen. Nutzen Sie dann Ressourcen und Funktionen, die auf den neuen Datentyp spezialisiert sind, in SQL-Funktionsreferenz.

Das Kopieren vorhandener Daten in die neue Spalte kann einige Zeit dauern. Wir empfehlen Ihnen, jede Advisor-Empfehlung zu implementieren, wenn die Workload des Clusters leicht ist. Verweisen Sie auf die Liste der verfügbaren Datentypen unter Datentypen.

Beachten Sie, Advisor gibt keine Empfehlungen, wenn nicht genügend Daten vorhanden sind oder der erwartete Nutzen der Veränderung des Datentyps gering ist.