View a markdown version of this page

Parallelitätssteuerung in Aurora DSQL - Amazon Aurora DSQL
Antworten zur Kontrolle der ParallelitätRichtlinien für die Optimierung der Transaktionsleistung

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.

Parallelitätssteuerung in Aurora DSQL

Durch Parallelität können mehrere Sitzungen gleichzeitig auf Daten zugreifen und diese ändern, ohne die Datenintegrität und -konsistenz zu beeinträchtigen. Aurora DSQL bietet PostgreSQL-Kompatibilität und implementiert gleichzeitig einen modernen, sperrenlosen Parallelitätskontrollmechanismus. Dieser gewährleistet vollständige ACID-Konformität durch Snapshot-Isolierung und gewährleistet so Datenkonsistenz und -zuverlässigkeit.

Die sperrenfreie Architektur, die häufig auftretende Engpässe bei der Datenbankleistung beseitigt, ist ein entscheidender Vorteil von Aurora DSQL. Aurora DSQL verhindert, dass langsame Transaktionen andere Operationen blockieren, und beseitigt das Risiko von Deadlocks. Dieser Ansatz macht Aurora DSQL besonders wertvoll für Anwendungen mit hohem Durchsatz, bei denen Leistung und Skalierbarkeit entscheidend sind.

Antworten zur Kontrolle der Parallelität

Aurora DSQL verwendet Optimistic Concurrency Control (OCC), die anders funktioniert als herkömmliche sperrenbasierte Systeme. Anstatt Sperren zu verwenden, bewertet OCC Konflikte beim Festschreiben. Wenn Aurora DSQL einen Konflikt erkennt, gibt es einen PostgreSQL-Serialisierungsfehler mit SQLSTATE-Code zurück. 40001 Die Antwortnachricht enthält einen OCC-Code, der die Art des Konflikts identifiziert:

OC000 — Datenkonflikt

Zwei Transaktionen haben versucht, dieselbe Zeile zu ändern. Die Transaktion mit dem frühesten Commit-Zeitpunkt ist erfolgreich, und die Transaktion, bei der der Konflikt entsteht, erhält die OC000 Antwort:

ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)
OC001 — Schemakonflikt

Der zwischengespeicherte Schemakatalog der Sitzung ist veraltet. Wenn Aurora DSQL feststellt, dass sich die Katalogversion seit dem Laden des Caches durch die Sitzung geändert hat und die Transaktion nicht sicher auf die aktuelle Version umgestellt werden kann, erhält die Transaktion die Antwort: OC001

ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)

Jede Operation, die den Schemakatalog ändert, kann zu einer OC001 Antwort führen, einschließlich DDL-Anweisungen wie CREATE TABLE und undALTER TABLE. GRANT REVOKE Weitere Informationen finden Sie unter DDL und verteilte Transaktionen in Aurora DSQL.

Entwerfen Sie Ihre Anwendungen so, dass sie Wiederholungslogik implementieren, um diese Antworten zu verarbeiten. Das ideale Entwurfsmuster ist idempotent, sodass Transaktionen wenn möglich immer gleich erneut ausgeführt werden können. Die empfohlene Logik ähnelt dem Abbruch- und Wiederholungsverhalten bei einem PostgreSQL-Sperrzeitlimit oder Deadlock. Allerdings erfordert OCC, dass Ihre Anwendung diese Wiederholungslogik häufiger anwendet.

Richtlinien für die Optimierung der Transaktionsleistung

Um die Leistung zu optimieren, sollte hohe Konkurrenz auf einzelnen Schlüsseln oder kleinen Schlüsselbereichen vermieden werden. Dazu sollten Sie Ihr Schema so entwerfen, dass Updates über den gesamten Cluster-Schlüsselbereich verteilt werden. Beachten Sie dabei die folgenden Richtlinien:

  • Wählen Sie einen zufälligen Primärschlüssel für Ihre Tabellen.

  • Vermeiden Sie Muster, die Konflikten bei einzelnen Schlüsseln erhöhen. Dieser Ansatz gewährleistet eine optimale Leistung auch bei steigendem Transaktionsvolumen.