View a markdown version of this page

Parallelitätssteuerung in Aurora DSQL - Amazon Aurora DSQL
Antworten zur ParallelitätskontrolleArten von DatenkonfliktenRichtlinien 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. Dieser Prozess der Bewertung von Konflikten zu bestimmten Zeiten wird auch als Adjudikation bezeichnet. 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.

Arten von Datenkonflikten

Aufgrund des Aurora-DSQL-Mechanismus zur Kontrolle der Parallelität führen die SELECT ... FOR UPDATE SELECT ... FOR KEY SHARE UND-Klauseln zu Ergebnissen, indem sie bei der Übertragung eine optimistische Konflikterkennung vornehmen, anstatt sie zu sperren. Wenn in Aurora DSQL eine Transaktion eine Zeile schreibt und eine andere sie mit einer der vorhergehenden Klauseln liest, kann zum Zeitpunkt des Commits ein Konflikt auftreten, je nachdem, welche Spalten die Transaktionen verwenden. Die folgenden Klauseln bestimmen, wie Aurora DSQL diese Konflikte erkennt.

Definition der Schlüsselspalte

Schlüsselspalten sind Spalten, die Mitglieder eines eindeutigen, nicht partiellen Indexes ohne Ausdrücke sind. Alle anderen Spalten sind keine Schlüsselspalten.

SELECT ... FOR UPDATE

Deklariert, dass Aurora DSQL die ausgewählten Zeilen so beurteilt, als ob die Transaktion in sie schreibt. Wenn eine andere TransaktionUPDATE,, DELETESELECT ... FOR UPDATE, oder SELECT ... FOR KEY SHARE in derselben Zeile ausgeführt wird und zuerst festgeschrieben wird, schlägt die ausgeführte Transaktion mit einer Antwort fehl. SELECT ... FOR UPDATE OC000 Diese Klausel steht in Konflikt mit allen gleichzeitigen Schreibvorgängen in die Zeile und mit gleichzeitigen LesevorgängenFOR UPDATE. FOR KEY SHARE

SELECT ... FOR KEY SHARE

Deklariert, dass die Transaktion von den Schlüsselspalten der ausgewählten Zeilen abhängt. Wenn eine andere Transaktion die Zeile löscht, ihre Schlüsselspalten ändert oder zuerst ausgeführt SELECT ... FOR UPDATE und festgeschrieben wird, schlägt die ausgeführte Transaktion mit einer Antwort SELECT ... FOR KEY SHARE fehl. OC000 Eine gleichzeitige Verwendung von SpaltenUPDATE, die keine Schlüsselspalten sind, führt nicht zu Konflikten.

Aurora DSQL unterstützt die OR-Klauseln nicht. NO KEY UPDATE FOR SHARE DML verwendet den Mechanismus jedoch implizit. NO KEY UPDATE Die folgende Matrix fasst zusammen, wenn zwei gleichzeitige Transaktionen, die auf dieselbe Zeile zugreifen, in Konflikt geraten. Ein X gibt an, dass zwischen den beiden Vorgängen ein Konflikt besteht: Die zuletzt durchgeführte Transaktion schlägt mit einer Antwort fehl. OC000 Eine leere Zelle gibt an, dass für beide Transaktionen ein Commit ausgeführt werden kann.

Operation INSERT,DELETE, UPDATE (Schlüsselspalten), oder SELECT ... FOR UPDATE UPDATE(nur Spalten, die keine Schlüsselspalten sind) SELECT ... FOR KEY SHARE
INSERTDELETE, UPDATE (Schlüsselspalten), oder SELECT ... FOR UPDATE X X X
UPDATE(nur Spalten, die keine Schlüsselspalten sind) X X
SELECT ... FOR KEY SHARE X

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.