Transaktionen und Steuerung für optimistische Nebenläufigkeit

Datenbanktransaktionen bieten ein sicheres und vorhersagbares Programmiermodell, um gleichzeitige Änderungen an den Daten zu bewältigen. Herkömmliche relationale Datenbanken wie SQL Server ermöglichen es Ihnen, die Geschäftslogik mithilfe gespeicherter Prozeduren und Trigger zu schreiben und sie dann direkt innerhalb des Datenbankmoduls an den Server zu senden.

Bei herkömmlichen relationalen Datenbanken müssen Sie zwei verschiedene Programmiersprachen behandeln: eine nichttransaktionale Programmiersprache wie JavaScript, Python, C# oder Java; und eine transaktionsbasierte Programmiersprache, z. B. T-SQL, die von der Datenbank nativ ausgeführt wird.

Das Datenbankmodul in Azure Cosmos DB unterstützt vollständige ACID-kompatible (Atomarität, Konsistenz, Isolation, Haltbarkeit) Transaktionen mit Snapshot-Isolation. Alle Datenbankvorgänge im Bereich der logischen Partition eines Containers werden im Datenbankmodul, das vom Replikat der Partition gehostet wird, transaktional ausgeführt. Diese Vorgänge umfassen sowohl Schreibvorgänge (Aktualisieren eines oder mehrerer Elemente innerhalb der logischen Partition) als auch Lesevorgänge.

In der folgenden Tabelle sind verschiedene Vorgänge und Transaktionstypen aufgeführt:

Transaktionen mit mehreren Elementen

Mit Azure Cosmos DB können Sie gespeicherte Prozeduren, Trigger und benutzerdefinierte Funktionen schreiben und Prozeduren in JavaScript zusammenführen. Azure Cosmos DB unterstützt systemeigene JavaScript-Ausführung innerhalb des Datenbankmoduls. Sie können gespeicherte Prozeduren, Pre/Post-Trigger, benutzerdefinierte Funktionen (UDFs) registrieren und Prozeduren in einem Container zusammenführen und sie später im Azure Cosmos DB-Datenbankmodul transaktional ausführen. Das Schreiben von Anwendungslogik in JavaScript ermöglicht den natürlichen Ausdruck des Steuerungsflusses, des variablen Bereichs, der Zuordnung und der Integration von Ausnahmebehandlungsgrundtypen innerhalb der Datenbanktransaktionen direkt in der JavaScript-Sprache.

Die javaScript-basierten gespeicherten Prozeduren, Trigger, UDFs und Zusammenführungsprozeduren werden in eine Ambient ACID-Transaktion mit Snapshotisolation für alle Elemente innerhalb der logischen Partition eingeschlossen. Wenn das JavaScript-Programm während der Ausführung eine Ausnahme auslöst, wird die gesamte Transaktion abgebrochen und zurückgesetzt. Das resultierende Programmiermodell ist einfach und dennoch leistungsfähig. JavaScript-Entwickler erhalten ein dauerhaftes Programmiermodell, während sie weiterhin ihre vertrauten Sprachkonstrukte und Bibliotheksgrundtypen verwenden.

Die Möglichkeit, JavaScript direkt innerhalb des Datenbankmoduls auszuführen, bietet Leistung und transaktionsale Ausführung von Datenbankvorgängen für die Elemente eines Containers. Da das Azure Cosmos DB-Datenbankmodul JSON und JavaScript nativ unterstützt, besteht kein Impedanzkonflikt zwischen den Typsystemen einer Anwendung und der Datenbank.

Optimistische Nebenläufigkeitskontrolle

Mit dem optimistischen Parallelitätssteuerelement (OCC) können Sie verlorene Updates und Löschungen verhindern. Gleichzeitige, widersprüchliche Vorgänge unterliegen der regelmäßigen pessimistischen Sperrung des Datenbankmoduls, das von der logischen Partition gehostet wird, die das Element besitzt. Wenn zwei gleichzeitige Vorgänge versuchen, die neueste Version eines Elements in einer logischen Partition zu aktualisieren, gewinnt einer davon und die andere schlägt fehl. Wenn jedoch ein oder zwei Vorgänge versuchen, dasselbe Element gleichzeitig zu aktualisieren, und zuvor einen älteren Wert des Elements gelesen hatten, weiß die Datenbank nicht, ob der zuvor gelesene Wert von einem oder beiden der in Konflikt stehenden Vorgänge tatsächlich der neueste Wert des Elements war.

Glücklicherweise kann diese Situation mit dem OCC erkannt werden, bevor die beiden Vorgänge die Transaktionsgrenze innerhalb des Datenbankmoduls eingeben können. Das OCC schützt Ihre Daten vor versehentlichen Überschreiben von Änderungen, die von anderen Personen vorgenommen wurden. Es verhindert auch, dass andere Versehentlich Ihre eigenen Änderungen überschreiben.

Implementieren Sie die optimistische Parallelitätskontrolle mithilfe von ETags und HTTP-Headern.

Jedes element, das in einem Azure Cosmos DB-Container gespeichert ist, verfügt über eine systemdefinierte _etag Eigenschaft. Der Wert des Elements _etag wird bei jeder Aktualisierung des Elements automatisch vom Server generiert und aktualisiert. _etag kann mit dem vom Client bereitgestellten if-match Anforderungsheader verwendet werden, damit der Server entscheiden kann, ob ein Element bedingt aktualisiert werden kann. Wenn der Wert der if-match Kopfzeile mit dem Wert des _etag Servers übereinstimmt, wird das Element dann aktualisiert. Wenn der Wert des if-match Anforderungsheaders nicht mehr aktuell ist, lehnt der Server den Vorgang mit einer Antwortnachricht "HTTP 412-Vorbedingungsfehler" ab. Der Client kann das Element dann erneut abrufen, um die aktuelle Version des Elements auf dem Server zu erhalten, oder die Version des Elements auf dem Server mit seinem eigenen Wert _etag für das Element überschreiben. Darüber hinaus kann _etag zusammen mit dem if-none-match Header verwendet werden, um festzustellen, ob ein erneutes Abrufen einer Ressource erforderlich ist.

Der Wert des _etag Elements ändert sich jedes Mal, wenn das Element aktualisiert wird. Bei Ersetzungsvorgängen muss if-match explizit als Teil der Anforderungsoptionen spezifiziert werden. Ein Beispiel finden Sie im Beispielcode in GitHub. Die _etag Werte werden implizit auf alle geschriebenen Elemente überprüft, die von der gespeicherten Prozedur berührt werden. Wenn ein Konflikt erkannt wird, führt die gespeicherte Prozedur ein Rollback der Transaktion durch und löst eine Ausnahme aus. Bei dieser Methode werden entweder alle oder keine Schreibvorgänge innerhalb der gespeicherten Prozedur atomar angewendet. Dies ist ein Signal für die Anwendung, aktualisierungen erneut zu verwenden und die ursprüngliche Clientanforderung erneut zu versuchen.

Optimistische Parallelitätskontrolle und globale Verteilung

Die gleichzeitigen Aktualisierungen eines Elements unterliegen der OCC durch die Kommunikationsprotokollebene von Azure Cosmos DB. Für Azure Cosmos DB-Konten, die für Schreibvorgänge mit einer Region konfiguriert sind, stellt Azure Cosmos DB sicher, dass die clientseitige Version des Elements, das Sie aktualisieren (oder löschen), mit der Version des Elements im Azure Cosmos DB-Container identisch ist. Dadurch wird sichergestellt, dass Ihre Schreibvorgänge nicht versehentlich durch die Schreibvorgänge anderer überschrieben werden und umgekehrt. In einer Umgebung mit mehreren Benutzern schützt Das optimistische Parallelitätssteuerelement Sie davor, versehentlich die falsche Version eines Elements zu löschen oder zu aktualisieren. Daher sind Elemente vor den berüchtigten Problemen "Verlorenes Update" oder "Verlorenes Löschen" geschützt.

In einem Azure Cosmos DB-Konto, das mit Schreibvorgängen mit mehreren Regionen konfiguriert ist, können Daten unabhängig in sekundäre Regionen zugesichert werden, wenn sie _etag mit den Daten in der lokalen Region übereinstimmen. Sobald neue Daten lokal in einer sekundären Region zugesichert wurden, wird sie dann im Hub oder in der primären Region zusammengeführt. Wenn die Konfliktlösungsrichtlinie die neuen Daten in der Hubregion zusammenführt, werden diese Daten global mit dem neuen _etagrepliziert. Wenn die Konfliktlösungsrichtlinie die neuen Daten ablehnt, wird der sekundäre Bereich auf die ursprünglichen Daten zurückgesetzt und _etag.

Nächste Schritte

Erfahren Sie mehr über Datenbanktransaktionen und optimistische Parallelitätssteuerung:

• Datenbanken, Container und Elemente in Azure Cosmos DB
• Konsistenzebenen in Azure Cosmos DB
• Konflikttypen und Lösungsrichtlinien
• Transaktionsbatchvorgänge in Azure Cosmos DB
• Gespeicherte Prozeduren, Trigger und benutzerdefinierte Funktionen