Die Anwendung Konsistenz Methoden in NoSQL

Das Konsistenz

Eigenschaft einer Datenbank bedeutet, dass, sobald Daten erfolgreich in eine Datenbank geschrieben wird, Abfragen, die auf die Daten zugreifen können folgen und eine konsistente Sicht der Daten erhalten. In der Praxis bedeutet dies, dass, wenn Sie einen Datensatz in einer Datenbank zu schreiben und dann fordern Sie sofort, dass Datensatz, sind Sie es, um zu sehen garantiert. Es ist besonders nützlich für Dinge wie Amazon Aufträge und Überweisungen.

Konsistenz ist eine gleitende Skala, aber, und ein Thema zu tief hier zu decken. Doch in der NoSQL-Welt, die Konsistenz der Regel fällt in eine von zwei Lager:

• ACID Konsistenz (ACID steht für Unteilbarkeit, Konsistenz, Isolation, Durability): ACID bedeutet, dass einmal Daten geschrieben werden, Ihnen die volle Konsistenz in liest.

• Eventual Consistency (BASE): BASE bedeutet, dass, sobald Daten geschrieben werden, wird es schließlich zum Lesen angezeigt.

Ein Kampf wurde zwischen den Menschen gerast, die starke Konsistenz in einer Datenbank glauben ist nicht erforderlich, und diejenigen, die es unbedingt glauben erforderlich (übersetzen Menschen nach NoSQL Unternehmen Marketing-Abteilungen!).

Die Realität liegt irgendwo dazwischen. Ist es wichtig, dass eine Person, die Facebook-Post nicht von allen seinen Freunden für fünf Minuten zu sehen ist? Nein, wahrscheinlich nicht. Veränderung # 147-Facebook post # 148- bis # 147-Milliarden-# 8208-Dollar # 8208-Finanztransaktion, # 148- aber, und Ihre Haltung ändert sich schnell! Welche Konsistenz Ansatz Sie wählen, hängt von der Situation ab. Nach meiner Erfahrung ist jedoch, starke Konsistenz immer die Wahl in der Mission # 8208 kritischen Enterprise-System-Situationen.

ACID

ACID ist ein allgemeiner Satz von Prinzipien für Transaktionssysteme, nicht etwas rein zu relationalen Systemen verknüpft, oder auch nur Datenbanken, also ist es gut Wertes zu. ACID im Grunde bedeutet, # 147-Diese Datenbank hat Einrichtungen, die Sie von verderblichen oder den Verlust von Daten zu stoppen,# 148-, der nicht für alle Datenbanken gegeben ist. In der Tat bieten die überwiegende Mehrheit der NoSQL-Datenbanken nicht ACID Garantien.

Stiftung DB, Marklogic, und Neo4j sind bemerkenswerte Ausnahmen. Einige NoSQL-Datenbanken bieten eine niedrigere # 8208-Grade-Garantie in Anspruch genommen Prüfen und einstellen dass überprüft, ob jemand anderes ein Dokument, bevor so dass eine Transaktion abzuschließen verändert hat. Dieses Verhalten ist in der Regel begrenzt, da es dazu neigt, auf einer einzigen # 8208-Satzbasis umgesetzt werden.

MongoDB ist eine bemerkenswerte Datenbank, die prüfen und einstellen Funktionen zur Verfügung stellt. Mit MongoDB, ein ganzer Knoten # 8208-Wert von Daten können während einer Aktualisierung gesperrt werden, wodurch verhindert wird alle lesen und alle Schreiboperationen, bis der Vorgang abgeschlossen ist. Das Unternehmen arbeitet diese Beschränkung auf die Beseitigung, wenn.

BASE

BASE bedeutet, dass anstatt ACID Garantien machen, die Datenbank eine abstimmbare Balance von Konsistenz und Datenverfügbarkeit hat. Dies ist in der Regel der Fall, wenn Knoten in einer bestimmten Datenbank-Cluster fungieren als primäre Manager eines Teils der Datenbank und andere Knoten lesen halten # 8208-nur Repliken.

Um sicherzustellen, dass jeder Kunde alle Updates sieht (das heißt, sie eine einheitliche Sicht auf die Daten haben), ein Schreiben auf dem Primärknoten die Daten halten muss sperren, bis alle lesen Repliken sind auf dem neuesten Stand. Dies nennt man eine zwei# 8208-Phasen-Commit - die Veränderung wird lokal gemacht, sondern nur auf den Client angewendet und bestätigt, wenn alle anderen Knoten aktualisiert werden.

BASE entspannt diese Anforderung und erfordert nur eine Teilmenge der Knoten die gleichen Daten halten, um aktualisiert zu werden für die Transaktion erfolgreich zu sein. Einige Zeit nach der Transaktion festgeschrieben wird, wird die Lese # 8208-Replik nur aktualisiert.

Der Vorteil dieses Ansatzes besteht darin, dass Transaktionen schneller verpflichtet. lesbar Live-Repliken zu haben, bedeutet auch können Sie Ihre Daten lesen Last verteilen, das Lesen schneller zu machen.

Der Nachteil ist, dass die Kunden auf einige der Lese Repliken Verbindungs ​​# sehen aus kann 8208-of # 8208 aktuelle Informationen für einen unbestimmten Zeitraum. In einigen Szenarien ist dieser Zustand in Ordnung. Wenn Sie eine neue Nachricht auf Facebook und einige Ihrer Freunde veröffentlichen sehen es nicht für ein paar Minuten, dann ist es kein großer Verlust. Wenn Sie einen Zahlungsauftrag an Ihre Bank senden, obwohl, können Sie eine sofortige Transaktion soll.

Ein alternativer Ansatz # 8208-nur Repliken zu lesen, ist ein zu haben, gemeinsam genutzt# 8208-nichts Cluster, in dem nur ein Knoten in einem Cluster dient immer einen bestimmten Teil der Datenbank.

Gemeinsame # 8208-nichts bedeutet nicht, Sie Replikation verlieren, wenn. Datenbanken, die diese Methode verwenden typischerweise tun, um ihre Daten an einen sekundären Bereich auf einem anderen Primärknoten oder Knoten repliziert werden - aber nur ein Knoten ist der Master für liest und zu jeder Zeit schreibt.

Gemeinsame # 8208-Nothing Cluster haben den Vorteil einer einfacheren Konsistenzmodell, sondern erfordern eine zwei # 8208-Phase zu Repliken begehen. Diese Tatsache bedeutet, dass die Transaktionssperren, während alle Replikate aktualisiert werden. (Eine interne Sperre sowie für andere Knoten Sperren gibt Ihnen zwei Phasen.)

Dies hat in der Regel weniger Einfluss als gemeinsam genutzte Daten-Cluster mit Nur-Lese-Repliken, obwohl, weil geteilt # 8208-nichts Replik Datenbereiche Leseanforderungen nicht für den Teil der Datenbank erhalten. Daher sind zwei # 8208-Phasen-Commits schneller auf einem gemeinsamen # 8208-Cluster nichts als auf einem Cluster mit lesbaren Repliken.

Die Wahl Säure oder Base?

Wie zu erwarten, ist viel von dem Argument, weil NoSQL-Anbieter, sich von ihren Mitbewerbern, indem sie behaupten, eine andere, einzigartige Ansatz unterscheiden kann. Es ist interessant, zu beachten Sie jedoch, die Zahl der NoSQL-Anbieter mit ACID # 8208 Einhaltung ihrer Roadmap.

Einige NoSQL-Datenbanken haben ACID # 8208-Compliance auf ihre Roadmap, obwohl sie sind Befürworter von BASE, die zeigt, wie relevant ACID Garantien zu Unternehmen, Mission# 8208-kritisch Systemen.

Viele Unternehmen nutzen BASE # 8208-Konsistenz Produkte, wenn Ideen zu testen, weil sie frei sind, aber dann zu einem ACID # 8208-konformen bezahlt # 8208-für-Datenbank migrieren, wenn sie live auf einer Mission # 8208 kritisches System gehen wollen.

Der einfachste Weg, um zu entscheiden, ob Sie ACID müssen, ist, die Wechselwirkungen Menschen und andere Systeme mit Ihren Daten haben zu prüfen. Zum Beispiel, wenn Sie Daten hinzufügen oder aktualisieren, ist es wichtig, dass die nächsten Abfrage der Lage ist, um die Änderung zu sehen? Mit anderen Worten, hängen wichtige Entscheidungen über den aktuellen Zustand der Datenbank? Würde sehen etwas aus # 8208-of # 8208 aktuelle Daten bedeuten, dass diese Entscheidungen tödlich fehlerhaft sein könnte?

Im Finanzdienstleistungen, ist die Notwendigkeit, für die Konsistenz der Hand. Denken Sie an Händler den Kauf Lager. Sie brauchen die Cash-Balance zu überprüfen, bevor der Handel, um sicherzustellen, dass sie das Geld haben, um den Handel zu decken. Wenn sie nicht die richtige Balance zu sehen, werden sie sich entscheiden, Geld für eine andere Transaktion zu verbringen. Wenn die Datenbank sind Abfragen sie nur schließlich konsistent ist, können sie nicht einen Mangel an ausreichenden Mitteln zu sehen, was ihre Organisation eine finanzielle Risiko auszusetzen.

Ähnliche Fälle können für ACID über BASE im Gesundheitswesen, Verteidigung, Intelligenz und anderen Sektoren gebaut werden. Es läuft alles auf die Daten nach unten, aber, und die Bedeutung sowohl Aktualität und Datensicherheit.