Graph-Datenbanken für Anfänger: ACID vs. BASE erklärt

Wenn es um NoSQL-Datenbanken geht, können sich Datenkonsistenzmodelle manchmal auffallend von denen unterscheiden, die von relationalen Datenbanken verwendet werden (und sich auch von anderen NoSQL-Speichern unterscheiden).
Die beiden gängigsten Konsistenzmodelle sind unter den Akronymen ACID und BASE bekannt. Während sie oft in einem Kampf um den ultimativen Sieg gegeneinander antreten (bitte macht jemand ein Video davon), haben beide Konsistenzmodelle Vor– und Nachteile – und keines passt immer perfekt.
Werfen wir einen genaueren Blick auf die Kompromisse beider Datenbankkonsistenzmodelle.

In dieser Graph Databases for Beginners Blog-Serie werde ich Sie durch die Grundlagen der Graph-Technologie führen, vorausgesetzt, Sie haben wenig (oder keinen) Hintergrund im Raum. In den letzten Wochen haben wir uns damit beschäftigt, warum die Graphentechnologie die Zukunft ist, warum verbundene Daten wichtig sind, die Grundlagen (und Fallstricke) der Datenmodellierung, warum eine Datenbankabfragesprache wichtig ist, die Unterschiede zwischen imperativen und deklarativen Abfragesprachen, Vorhersagemodellierung mit Graphentheorie, die Grundlagen von Graph Search Algorithmen und warum wir NoSQL-Datenbanken brauchen.
Diese Woche werfen wir einen genaueren Blick auf die wichtigsten Unterschiede zwischen ACID- und BASE-Datenbankkonsistenzmodellen und was ihre Kompromisse für Ihre Datentransaktionen bedeuten.

Das ACID-Konsistenzmodell

Viele Entwickler kennen ACID-Transaktionen aus der Arbeit mit relationalen Datenbanken. Als solches ist das SAURE Konsistenzmodell seit einiger Zeit die Norm.
Der Schlüssel ACID Garantie ist, dass es eine sichere Umgebung, in der auf Ihre Daten zu betreiben bietet. Das ACID-Akronym steht für:
Atomic

• Alle Operationen in einer Transaktion sind erfolgreich oder jede Operation wird zurückgesetzt.

Konsistent

• Nach Abschluss einer Transaktion ist die Datenbank strukturell einwandfrei.

Isolierte

• Transaktionen konkurrieren nicht miteinander. Der umstrittene Zugriff auf Daten wird von der Datenbank moderiert, sodass Transaktionen scheinbar sequenziell ausgeführt werden.

Dauerhaft

• Die Ergebnisse der Anwendung einer Transaktion sind auch bei Fehlern dauerhaft.

ACID-Eigenschaften bedeuten, dass, sobald eine Transaktion abgeschlossen ist, ihre Daten konsistent (Tech-Jargon: Schreibkonsistenz) und stabil auf der Festplatte sind, was mehrere verschiedene Speicherorte beinhalten kann.
Schreiben Konsistenz ist eine wunderbare Sache für Anwendungsentwickler, aber es erfordert auch anspruchsvolle Sperren, die in der Regel ein Schwergewicht Muster für die meisten Anwendungsfälle ist.Wenn es um NoSQL-Technologien geht, verwenden die meisten Graphdatenbanken (einschließlich Neo4j) ein ACID-Konsistenzmodell, um sicherzustellen, dass Daten sicher und konsistent gespeichert sind.

Das Basiskonsistenzmodell

Für viele Domänen und Anwendungsfälle sind ACID-Transaktionen weitaus pessimistischer (dh sie sorgen sich mehr um die Datensicherheit), als es die Domäne tatsächlich erfordert.In der NoSQL-Datenbankwelt sind ACID-Transaktionen weniger in Mode, da einige Datenbanken die Anforderungen an sofortige Konsistenz, Datenaktualität und Genauigkeit gelockert haben, um andere Vorteile wie Skalierbarkeit und Ausfallsicherheit zu erzielen.
(Insbesondere die .NET-basierte RavenDB hat sich dem Trend unter den Aggregatspeichern bei der Unterstützung von ACID-Transaktionen widersetzt.)
So funktioniert das BASIS-Akronym:
Basic Availability

• Die Datenbank scheint die meiste Zeit zu funktionieren.

Soft-state

• Stores müssen weder schreibkonsistent sein, noch müssen verschiedene Replikate ständig konsistent sein.

Eventuelle Konsistenz

• Speichert die Konsistenz zu einem späteren Zeitpunkt (z. B. träge zur Lesezeit).

Basiseigenschaften sind viel lockerer als Säuregarantien, aber es gibt keine direkte Eins-zu-Eins-Zuordnung zwischen den beiden Konsistenzmodellen (ein Punkt, der wahrscheinlich nicht überbewertet werden kann).Ein Basisdatenspeicher bewertet die Verfügbarkeit (da dies für die Skalierung wichtig ist), bietet jedoch keine garantierte Konsistenz der replizierten Daten zum Zeitpunkt des Schreibens. Insgesamt bietet das Basiskonsistenzmodell eine weniger strenge Sicherheit als ACID: Daten werden in Zukunft konsistent sein, entweder zur Lesezeit (z. B. Riak) oder sie werden immer konsistent sein, jedoch nur für bestimmte verarbeitete vergangene Snapshots (z. B. Datomic).
Das Basiskonsistenzmodell wird hauptsächlich von Aggregatspeichern verwendet, einschließlich Spaltenfamilien-, Schlüsselwert- und Dokumentspeichern.

Hyaluronsäure vs. BASE Trade-offs

Es gibt keine richtige Antwort darauf, ob Ihre Anwendung ein SÄURE-BASEN-Konsistenzmodell benötigt. Entwickler und Datenarchitekten sollten ihre Datenkonsistenzkonflikte von Fall zu Fall auswählen – nicht nur auf der Grundlage dessen, was im Trend liegt oder welches Modell zuvor verwendet wurde.
Angesichts der losen Konsistenz von BASE müssen Entwickler sachkundiger und strenger mit konsistenten Daten umgehen, wenn sie einen Basisspeicher für ihre Anwendung auswählen. Es ist wichtig, mit dem Basisverhalten des ausgewählten Aggregatspeichers vertraut zu sein und innerhalb dieser Einschränkungen zu arbeiten.Auf der anderen Seite kann die Planung um Basisbeschränkungen herum manchmal ein großer Nachteil sein, verglichen mit der Einfachheit von ACID-Transaktionen. Eine vollständig saure Datenbank ist die perfekte Lösung für Anwendungsfälle, in denen Datenzuverlässigkeit und -konsistenz unerlässlich sind (Banking, irgendjemand?).
In den kommenden Wochen werden wir uns mit mehr SÄURE / BASE-Besonderheiten befassen, wenn es um Aggregatspeicher und andere Diagrammtechnologien geht.

Informieren Sie sich über den Rest der Graph-Datenbanken für Anfänger Serie:

• Warum Graph-Technologie ist die Zukunft
• Warum Connected Data Matters
• Die Grundlagen der Datenmodellierung
• Datenmodellierung Fallstricke zu vermeiden
• Warum eine Datenbank-Abfragesprache Matters (mehr als Sie denken)
• Imperative vs. deklarative Abfragesprachen: Was ist der Unterschied?
• Graphentheorie & Vorhersagemodellierung
• Grundlagen des Graph-Suchalgorithmus
• Warum wir NoSQL-Datenbanken brauchen
• Eine Tour durch Aggregatspeicher
• Andere Graph-Datentechnologien
• Native vs. nicht-native Graph-Technologie