Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
GILT FÜR: 
NoSQL
Datenbanktransaktionen bieten ein sicheres und vorhersagbares Programmiermodell zur Verarbeitung von gleichzeitig an den Daten vorgenommenen Änderungen. 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 (Atomarität, Konsistenz, Isolation, Haltbarkeit)-kompatible 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 in der logischen Partition) als auch Lesevorgänge.
In der folgenden Tabelle sind verschiedene Vorgänge und Transaktionstypen aufgeführt:
| Vorgang | Vorgangstyp | Einzel- oder Mehrelementtransaktion |
|---|---|---|
| Einfügen (ohne vorangestellten oder nachgestellten Trigger) | Schreiben | Transaktion für einzelnes Element |
| Einfügen (mit vorangestelltem oder nachgestelltem Trigger) | Schreiben und Lesen | Transaktion für mehrere Elemente |
| Ersetzen (ohne vorangestellten oder nachgestellten Trigger) | Schreiben | Transaktion für einzelnes Element |
| Ersetzen (mit vorangestelltem oder nachgestelltem Trigger) | Schreiben und Lesen | Transaktion für mehrere Elemente |
| Upsert (ohne vorangestellten oder nachgestellten Trigger) | Schreiben | Transaktion für einzelnes Element |
| Upsert (mit vorangestelltem oder nachgestelltem Trigger) | Schreiben und Lesen | Transaktion für mehrere Elemente |
| Löschen (ohne vorangestellten oder nachgestellten Trigger) | Schreiben | Transaktion für einzelnes Element |
| Löschen (mit vorangestelltem oder nachgestelltem Trigger) | Schreiben und Lesen | Transaktion für mehrere Elemente |
| Gespeicherte Prozedur ausführen | Schreiben und Lesen | Transaktion für mehrere Elemente |
| Vom System initiierte Ausführung einer Mergeprozedur | Schreiben | Transaktion für mehrere Elemente |
| Vom System initiierte Ausführung zum Löschen von Elementen basierend auf der Gültigkeitsdauer (TTL) eines Elements | Schreiben | Transaktion für mehrere Elemente |
| Lesen | Lesen | Transaktion für einzelnes Element |
| Änderungsfeed | Lesen | Transaktion für mehrere Elemente |
| Lesevorgang mit Paginierung | Lesen | Transaktion für mehrere Elemente |
| Paginierte Abfrage | Lesen | Transaktion für mehrere Elemente |
| UDF als Teil der paginierten Abfrage ausführen | Lesen | Transaktion für mehrere Elemente |
Transaktionen für mehrere Elemente
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 die JavaScript-Ausführung nativ innerhalb der Datenbank-Engine. 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 der Anwendungslogik in JavaScript ermöglicht eine natürliche Ausdrucksweise für Ablaufsteuerung, Variablen-Bereichssteuerung, Zuweisung und Integration von Grundtypen zur Ausnahmebehandlung für die Datenbanktransaktionen direkt in der Programmiersprache JavaScript.
Die JavaScript-basierten gespeicherten Prozeduren, Trigger, UDFs und Mergeprozeduren werden für alle Elemente innerhalb der logischen Partition in einer umgebenden ACID-Transaktion mit Momentaufnahmeisolation umschlossen. Wenn das JavaScript-Programm während der Ausführung eine Ausnahme auslöst, wird die gesamte Transaktion abgebrochen und zurückgesetzt. Das sich ergebende Programmiermodell ist einfach, aber dennoch leistungsstark. JavaScript-Entwickler erhalten ein beständiges Programmiermodell, während sie weiterhin ihre vertrauten Sprachkonstrukte und Bibliotheksstammfunktionen verwenden können.
Die Möglichkeit zur direkten Ausführung von JavaScript innerhalb der Datenbank-Engine bietet die leistungsfähige und transaktionale 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.
Steuerung durch vollständige Parallelität
Mit dem optimistischen Parallelitätssteuerelement (OCC) können Sie verlorene Updates und Löschungen verhindern. Gleichzeitige, konfliktverursachende Vorgänge unterliegen der regulären pessimistischen Sperrung der Datenbank-Engine, die in 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 Operationen 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 einer oder beiden der widersprüchlichen Operationen 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. Ebenso wird verhindert, dass andere Benutzer versehentlich die von Ihnen vorgenommenen Änderungen überschreiben.
Implementieren der optimistischen Parallelitätskontrolle mit ETag und HTTP-Headern
Jedes in einem Azure Cosmos DB-Container gespeicherte Element weist eine systemdefinierte _etag-Eigenschaft auf. Der Wert von _etag wird automatisch generiert und bei jeder Aktualisierung des Elements vom Server aktualisiert. _etag kann mit dem vom Client bereitgestellten Anforderungsheader if-match verwendet werden, sodass der Server festlegen 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 der Antwortmeldung „HTTP 412 – Vorbedingungsfehler“ ab. Der Client kann dann das Element erneut abrufen, um die aktuelle Version des Elements auf dem Server zu erhalten, oder die Version des Elements auf dem Server mit dem eigenen _etag-Wert für das Element überschreiben. Darüber hinaus kann _etag mit dem if-none-match-Header verwendet werden, um festzustellen, ob ein erneutes Abrufen einer Ressource erforderlich ist.
Der Wert _etag des Elements ändert sich bei jeder Aktualisierung des Elements. Bei Vorgängen zum Ersetzen von Elementen muss if-match ausdrücklich als Teil der Anforderungsoptionen ausgedrückt 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. Mit dieser Methode werden entweder alle oder keine Schreibvorgänge in der gespeicherten Prozedur unteilbar angewandt. Dies ist ein Signal für die Anwendung, Aktualisierungen erneut anzuwenden und die ursprüngliche Clientanforderung zu wiederholen.
Optimistische Übereinstimmungssteuerung und globale Verteilung
Die gleichzeitigen Aktualisierungen eines Elements unterliegen über die Kommunikationsprotokollebene von Azure Cosmos DB der Steuerung für optimistische Nebenläufigkeit. 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 geschützt sind und nicht versehentlich durch Schreibvorgänge von anderen Benutzern ü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. Elemente werden so vor den berühmt-berüchtigten Problemen mit verloren gegangenen Aktualisierungs- oder Löschvorgängen geschützt.
In einem Azure Cosmos DB-Konto, das für Schreibvorgänge in mehreren Regionen konfiguriert ist, können Daten unabhängig per Commit in sekundäre Regionen übertragen werden, wenn das _etag den Daten in der lokalen Region entspricht. 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 Richtlinie zur Konfliktlösung die neuen Daten ablehnt, wird in der sekundären Region ein Rollback zu den ursprünglichen Daten und zum ursprünglichen _etag ausgeführt.
Nächste Schritte
Erfahren Sie mehr über Datenbanktransaktionen und optimistische Parallelitätssteuerung: