Parallele Abfrage für Amazon Aurora My SQL - Amazon Aurora
Übersicht über Parallel Query

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.

Parallele Abfrage für Amazon Aurora My SQL

In diesem Thema wird die Leistungsoptimierung für parallel Abfragen für Amazon Aurora My SQL -Compatible Edition beschrieben. Diese Funktion verwendet für bestimmte datenintensive Abfragen einen speziellen Verarbeitungspfad. Dabei kommt zum Tragen, dass die Architektur von Aurora verschiedene Speicherquellen nutzt. Parallele Abfragen funktionieren am besten mit Aurora My SQL DB-Clustern, die Tabellen mit Millionen von Zeilen und Analyseabfragen haben, deren Fertigstellung Minuten oder Stunden dauert.

Themen

Überblick über die parallel Abfrage für Aurora My SQL

Aurora Meine SQL parallel Abfrage ist eine Optimierung, die einen Teil der I/O und der Berechnungen, die bei der Verarbeitung datenintensiver Abfragen anfallen, parallelisiert. Die parallelisierten Vorgänge beinhalten das Abrufen von Zeilen aus dem Speicher, das Extrahieren von Spaltenwerten und das Bestimmen der Zeilen, die den Bedingungen der WHERE-Klausel und der JOIN-Klauseln entsprechen. Diese datenintensive Arbeit wird auf der Ebene des verteilten Speichers von Aurora an mehrere Knoten in der verteilten Speicherschicht delegiert (aus Datenbanksicht herabgestuft). Ohne parallel Abfrage bringt jede Abfrage alle gescannten Daten auf einen einzelnen Knoten innerhalb des Aurora SQL My-Clusters (den Hauptknoten) und führt dort die gesamte Abfrageverarbeitung durch.

Tipp

Die SQL Postgre-Datenbank-Engine verfügt auch über eine Funktion namens „parallel Abfrage“. Diese Funktion steht in keinem Zusammenhang mit der parallelen Abfrage von Aurora.

Wenn die Funktion für parallel Abfragen aktiviert ist, bestimmt die Aurora My SQL Engine automatisch, wann Abfragen von Nutzen sein können, ohne dass SQL Änderungen wie Hinweise oder Tabellenattribute erforderlich sind. In den folgenden Abschnitten lesen Sie, in welchen Fällen Abfragen parallelisiert werden. Dabei erfahren Sie auch, wie Parallelabfragen nur dann eingesetzt werden, wenn sie den größten Nutzen bringen.

Anmerkung

Die Funktion für die Optimierung der parallelen Abfrageausführung ist besonders bei Abfragen sinnvoll, die mehrere Minuten oder Stunden in Anspruch nehmen. Aurora My führt SQL im Allgemeinen keine parallel Abfrageoptimierung für kostengünstige Abfragen durch. Es führt auch im Allgemeinen keine parallele Abfrageoptimierung durch, wenn ein anderes Optimierungsverfahren geeigneter wäre (z. B. Abfrage-Caching, Caching im Bufferpool oder Index-Lookups). Wenn Sie der Meinung sind, dass die parallele Abfrageausführung anders als erwartet angewendet wird, lesen Sie den Abschnitt Überprüfen, welche Anweisungen die parallel Abfrage für Aurora My verwenden SQL.

Vorteile

Mit parallel Abfragen können Sie datenintensive Analyseabfragen für Aurora My-Tabellen ausführen. SQL In vielen Fällen können Sie eine order-of-magnitude Leistungsverbesserung gegenüber der herkömmlichen Arbeitsteilung bei der Abfrageverarbeitung erzielen.

Vorteile der parallelen Abfrageausführung:

  • Höhere I/O-Leistung, weil physische Leseanforderungen auf mehrere Speicherknoten parallelisiert werden.

  • Reduzierter Netzwerkverkehr. Aurora überträgt nicht komplette Datenseiten von den Speicherknoten zum Hauptknoten, um dort überflüssige Zeilen und Spalten herauszufiltern. Aurora überträgt stattdessen kompakte Tupel, die nur die Spaltenwerte enthalten, die für den Ergebnissatz erforderlich sind.

  • Reduzierte CPU Auslastung des Hauptknotens, da die Funktionsverarbeitung, die Zeilenfilterung und die Spaltenprojektion für die WHERE Klausel nach unten verschoben wurden.

  • Weniger Speicherdruck im Bufferpool. Die von der parallelen Abfrage verarbeiteten Seiten werden dem Bufferpool nicht hinzugefügt. Dieser Ansatz reduziert die Wahrscheinlichkeit, dass ein datenintensiver Scan häufig verwendete Daten aus dem Bufferpool entfernt.

  • Potenziell verringerte sich die Datenduplizierung in Ihrer Extraktions-, Transformations- und Load (ETL) -Pipeline, da es praktisch ist, lang andauernde analytische Abfragen an vorhandenen Daten durchzuführen.

Architektur

Die Funktion für parallel Abfragen nutzt die wichtigsten Architekturprinzipien von Aurora MySQL: Entkopplung der Datenbank-Engine vom Speichersubsystem und Reduzierung des Netzwerkverkehrs durch Rationalisierung der Kommunikationsprotokolle. Aurora My SQL verwendet diese Techniken, um schreibintensive Operationen wie die Redo-Log-Verarbeitung zu beschleunigen. Parallel Query wendet die gleichen Prinzipien auf Leseoperationen an.

Anmerkung

Die Architektur von Aurora My SQL Parallel Query unterscheidet sich von der Architektur ähnlich benannter Funktionen in anderen Datenbanksystemen. Aurora Meine SQL parallel Abfrage beinhaltet kein symmetrisches Multiprocessing (SMP) und ist daher nicht von der CPU Kapazität des Datenbankservers abhängig. Die Parallelverarbeitung erfolgt in der Speicherschicht, unabhängig vom Aurora SQL My-Server, der als Abfragekoordinator dient.

Ohne eine Parallelabfrage beinhaltet die Verarbeitung einer Aurora-Abfrage standardmäßig die Übertragung von Rohdaten an einen Einzelknoten innerhalb des Aurora-Clusters (dem Hauptknoten). Aurora führt dann die gesamte weitere Verarbeitung für diese Abfrage in einem einzigen Thread auf diesem einzelnen Knoten durch. Bei parallel Abfragen wird ein Großteil dieser I/O-intensiven und CPU -intensiven Arbeit an Knoten in der Speicherschicht delegiert. Nur die kompakten Zeilen aus dem Ergebnissatz werden an den Hauptknoten zurück übertragen. Die Zeilen sind dann bereits gefiltert und die Spaltenwerte bereits extrahiert und umgewandelt. Der Leistungsvorteil ergibt sich aus der Reduzierung des Netzwerkverkehrs, der geringeren CPU Auslastung auf dem Hauptknoten und der Parallelisierung der I/O zwischen den Speicherknoten. Wie viele E/A-Vorgänge, Filterungen und Projektionen parallel ablaufen, ist unabhängig von der Anzahl der DB-Instances im Aurora-Cluster, der die Abfrage ausführt.

Voraussetzungen

Um alle Funktionen von Parallel Query nutzen zu können, ist ein Aurora My SQL DB-Cluster erforderlich, auf dem Version 2.09 oder höher ausgeführt wird. Wenn Sie bereits einen Cluster haben, den Sie mit der parallelen Abfrage verwenden möchten, können Sie ihn auf eine kompatible Version aktualisieren und anschließend die parallele Abfrage einschalten. Stellen Sie in diesem Fall sicher, dass Sie das Upgrade-Verfahren unter Wichtige Punkte bei einem Upgrade für parallele Abfragen befolgen, da die Namen der Konfigurationseinstellungen und Standardwerte in diesen neueren Versionen unterschiedlich sind.

Die DB-Instances in Ihrem Cluster müssen die db.r*-Instance-Klassen verwenden.

Stellen Sie sicher, dass die Hash-Join-Optimierung für Ihren Cluster aktiviert ist. Um zu erfahren wie dies geht, vgl. Hash-Join für parallele Abfrage-Cluster aktivieren.

Zum Anpassen von Parametern wie aurora_parallel_query und aurora_disable_hash_join benötigen Sie eine benutzerdefinierte Parametergruppe, die Sie mit dem Cluster verwenden. Sie können diese Parameter für jede DB-Instance einzeln angeben, indem Sie eine DB-Parametergruppe verwenden. Es wird jedoch empfohlen, sie in einer DB-Cluster-Parametergruppe anzugeben. Auf diese Weise übernehmen alle DB-Instances in Ihrem Cluster die gleichen Einstellungen für diese Parameter.

Einschränkungen

Parallele Abfragen unterliegen folgenden Einschränkungen:

  • Parallelabfragen werden mit der DB-Cluster-Speicherkonfiguration Aurora I/O-Optimized nicht unterstützt.

  • Sie können eine parallele Abfrage nicht mit den Instance-Klassen db.t2 oder db.t3 verwenden. Diese Einschränkung gilt auch dann, wenn Sie eine Parallelabfrage mit dem SQL-Hinweis aurora_pq_force anfordern.

  • Die parallele Abfrage gilt nicht für Tabellen, die das Zeilenformat COMPRESSED oder REDUNDANT verwenden. Verwenden Sie die Zeilenformate COMPACT oder DYNAMIC für Tabellen, die Sie mit der parallelen Abfrage verwenden möchten.

  • Aurora verwendet einen kostenbasierten Algorithmus, um zu bestimmen, ob der parallel Abfragemechanismus für jede SQL Anweisung verwendet werden soll. Die Verwendung bestimmter SQL Konstrukte in einer Anweisung kann parallel Abfragen verhindern oder eine parallel Abfrage für diese Anweisung unwahrscheinlich machen. Hinweise zur Kompatibilität von SQL Konstrukten mit parallel Abfragen finden Sie unterSQLKonstrukte für parallel Abfragen in Aurora My SQL.

  • Jede Aurora-DB-Instance kann nur eine bestimmte Anzahl Parallelabfrage-Sitzungen gleichzeitig leisten. In Abfragen, die mehrere Komponenten mit paralleler Abfrageausführung enthalten (z. B. Unterabfragen, Join-Abfragen oder UNION-Operatoren), werden diese Phasen nacheinander ausgeführt. Die Anweisung zählt stets nur als einzelne Parallelabfrage-Sitzung. Wenn Sie überwachen möchten, wie viele Sitzungen derzeit geöffnet sind, verwenden Sie die Parallel-Query-Statusvariablen. Um herauszufinden, wie viele gleichzeitige Sitzungen eine DB-Instance maximal zulässt, fragen Sie die Statusvariable a Aurora_pq_max_concurrent_requests.

  • Parallele Abfragen sind in allen AWS Regionen verfügbar, die Aurora unterstützt. In den meisten AWS Regionen ist mindestens SQL Version 2.09 von Aurora My für die Verwendung parallel Abfragen erforderlich.

  • Parallelabfragen wurden entwickelt, um die Leistung datenintensiver Abfragen zu verbessern. Diese Funktion ist nicht für einfache Abfragen konzipiert.

  • Wir empfehlen, Reader-Nodes für SELECT Anweisungen zu verwenden, insbesondere für datenintensive Anweisungen.

I/O-Kosten bei Parallelabfragen

Wenn Ihr Aurora My SQL Cluster parallel Abfragen verwendet, stellen Sie möglicherweise einen Anstieg der VolumeReadIOPS Werte fest. Parallel Query verwendet den Bufferpool nicht. Obwohl die Abfragen schnell sind, kann diese optimierte Verarbeitung zu einem Anstieg der Lesevorgänge und der damit verbundenen Gebühren führen.

Die I/O-Kosten für parallele Abfragen werden für Ihre Abfrage auf der Speicherebene gemessen und sind gleich oder höher, wenn die parallele Abfrage aktiviert ist. Ihr Vorteil ist die Verbesserung der Abfrageleistung. Es gibt zwei Gründe für potenziell höhere I/O-Kosten bei parallelen Abfragen:

  • Selbst wenn sich einige Daten in einer Tabelle im Pufferpool befinden, müssen bei der parallelen Abfrage alle Daten auf der Speicherebene gescannt werden, was I/O-Kosten verursacht.

  • Das Ausführen einer parallelen Abfrage führt nicht zu einem Aufwärmvorgang des Pufferpools. Folglich fallen bei aufeinanderfolgenden Läufen derselben parallelen Abfrage die vollen I/O-Kosten an.