Leistung

Amazon Redshift erzielt eine extrem schnelle Abfrageausführung mithilfe der folgenden Leistungsfunktionen.

Massiv parallele Verarbeitung

Die massiv parallele Verarbeitung (Massively Parallel Processing, MPP) ermöglicht die schnelle Ausführung äußerst komplexer Abfragen für sehr große Datenmengen. Mehrere Datenverarbeitungsknoten führen die gesamte Abfrageverarbeitung bis zur abschließenden Aggregation der Ergebnisse aus. Jeder Kern eines jeden Knotens führt dabei dieselben kompilierten Abfragesegmente auf Teilen der gesamten Daten aus.

Amazon Redshift verteilt die Zeilen einer Tabelle an die Datenverarbeitungsknoten, sodass die Daten parallel verarbeitet werden können. Durch die Auswahl eines geeigneten Verteilungsschlüssels für die einzelnen Tabellen können Sie die Verteilung der Daten optimieren, um den Workload auszugleichen und die Bewegung der Daten von Knoten zu Knoten zu verringern. Weitere Informationen finden Sie unter Auswahl des besten Verteilungsstils.

Das Laden von Daten aus Flat-Dateien nutzt die parallele Verarbeitung, indem der Workload auf mehrere Knoten verteilt und gleichzeitig aus mehreren Dateien gelesen wird. Weitere Informationen zum Laden von Daten in Tabellen finden Sie unter Bewährte Methoden für Amazon Redshift zum Laden von Daten.

Spaltenweise Datenspeicherung

Die spaltenweise Speicherung für Datenbanktabellen sorgt für eine drastische Reduzierung der allgemeinen Datenträger-I/O-Anforderungen und stellt einen wichtigen Faktor im Zusammenhang mit der Optimierung der Leistung analytischer Abfragen dar. Die spaltenweise Speicherung von Datenbanktabellen-Daten reduziert die Anzahl von Datenträger-I/O-Anfragen sowie die Menge an Daten, die Sie von der Festplatte laden müssen. Das Laden von weniger Daten in den Arbeitsspeicher ermöglicht Amazon Redshift, beim Ausführen von Abfragen weniger In-Memory-Verarbeitung auszuführen. Eine detaillierte Erläuterung finden Sie unter Spaltenweise Speicherung.

Wenn Spalten angemessen sortiert werden, kann der Abfrageverarbeiter schnell einen großen Teil von Datenblöcken herausfiltern. Weitere Informationen finden Sie unter Auswahl des besten Sortierschlüssels.

Datenkompression

Datenkompression reduziert die Speicheranforderungen und somit die Datenträger-I/O, wodurch die Abfrageleistung verbessert wird. Wenn Sie eine Abfrage ausführen, werden die komprimierten Daten in den Arbeitsspeicher gelesen und anschließend während der Abfrageausführung dekomprimiert. Das Laden von weniger Daten in den Arbeitsspeicher ermöglicht Amazon Redshift, mehr Arbeitsspeicher zum Analysieren der Daten zuzuordnen. Da bei der spaltenweisen Speicherung ähnliche Daten sequenziell gespeichert werden, kann Amazon Redshift Codierungen für adaptive Komprimierungen anwenden, die speziell mit spaltenweisen Datentypen verbunden sind. Die beste Möglichkeit, Datenkomprimierung in Tabellenspalten zu aktivieren, besteht darin, Amazon Redshift zu gestatten, optimale Komprimierungskodierungen anzuwenden, wenn die Tabelle mit Daten geladen wird. Weitere Informationen zur Verwendung der automatischen Datenkompression erhalten Sie unter Laden von Tabellen mit automatischer Kompression.

Abfragenoptimierer

Die Abfrageausführungs-Engine von Amazon Redshift enthält einen Abfragenoptimierer, der MPP-fähig ist und die spaltenweise Datenspeicherung nutzt. Der Abfragenoptimierer von Amazon Redshift implementiert wesentliche Verbesserungen und Erweiterungen für die Verarbeitungen komplexer Analyseabfragen, die oft Mehrtabellen-Joins, Unterabfragen und Aggregation beinhalten. Weitere Informationen zur Optimierung von Abfragen finden Sie unter Optimieren der Abfrageleistung.

Ergebnis-Zwischenspeicherung

Um die Laufzeit von Abfragen zu reduzieren und die Systemleistung zu verbessern, stellt Amazon Redshift die Ergebnisse bestimmter Abfragetypen in den Speicher auf dem Führungsknoten. Wenn ein Benutzer eine Abfrage stellt, durchsucht Amazon Redshift den Ergebnis-Cache nach einer gültigen, zwischengespeicherten Kopie der Abfrageergebnisse. Wenn im Ergebnis-Cache ein passender Datensatz gefunden wird, verwendet Amazon Redshift die zwischengespeicherten Ergebnisse und führt die Abfrage nicht aus. Die Ergebnis-Zwischenspeicherung ist transparent für den Benutzer.

Die Ergebnis-Zwischenspeicherung ist standardmäßig aktiviert. Um die Ergebnis-Zwischenspeicherung für die aktuelle Sitzung zu deaktivieren, setzen Sie den Parameter enable_result_cache_for_session auf off.

Amazon Redshift verwendet für eine neue Abfrage zwischengespeicherte Ergebnisse, wenn die folgenden Dinge zutreffen:

• Der Benutzer, der die Abfrage absetzt, besitzt Zugriffsberechtigung für die in der Abfrage verwendeten Objekte.

• Die Tabelle oder die Ansichten in der Abfrage wurden nicht verändert.

• Die Abfrage verwendet keine Funktion, die bei jeder Ausführung überprüft werden muss, wie beispielsweise GETDATE.

• Die Abfrage verweist nicht auf externe Tabellen von Amazon Redshift Spectrum.

• Konfigurationsparameter, die sich auf die Abfrageparameter auswirken könnten, sind unverändert.

• Die Abfrage stimmt syntaktisch mit der zwischengespeicherten Abfrage überein.

Um die Effektivität der Zwischenspeicherung und die effiziente Nutzung der Ressourcen zu maximieren, speichert Amazon Redshift einige große Datensätze von Abfrageergebnissen nicht zwischen. Amazon Redshift stellt anhand verschiedener Faktoren fest, ob Abfrageergebnisse zwischengespeichert werden sollen. Zu diesen Faktoren zählen unter anderem die Anzahl der Einträge im Cache sowie der Instance-Typ Ihres Amazon-Redshift-Clusters.

Um festzustellen, ob eine Abfrage die Ergebnis-Zwischenspeicherung genutzt hat, rufen Sie die Systemansicht SVL_QLOG auf. Wenn eine Abfrage die Ergebniszwischenspeicherung verwendet hat, gibt die Spalte source_query die Abfrage-ID der Quellabfrage zurück. Wenn keine Ergebniszwischenspeicherung verwendet wurde, ist der Wert der Spalte source_query gleich NULL.

Das folgende Beispiel zeigt, dass die von der userid 104 und der userid 102 gestellten Abfragen die Abfragen von der userid 100 aus dem Ergebnis-Zwischenspeicher verwenden.

select userid, query, elapsed, source_query from svl_qlog 
where userid > 1
order by query desc;

userid | query  | elapsed  | source_query
-------+--------+----------+-------------
   104 | 629035 |       27 |       628919
   104 | 629034 |       60 |       628900
   104 | 629033 |       23 |       628891
   102 | 629017 |  1229393 |             
   102 | 628942 |       28 |       628919
   102 | 628941 |       57 |       628900
   102 | 628940 |       26 |       628891
   100 | 628919 | 84295686 |             
   100 | 628900 | 87015637 |             
   100 | 628891 | 58808694 |             

Kompilierter Code

Der Führungsknoten verteilt vollständig optimierten kompilierten Code auf die Knoten eines Clusters. Durch das Kompilieren der Abfrage verringert sich der mit einem Interpreter verbundene Verwaltungsaufwand, wodurch insbesondere bei komplexen Abfragen eine höhere Laufzeitgeschwindigkeit erzielt wird. Der kompilierte Code wird im Cache gespeichert und von mehreren Sitzungen auf demselben Cluster gemeinsam verwendet. Zukünftige Ausführungen derselben Abfrage können somit schneller erfolgen – häufig sogar mit verschiedenen Parametern.

Die Abfrageausführungs-Engine kompiliert unterschiedlichen Code für die JDBC- und ODBC-Verbindungsprotokolle, sodass für zwei Clients, die verschiedene Protokolle verwenden, jeweils Kosten anfallen, wenn zum ersten Mal Code kompiliert wird. Clients, die dasselbe Protokoll verwenden, profitieren dann jedoch wieder von dem im Cache verfügbaren Code.