Parallel Query für Amazon Aurora MySQL - 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.

Parallel Query für Amazon Aurora MySQL

Dieses Thema beschreibt, wie Sie Amazon-Aurora-MySQL-kompatible Edition Parallel Query optimal nutzen. Diese Funktion verwendet für bestimmte datenintensive Abfragen einen speziellen Verarbeitungspfad. Dabei kommt zum Tragen, dass die Architektur von Aurora verschiedene Speicherquellen nutzt. Parallel Query ist am wirkungsvollsten in Verbindung mit Aurora MySQL DB-Clustern, deren Tabellen Millionen Zeilen und analytische Abfragen unterstützen, deren Abarbeitung Minuten oder Stunden dauert.

Themen

Übersicht über Parallel Query für Aurora MySQL

Aurora MySQL Parallel Query ist eine Optimierung, die bei der Verarbeitung datenintensiver Abfragen einen Teil der I/O-Operationen und Berechnungen 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 eine Parallelabfrage leitet jede Abfrage die gescannten Daten zu einem einzigen Knoten innerhalb des Aurora MySQL-Clusters (Hauptknoten) und die Verarbeitung jeglicher Abfragen erfolgt dort.

Tipp

Die PostgreSQL-Datenbank-Engine hat auch eine Funktion, die auch „parallel query bzw. Paralleabfragen“ genannt wird. Diese Funktion steht in keinem Zusammenhang mit der parallelen Abfrage von Aurora.

Wenn die Funktion für parallele Abfragen aktiviert ist, bestimmt die Aurora-MySQL-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 MySQL führt in der Regel keine parallele 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 Parallel Query für Aurora MySQL verwenden.

Vorteile

Mit parallelen Abfragen können Sie datenintensive analytische Abfragen für Aurora MySQL-Tabellen ausführen. In vielen Fällen verbessert sich die Leistung im Vergleich mit herkömmlichen Verfahren, in denen Abfragen arbeitsteilig verarbeitet werden, um mehrere Größenordnungen.

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.

  • Niedrigere CPU-Last im Hauptknoten, weil die Funktionsverarbeitung, Zeilenfilterung und Spaltenprojektion für die WHERE-Klausel herabgestuft werden.

  • 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.

  • Möglicherweise weniger Datenduplikate in der ETL-Pipeline (Extract, Transform, Load), weil langwierige analytische Abfragen auf Bestandsdaten ausgeführt werden können.

Architektur

Parallele Abfragen machen sich die maßgeblichen Architekturprinzipien von Aurora MySQL zunutze: Entkopplung zwischen Datenbank-Engine und Speichersubsystem und weniger Netzwerkdatenverkehr durch Optimierung von Kommunikationsprotokollen. Aurora MySQL verwendet diese Techniken, um schreibintensive Operationen wie Redo-Protokoll-Verarbeitung zu beschleunigen. Parallel Query wendet die gleichen Prinzipien auf Leseoperationen an.

Anmerkung

Die Architektur von Aurora MySQL Parallel Query ist anders als die ähnlich benannter Funktionen in anderen Datenbanksystemen. Aurora MySQL Parallel Query ist kein symmetrisches Multiprocessing (SMP) und ist daher nicht von der CPU-Kapazität des Datenbankservers abhängig. Die Parallelverarbeitung erfolgt auf der Speicherschicht, völlig losgelöst vom Aurora MySQL-Server, der als Abfragekoordinator fungiert.

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. Parallel Query delegiert einen Großteil dieser I/O- und CPU-intensiven Arbeit an Knoten aus der Speicherschicht. 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 dem reduzierten Netzwerkdatenverkehr, einer niedrigeren CPU-Last im Hauptknoten und der Parallelisierung der I/O-Vorgänge aller 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 verwenden zu können, wird ein DB-Cluster von Aurora MySQL benötigt, auf dem Version 2.09 und 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 parallele Abfragemechanismus für jede SQL-Anweisung verwendet werden soll. Die Verwendung bestimmter SQL-Konstrukte in einer Anweisung kann eine parallele Abfrage verhindern oder eine parallele Abfrage für diese Anweisung unwahrscheinlich machen. Hinweise zur Kompatibilität von SQL-Konstrukten mit parallelen Abfragen finden Sie unter SQL-Konstrukte für Parallel Query in Aurora MySQL.

  • 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.

  • Parallel Query ist in allen AWS-Regionen verfügbar, die Aurora unterstützt. Für die meisten AWS-Regionen ist für die Verwendung von Parallel Query mindestens die Aurora-MySQL-Version 2.09 erforderlich.

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

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

I/O-Kosten bei Parallelabfragen

Wenn Ihr Aurora MySQL Cluster eine parallele Abfrage verwendet, erfolgt möglicherweise eine Zunahme der VolumeReadIOPS-Werte. 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.