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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) 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](working-with-ddl.md).
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 Transaktion`UPDATE`,, `DELETE``SELECT ... 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ängen`FOR 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 Spalten`UPDATE`, 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.