Amazon QLDB-Nebenläufigkeit von Amazon QLDB-Nebenläufigkeit

Amazon QLDB ist für Online-Transaktionsverarbeitungs------------------------------------ QLDB unterstützt SQL-ähnliche Abfragefunktionen und liefert vollständige ACID-Transaktionen. Darüber hinaus sind QLDB-Datenelemente Dokumente, die Schemaflexibilität und intuitive Datenmodellierung bieten. Mit einem Journal als Herzstück können Sie QLDB verwenden, um auf den vollständigen und überprüfbaren Verlauf aller Änderungen an Ihren Daten zuzugreifen und kohärente Transaktionen bei Bedarf an andere Datendienste zu streamen.

Optimistic Concurrency Control

In QLDB wird die Parallelitätssteuerung mithilfe der optimistischen Parallelitätssteuerung (OCC) implementiert. OCC arbeitet auf dem Prinzip, dass mehrere Transaktionen häufig abgeschlossen werden können, ohne sich gegenseitig zu beeinflussen.

Mithilfe von OCC werden für Transaktionen in QLDB keine Sperren der Datenbankressourcen übernommen und sie werden mit vollständiger serialisierbarer Isolierung ausgeführt. QLDB führt gleichzeitige Transaktionen seriell aus, sodass sie den gleichen Effekt haben, als ob diese Transaktionen seriell gestartet würden.

Vor dem Commit führt jede Transaktion eine Validierungsprüfung durch, um sicherzustellen, dass keine andere übernommene Transaktion die Daten, auf die sie zugreift, geändert hat. Wenn bei dieser Prüfung widersprüchliche Änderungen festgestellt werden oder sich der Status der Daten ändert, wird die übernehmende Transaktion abgelehnt. Die Transaktion kann jedoch neu gestartet werden.

Wenn eine Transaktion in QLDB schreibt, werden die Validierungsprüfungen des OCC-Modells von QLDB selbst implementiert. Wenn eine Transaktion aufgrund eines Fehlers in der Überprüfungsphase von OCC nicht in das Journal geschrieben werden kann, gibt QLDBOccConflictException an die Anwendungsebene zurück. Die Anwendungssoftware ist dafür verantwortlich sicherzustellen, dass die Transaktion neu gestartet wird. Die Anwendung sollte die abgelehnte Transaktion abbrechen und dann die gesamte Transaktion von Anfang an wiederholen.

Informationen dazu, wie der QLDB-Treiber mit OCC-Konflikten und anderen vorübergehenden Ausnahmen umgeht und es erneut versucht, finden Sie unterVerstehen der Wiederholungsrichtlinie mit dem Treiber in Amazon QLDB.

Verwendung von Indizes zur Vermeidung vollständiger Tabellenscans

In QLDB wird jede PartiQL-Anweisung (einschließlich jederSELECT Abfrage) in einer Transaktion verarbeitet und unterliegt einem Transaktions-Timeout-Limit.

Es hat sich bewährt, Anweisungen mit einerWHERE Prädikatklausel auszuführen, die nach einem indizierten Feld oder einer Dokument-ID filtert. QLDB benötigt einen Gleichheitsoperator für ein indiziertes Feld, um ein Dokument effizient nachschlagen zu können; zum BeispielWHERE indexedField = 123 oderWHERE indexedField IN (456, 789).

Ohne diese indizierte Suche muss QLDB beim Lesen von Dokumenten einen vollständigen Tabellenscan durchführen. Dies kann zu Abfragelatenz und Transaktionszeitüberschreitungen führen und erhöht auch die Wahrscheinlichkeit eines OCC-Konflikts mit konkurrierenden Transaktionen.

Erwägen Sie beispielsweise eine Tabelle mit dem Namen Vehicle, die nur einen Index für das Feld VIN aufweist. Sie enthält die folgenden Dokumente.

VIN	Marke	Model	Farbe
"1N4AL11D75C109151"	"Audi"	"A5"	"Silver"
"KM8SRDHF6EU074761"	"Tesla"	"Model S"	"Blue"
"3HGGK5G53FM761765"	"Ducati"	"Monster 1200"	"Yellow"
"1HVBBAANXWH544237"	"Ford"	"F 150"	"Black"
"1C4RJFAG0FC625797"	"Mercedes"	"CLK 350"	"White"

Zwei gleichzeitige Benutzer namens Alice und Bob arbeiten mit derselben Tabelle in einem Ledger. Sie möchten zwei verschiedene Dokumente wie folgt aktualisieren.

Alice:

UPDATE Vehicle AS v
SET v.Color = 'Blue'
WHERE v.VIN = '1N4AL11D75C109151'

Bob:

UPDATE Vehicle AS v
SET v.Color = 'Red'
WHERE v.Make = 'Tesla' AND v.Model = 'Model S'

Angenommen, Alice und Bob starten ihre Transaktionen gleichzeitig. Alices UPDATE-Anweisung führt eine indizierte Suche für das Feld VIN durch, sodass sie nur dieses eine Dokument lesen muss. Alice beendet ihre Transaktion und übergibt diese als erste erfolgreich.

Bobs Anweisung filtert nach nicht indizierten Feldern. Sie führt also einen Tabellenscan durch und trifft auf eine OccConflictException. Das liegt daran, dass durch die übernommene Transaktion von Alice die Daten geändert wurden, auf die Bobs Anweisung zugreift. Dazu gehören alle Dokumente in der Tabelle — nicht nur das Dokument, das Bob gerade aktualisiert.

Einfügungs-OCC-Konflikte

OCC-Konflikte können Dokumente beinhalten, die neu eingefügt wurden — nicht nur Dokumente, die zuvor existierten. Sehen Sie sich das folgende Diagramm an, in dem zwei gleichzeitige Benutzer (Alice und Bob) mit derselben Tabelle in einem Ledger arbeiten. Beide wollen ein neues Dokument nur unter der Bedingung einfügen, dass ein Prädikatwert noch nicht vorhanden ist.

In diesem Beispiel führen sowohl Alice als auch Bob die folgendenSELECTINSERT AND-Anweisungen innerhalb einer einzigen Transaktion aus. Ihre Anwendung führt dieINSERT Anweisung nur aus, wenn dieSELECT Anweisung keine Ergebnisse zurückgibt.

SELECT * FROM Vehicle v WHERE v.VIN = 'ABCDE12345EXAMPLE'

INSERT INTO Vehicle VALUE
{
    'VIN' : 'ABCDE12345EXAMPLE',
    'Type' : 'Wagon',
    'Year' : 2019,
    'Make' : 'Subaru',
    'Model' : 'Outback',
    'Color' : 'Gray'
}

Angenommen, Alice und Bob starten ihre Transaktionen gleichzeitig. Beide SELECT Abfragen geben kein vorhandenes Dokument mit einem VIN von ABCDE12345EXAMPLE zurück. Ihre Anwendungen fahren also mit der INSERT-Anweisung fort.

Alice beendet ihre Transaktion und übergibt diese als erste erfolgreich. Dann versucht Bob, seine Transaktion zu bestätigen, aber QLDB lehnt sie ab und wirft eineOccConflictException. Dies liegt daran, dass mit der von Alice übergebenen Transaktion die Ergebnismenge von Bobs SELECT-Abfrage geändert wurde und OCC diesen Konflikt erkennt, bevor Bobs Transaktion übergeben wird.

DieSELECT Abfrage ist erforderlich, damit dieses Transaktionsbeispiel idempotent ist. Bob kann dann zwar seine gesamte Transaktion von Anfang an wiederholen. Seine nächsteSELECT Abfrage gibt jedoch das Dokument zurück, das Alice eingefügt hat, sodass Bobs Anwendung das nicht ausführtINSERT.

Transaktionen idempotent machen

Die Insert-Transaktion im vorherigen Abschnitt ist auch ein Beispiel für eine idempotente Transaktion. Mit anderen Worten, die mehrfache Ausführung derselben Transaktion führt zu identischen Ergebnissen. Wenn Bob den ausführt,INSERT ohne vorher zu überprüfen, ob ein bestimmtesVIN Objekt bereits existiert, kann es sein, dass die Tabelle Dokumente enthält, die doppelteVIN Werte enthalten.

Berücksichtigen Sie neben OCC-Konflikten auch andere Wiederholungsszenarien. Beispielsweise ist es möglich, dass QLDB eine Transaktion auf der Serverseite erfolgreich festschreibt, der Client jedoch ein Timeout hat, während er auf eine Antwort wartet. Es hat sich bewährt, Schreibtransaktionen idempotent zu machen, um unerwartete Nebenwirkungen im Fall von Parallelität oder Wiederholungsversuchen zu vermeiden.

Redflifliflifliflifliflit

QLDB verhindert das gleichzeitige Schwärzen von Revisionen desselben Journalblocks. Stellen Sie sich ein Beispiel vor, in dem zwei gleichzeitige Benutzer (Alice und Bob) zwei verschiedene Dokumentrevisionen schwärzen möchten, die für denselben Block in einem Hauptbuch eingetragen sind. Zunächst fordert Alice die Bearbeitung einer Revision an, indem sie dieREDACT_REVISION gespeicherte Prozedur wie folgt ausführt.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'

Während Alices Anfrage noch bearbeitet wird, bittet Bob dann wie folgt um die Bearbeitung einer weiteren Revision.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '8F0TPCmdNQ6JTRpiLj2TmW', '05K8zpGYWynDlEOK5afDRc'

QLDB lehnt Bobs Anfrage mit einem Kommentar ab,OccConflictException obwohl sie versuchen, zwei verschiedene Dokumentrevisionen zu redigieren. Das liegt daran, dass sich Bobs Revision im selben Block befindet wie die Revision, die Alice gerade redigiert. Nachdem die Bearbeitung von Alices Anfrage abgeschlossen ist, kann Bob erneut versuchen, seine Schwärzungsanfrage zu bearbeiten.

Ebenso kann nur eine Anfrage bearbeitet werden, wenn zwei gleichzeitige Transaktionen versuchen, dieselbe Revision zu redigieren. Die andere Anfrage schlägt mit einer OCC-Konfliktexception fehl, bis die Bearbeitung abgeschlossen ist. Danach führen alle Anfragen, dieselbe Revision zu redigieren, zu einem Fehler, der darauf hinweist, dass die Revision bereits redigiert wurde.

Verwalten gleichzeitiger Sitzungen

Wenn Sie Erfahrung mit einem relationalen Datenbankmanagementsystem (RDBMS) haben, sind Sie möglicherweise mit Nebenläufigkeit vertraut. QLDB hat nicht das gleiche Konzept einer herkömmlichen RDBMS-Verbindung, da Transaktionen mit HTTP-Anforderungs- und Antwortnachrichten ausgeführt werden.

In QLDB ist das analoge Konzept eine aktive Sitzung. Eine Sitzung ähnelt konzeptionell einer Benutzeranmeldung — sie verwaltet Informationen über Ihre Datentransaktionsanforderungen an ein Ledger. Eine aktive Sitzung ist eine Sitzung, die aktiv eine Transaktion ausführt. Es kann sich auch um eine Sitzung handeln, die kürzlich eine Transaktion abgeschlossen hat und bei der der Service davon ausgeht, dass er sofort eine weitere Transaktion starten wird. QLDB unterstützt eine aktiv laufende Transaktion pro Sitzung.

Das Limit für gleichzeitige aktive Sitzungen pro Ledger ist in Kontingente und Limits in Amazon QLDB definiert. Nachdem dieses Limit erreicht ist, führt jede Sitzung, die versucht, eine Transaktion zu starten, zu einem Fehler (LimitExceededException).

Hinweise zum Lebenszyklus einer Sitzung und zur Verarbeitung von Sitzungen durch den QLDB-Treiber bei der Ausführung von Datentransaktionen finden Sie unterSitzungsmanagement mit dem Fahrer. Bewährte Methoden für die Konfiguration eines Sitzungspool in Ihrer Anwendung mithilfe des QLDB-Treibers finden SieKonfigurieren von QldbDriver Objekt in den Amazon QLDB-Treiberempfehlungen.