View a markdown version of this page

Parallelitätssteuerung in Aurora DSQL - Amazon Aurora DSQL
Antworten zur ParallelitätskontrolleRichtlinien 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 Parallelitätskontrolle

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 widersprüchliche Transaktion 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 geändert hat, seit die Sitzung ihren Cache geladen hat, und die Transaktion nicht sicher auf die aktuelle Version umbasieren kann, erhält die Transaktion die OC001-Antwort:

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

Jeder Vorgang, der den Schemakatalog ändert, kann eine OC001-Antwort auslösen, einschließlich DDL-Anweisungen wie CREATE TABLE und ALTER TABLE sowie UND-Anweisungen. GRANT REVOKE Weitere Informationen finden Sie unter DDL und verteilte Transaktionen in Aurora DSQL.

Entwerfen Sie Ihre Anwendungen so, dass sie eine 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.