Atomicity, Consistency, Isolation, Durability

Extra-Speed für ACID-Transaktionen in verteilten Datenbanken
Keine Kommentare

Moderne NoSQL-Datenbankplattformen müssen transaktionssicher und gleichzeitig hochverfügbar sein. Diese konkurrierenden Anforderungen können mit einer cleveren Kombination von Multi-Dokument-Verarbeitung und In-Memory-Processing gelöst werden.

ACID steht für die vier Parameter der Sicherheit von Datenbank-Transaktionen. A steht für Abgeschlossenheit (Atomicity), C für Konsistenz (Consistency), I für Isolation und D für die dauerhafte Speicherung (Durability). Sind diese nicht gegeben, wird die Datenbank nicht aktualisiert und wieder in den Zustand vor Beginn der Transaktion zurückversetzt. Das setzt unter anderem voraus, dass alle für eine Änderung benötigten Tabellen (bei herkömmlichen relationalen Datenbanksystemen) oder Dokumente (bei NoSQL-Datenbanken) während der Transaktion für den Zugriff oder andere Änderungen gesperrt werden müssen.

Transaktionen ohne Verzögerungen

NoSQL-Datenbanken sind jedoch für eine hohe Verfügbarkeit ausgelegt, eine lange Sperrung von Dokumenten und die damit verbundene Nutzbarkeitslücke würde diesen Vorteil konterkarieren. Da dort versucht wird, möglichst viele zusammengehörige Informationen in einem einzigen Dokument zu speichern wird häufig davon ausgegangen, dass ACID dafür gar nicht gebraucht wird, die Transaktionssicherheit also durch eine singuläre Dokumentensperrung (single document lock) mit entsprechend hoher Datenbankverfügbarkeit gewährleistet ist. Dieses Prinzip lässt sich jedoch nicht durchhalten. Häufig sind die Daten in mehreren Dokumenten verteilt, die bei Änderungen dementsprechend alle blockiert werden müssen (multi document lock). Eine solche Sperrung kann pro Dokument beim Default-Wert bis zu 15 Sekunden dauern.

Ziel muss es also sein, die Lock-Zeiten für solche Fälle zu minimieren. Wichtig ist das beispielsweise für Banken und Finanzdienstleister die an strenge Vorgaben bezüglich der Transaktionssicherheit gebunden sind, andererseits mit schnellen, jederzeit verfügbaren Kundenservices punkten wollen. Kein Kunde möchte auf das Ergebnis einer Kontoabfrage oder einer Kreditkartentransaktion lange warten müssen. Gleiches gilt für Bestellungen, Flugbuchungen oder Eigentumstransfers.

Multi-Dokument-Verarbeitung im Cache

In NoSQL-Datenbanken werden Informationen in JSON-Dokumenten gespeichert. Über die exklusive deklarative Abfragesprache N1QL (SQL for JSON) waren schon bislang Änderungen in einem einzelnen JSON-Dokument möglich. Jetzt können über die SQL-nativen Statements Änderungen auch in mehreren JSON-Dokumenten gleichzeitig vorgenommen werden. Das erleichtert und beschleunigt die Transaktionsbearbeitung und verkürzt so die Downtime der Dokumente. Für zusätzliche Geschwindigkeit sorgt das bislang im NoSQL-Umfeld ebenfalls exklusive In-Memory-Computing von Transaktionen. Die Read- und Write-Vorgänge bei der Datenbankabfrage werden dabei komplett direkt im Cache bearbeitet. Das hat zusätzlich den Vorteil, dass auch die Konsistenzprüfung ausschließlich im Cache erfolgen muss, was sie vereinfacht und beschleunigt. Dadurch wird ein hoher Datenbankdurchsatz erreicht, der die Wartezeiten auf ein Minimum reduziert.

Geschwindigkeit und Transaktionssicherheit sind damit keine Antagonismen mehr. Die exklusive Kombination von hohen Workload-Volumina und hoher Verarbeitungsgeschwindigkeit bei gleichzeitiger ACID-Konformität eröffnet der NoSQL-Datenbank, die über diese Fähigkeiten verfügt, erstmals Einsatzmöglichkeiten in Branchen, die genau das für die Digitalisierung ihrer Services und Geschäftsmodelle dringend benötigen. Und die werden in Zukunft wachsenden Bedarf dafür haben.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -