Parallelität während der Abfrageausführung

SQL Anywhere unterstützt zwei unterschiedliche Arten von Parallelität bei der Abfrageausführung: abfrageinterne und abfrageübergreifende Parallelität. Abfrageübergreifende Parallelität (Inter-Query-Parallelität) bedeutet, dass verschiedene Abfragen gleichzeitig auf separaten CPUs ausgeführt werden. Jede Anforderung (Task) läuft in einem einzelnen Thread und wird auf einem einzelnen Prozessor ausgeführt.

Abfrageinterne Parallelität (Intra-Query-Parallelität) bedeutet, dass mehrere CPUs gleichzeitig eine einzelne Anforderung verarbeiten, sodass Teile der Abfrage parallel durch Multi-Prozessor-Hardware berechnet werden. Die Verarbeitung dieser Teile wird vom Exchange-Algorithmus durchgeführt. Siehe Exchange-Algorithmus (Exchange).

Die abfrageinterne Parallelität kann die Systemlast verbessern, wenn die Anzahl der gleichzeitig ausgeführten Abfragen normalerweise geringer ist als die Anzahl der verfügbaren Prozessoren. Der Höchstgrad der Parallelität wird durch die max_query_tasks-Option kontrolliert. Siehe max_query_tasks-Option.

Der Optimierer schätzt die Extrakosten der Parallelität (zusätzliches Kopieren von Zeilen, Zusatzkosten für Koordination der Aufgaben) und wählt parallele Pläne nur aus, wenn sie die Performance verbessern können.

Die abfrageinterne Parallelität wird nicht bei Verbindungen angewendet, für die die Priority-Option auf "background" gesetzt wurde. Siehe priority-Option.

Die abfrageinterne Parallelität wird nicht angewendet, wenn die Anzahl der Server-Threads, die gerade eine Anforderung bearbeiten (Servereigenschaft "ActiveReq"), die Anzahl von CPU-Kernen des Computers überschreitet, für dessen Benutzung der Datenbankserver lizenziert ist. Über die genaue Zeitspanne entscheidet der Server. Dabei handelt es sich normalerweise um ein paar Sekunden. Siehe Datenbankservereigenschaften.

Parallelausführung

Ob eine Abfrage die Vorteile der parallelen Ausführung nutzen kann, hängt von einer Vielzahl von Faktoren ab:

den verfügbaren Ressourcen im System zur Zeit der Optimierung (Arbeitsspeicher, Datenmenge im Cache usw.)
der Anzahl von logischen Prozessoren auf dem Computer
der Anzahl der Plattenmedien für die Speicherung der Datenbank sowie deren Geschwindigkeit relativ zum Prozessor und der I/O-Architektur des Computers.
den spezifischen algebraischen Operatoren, die für die Anforderung erforderlich sind. SQL Anywhere unterstützt fünf algebraische Operatoren, die parallel ausgeführt werden können:
- Paralleler sequenzieller Scan (Table-Scan)
- Paralleler Index-Scan
- Paralleler Hash-Join sowie parallele Versionen von Hash-Semijoin und Anti-Semijoin
- Parallele Nested-Loop-Joins (Joins mit verschachtelten Schleifen) sowie parallele Versionen von Nested-Loop-Semijoins (Semijoins mit verschachtelten Schleifen) und Anti-Semijoins
- Paralleler Hash-Filter
- Paralleler Hash-Group-By

Eine Abfrage, die nicht unterstützte Operatoren verwendet, kann trotzdem parallel ausgeführt werden, jedoch müssen die unterstützten Operatoren im Plan unterhalb der nicht unterstützten Operatoren erscheinen (wie in dbisql gezeigt). Eine Abfrage, bei der die meisten nicht unterstützten Operatoren weit oben erscheinen können, wird mit größerer Wahrscheinlichkeit Parallelität verwenden. Ein Sort-Operator kann beispielsweise nicht parallel ausgeführt werden, aber eine Abfrage, die ORDER BY im äußersten Block verwendet, kann parallel ausgeführt werden, indem der Sort-Operator an den Anfang des Plans gesetzt wird und alle parallelen Operatoren darunter. Im Gegensatz dazu wird eine Abfrage die Parallelität weniger wahrscheinlich benutzen, wenn sie TOP n und ORDER BY in einer abgeleiteten Tabelle verwendet, da der Sort-Operator an einer anderen Stelle als am Anfang des Plans erscheinen muss.

Standardmäßig geht SQL Anywhere davon aus, dass sich alle DBSpaces auf einem Platten-Subsystem mit einer einzelnen Platte befinden. Während es Vorteile haben kann, in einer solchen Umgebung Abfragen parallel auszuführen, macht es das I/O-Kostenmodell des Optimierers für ein einzelnes Gerät schwierig, eine parallele Tabelle oder einen Index-Scan zu wählen, wenn sich die Tabellendaten nicht vollständig innerhalb des Caches befinden. Durch das Kalibrieren des I/O-Subsystems mit der ALTER DATABASE CALIBRATE PARALLEL READ-Anweisung kann der Optimierer die Kosten der Vorteile der parallelen Ausführung mit größerer Genauigkeit berechnen. Der Optimierer wählt daher mit größerer Wahrscheinlichkeit Ausführungspläne mit einer gewissen Parallelität für mehrere Spindles.

Wenn für einen Zugriffsplan abfrageinterne Parallelität benutzt wird, enthält der Plan einen Exchange-Operator, der die Ergebnisse der parallelen Berechnung jeder Unterstruktur zusammenführt (Union). Die Anzahl der Unterstrukturen unterhalb des Exchange-Operators ist der Grad der Parallelität. Jede Unterstruktur oder Plankomponente ist eine Aufgabe für den Datenbankserver. Der Kernel des Datenbankservers plant die Ausführung dieser Aufgaben so, als wären es einzelne SQL-Anforderungen, basierend auf der Verfügbarkeit von Ausführungsthreads (oder Fibers). Diese Architektur bedeutet, dass die parallele Berechnung eines Zugriffsplans weitgehend selbstoptimierend ist, da die Arbeit für die parallele Ausführung einer Aufgabe in einem Thread (Fiber) geplant wird, wenn der Server-Kernel dies erlaubt, und die Ausführung der Plankomponenten gleichmäßig durchgeführt wird.

Siehe auch

Parallelität in Abfragen

Kommentieren Sie diese Seite in DocCommentXchange.