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.

Amazon QLDB-Parallelitätsmodell

Amazon QLDB wurde entwickelt, um die Anforderungen leistungsstarker OLTP-Workloads (Online Transaction Processing) zu erfüllen. 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 mit QLDB auf den vollständigen und überprüfbaren Verlauf aller Änderungen an Ihren Daten zugreifen und bei Bedarf kohärente Transaktionen an andere Datendienste streamen.

Optimistic Concurrency Control

In QLDB wird die Parallelitätskontrolle 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.

Mit OCC erwerben Transaktionen in QLDB keine Sperren für Datenbankressourcen und arbeiten mit vollständiger serialisierbarer Isolation. QLDB führt gleichzeitige Transaktionen seriell aus, sodass der gleiche Effekt erzielt wird, als ob diese Transaktionen seriell gestartet würden.

Vor dem Festschreiben führt jede Transaktion eine Validierungsprüfung durch, um sicherzustellen, dass keine andere festgeschriebene 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 festgeschriebene Transaktion zurückgewiesen. 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 QLDB eine an die Anwendungsebene OccConflictException 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 darüber, wie der QLDB-Treiber OCC-Konflikte und andere vorübergehende Ausnahmen behandelt und wiederholt, finden Sie unter. Grundlegendes zur Wiederholungsrichtlinie mit dem Treiber in Amazon QLDB

Verwendung von Indizes zur Vermeidung vollständiger Tabellenscans

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

Es hat sich bewährt, Anweisungen mit einer WHERE 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 Beispiel oder. WHERE indexedField = 123 WHERE 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 Transaktions-Timeouts 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.

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 von Alice festgeschriebene Transaktion die Daten geändert wurden, auf die Bobs Aussage 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 umfassen, die neu eingefügt wurden, und nicht nur Dokumente, die zuvor vorhanden waren. 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 folgenden INSERT Anweisungen in einer einzigen SELECT Transaktion aus. Ihre Anwendung führt die INSERT Anweisung nur aus, wenn die SELECT 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 eine. OccConflictException 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.

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

Transaktionen idempotent machen

Die Insert-Transaktion im vorherigen Abschnitt ist auch ein Beispiel für eine idempotente Transaktion. Mit anderen Worten, wenn dieselbe Transaktion mehrmals ausgeführt wird, werden identische Ergebnisse erzielt. Wenn Bob das ausführt, INSERT ohne vorher zu prüfen, ob eine bestimmte VIN bereits existiert, könnte die Tabelle am Ende Dokumente mit doppelten VIN Werten enthalten.

Berücksichtigen Sie neben OCC-Konflikten auch andere Wiederholungsszenarien. Es ist beispielsweise möglich, dass QLDB erfolgreich eine Transaktion auf der Serverseite festschreibt, der Client jedoch während des Wartens auf eine Antwort eine Zeitüberschreitung ausführt. Als bewährte Methode sollten Sie Ihre Schreibtransaktionen idempotent gestalten, um unerwartete Nebenwirkungen im Fall von Parallelität oder Wiederholungsversuchen zu vermeiden.

Bei der Bearbeitung von OCC-Konflikten

QLDB verhindert das gleichzeitige Redigieren von Revisionen auf demselben Journalblock. Stellen Sie sich ein Beispiel vor, bei dem zwei gleichzeitige Benutzer (Alice und Bob) zwei verschiedene Dokumentversionen redigieren möchten, die für denselben Block in einem Ledger übernommen wurden. Zunächst fordert Alice die Schwärzung einer Revision an, indem sie die REDACT_REVISION gespeicherte Prozedur wie folgt ausführt.

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

Dann, während Alices Anfrage noch bearbeitet wird, fordert Bob die Schwärzung einer anderen Revision an, und zwar wie folgt.

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

QLDB lehnt Bobs Anfrage mit einem ab, OccConflictException obwohl sie versuchen, zwei verschiedene Dokumentüberarbeitungen 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 seine Redaktionsanfrage erneut versuchen.

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

Gleichzeitige Sitzungen verwalten

Wenn Sie Erfahrung mit einem relationalen Datenbankmanagementsystem (RDBMS) haben, sind Sie möglicherweise mit den Beschränkungen für gleichzeitige Verbindungen 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 Datentransaktionsanfragen an ein Ledger. Eine aktive Sitzung ist eine Sitzung, in der aktiv eine Transaktion ausgeführt wird. 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. Wenn dieses Limit erreicht ist, führt jede Sitzung, die versucht, eine Transaktion zu starten, zu einem Fehler ()LimitExceededException.

Informationen über den Lebenszyklus einer Sitzung und darüber, wie der QLDB-Treiber Sitzungen bei der Ausführung von Datentransaktionen verarbeitet, finden Sie unter. Sitzungsverwaltung mit dem Fahrer Bewährte Methoden für die Konfiguration eines Sitzungspools in Ihrer Anwendung mithilfe des QLDB-Treibers finden Sie unter Das Objekt konfigurieren QldbDriver Amazon QLDB-Treiberempfehlungen.