Können NoSQL-Datenbanken gelegentlich Datenverlust verursachen?

8

Ich evaluiere derzeit Datenbanken für ein neues Projekt, bei dem große Mengen an Handelsdaten eingefügt und abgefragt werden müssen. Unser Team neigt zu Cassandra, aber dann habe ich diesen Artikel gelesen, der darauf hindeutet, dass die Verwendung von nicht ACID-kompatiblen Datenbanken zu gelegentlichem Datenverlust führen kann:

http://www.dbms2.com/2010/09/21/acid-compliant-transaction-integrity/

Ich kann keine weiteren Informationen dazu im Internet finden und kann nicht verstehen, wie Nicht-ACID-Konformität zu Datenverlust führen kann. Kann jemand etwas Licht ins Dunkel bringen?

del
quelle
Neo4j ist eine NOSQL (Graph) -Datenbank, die tatsächlich ACID- kompatibel ist . Es kommt mit vollständiger Transaktionsunterstützung und dauerhafter Persistenz. Neo4j verwendet auch Transaktionsprotokolle, um Schreibvorgänge zu sichern, bevor sie auf den Datenspeicher angewendet werden. Haftungsausschluss: Ich arbeite für Neo Technology.
Michael Hunger
3
Nach Murphys Gesetz (und meiner eigenen Erfahrung) können Sie mit jeder Datenbank Daten verlieren .
a_horse_with_no_name
Eine bessere Formulierung könnte lauten: "Haben NoSQL-Datenbanken eine signifikant höhere Wahrscheinlichkeit für Datenverlust oder -beschädigung als herkömmliche RDBMS?" Immer noch etwas vage.
Jon of All Trades
Mehrere NoSQL-Produkte bieten einzeilige ACIDity. Nur wenige bieten mehrreihige Säuren an. Wenn es sich bei Ihrem Anwendungsfall um Stream-Single-Key-Schreibvorgänge handelt, können Sie erfolgreich sein. In vielen Geschäftsbereichen ist es wichtig, dass mehrere Zeilen gleichzeitig konsistent sind, bevor eine Änderung vorgenommen wird.
Michael Green

Antworten:

6

ACID bedeutet

  • Atomizität
  • Konsistenz
  • Isolation
  • Haltbarkeit

Für Sie bedeutet dies, dass "jede Schreibaktion nur einmal ausgeführt wird (keine doppelten Datensätze), aber nach Abschluss der Aktion vollständig in der Datenbank gespeichert wird" und dass Sie jedes Mal, wenn Sie lesen, die gewünschten Daten erhalten .

Das Besondere an den NoSQL-Datenbanken ist, dass sie häufig verteilt sind (genau das wollen die Leute, flach skalierbare Systeme, die billig sind), was bedeutet, dass es Zeit braucht, um die Daten auf alle Knoten zu replizieren. Manchmal ist es möglich, während eines Schreibvorgangs zu lesen und die alten Daten zu erhalten, während die neuen Daten herauskommen.

Sie opfern Reinheit für Geschwindigkeit.

Dies ist die Kurzversion meiner Antwort, und ich bin mir nicht sicher, was ich weiter erklären muss. Stell mir Fragen!

jcolebrand
quelle
1
Was Sie beschreiben, klingt nach sofortiger Konsistenz (RDBMS) und eventueller Konsistenz (NoSQL). Doch die verlinkten Artikel spricht über tatsächlich verlieren Daten (nicht nur inkonsistente Daten mit), und ich verstehe nicht, was ACID Einhaltung von Datenverlust zu tun hat.
del
1
Haltbarkeit höchstwahrscheinlich. Und das ist der Fall, das beschreibe ich (was den Anschein erweckt, dass Daten verloren gegangen sind). Der Punkt bei ACID ist, dass Sie keine Daten verlieren können. Je. (
Nun,
Alle von mir untersuchten NoSQL-Datenbanken (HBase, Cassandra, Redis) verwenden Write-Ahead-Protokolle, die abgespielt werden können, falls die Datenbank abstürzt, bevor Änderungen beibehalten werden. Bedeutet das, dass diese Kritik für keine dieser Datenbanken gilt?
del
Das würde ich mir vorstellen. Ich werde dies morgen noch einmal wiederholen, aber vorerst vor dem Schlafengehen. Hoffentlich bekommst du vorher noch einen anderen Input als meinen
;-)
6

Obwohl dies eine jahrelange Frage ist ...

Kurz gesagt, Sie können ACID als Garantie für Datenintegrität / -sicherheit unter allen erwarteten Umständen verstehen . Wie bei der generischen Programmierung entstehen alle Kopfschmerzen durch Multithreading.

Das größte Problem bei NoSQL ist hauptsächlich ACI. D (Urabilität) ist normalerweise ein getrenntes Thema.

Wenn Ihre Datenbank Single-Threaded ist und nur ein Benutzer gleichzeitig darauf zugreifen kann, ist dies nativ ACI-konform. Aber ich bin sicher, dass praktisch kein Server diesen Luxus haben kann.

Wenn Ihre Datenbank über mehrere Threads verfügen muss - mehrere Benutzer / Clients gleichzeitig bedienen -, müssen Sie eine ACI-kompatible Transaktion benötigen. Oder Sie erhalten eher eine stille Datenbeschädigung als einen einfachen Datenverlust. Welches ist viel schrecklicher. Dies ist einfach genau das gleiche mit der generischen Multithread-Programmierung. Wenn Sie nicht über einen geeigneten Mechanismus wie Sperren verfügen, erhalten Sie undefinierte Daten. Und der Mechanismus in der DB nennt sich vollständige ACID-Konformität .

Viele YesSQL / NoSQL-Datenbanken bewerben sich als ACID-konform, aber tatsächlich sind es nur sehr wenige.

  • Keine ACID-Konformität = In einer Mehrbenutzerumgebung (Client) erhalten Sie immer ein undefiniertes Ergebnis. Ich denke nicht einmal, was für eine DB das macht.

  • Einzelne Zeile / Schlüssel ACID-konform = Sie erhalten ein garantiertes Ergebnis, wenn Sie nur einen einzelnen Wert gleichzeitig ändern. Aber undefiniertes Ergebnis (= stille Datenbeschädigung) für gleichzeitige Aktualisierung mehrerer Zeilen / Schlüssel. Die meisten derzeit beliebten NoSQL-DBs, einschließlich Cassandra, MongoDB, CouchDB usw. Diese Art von DBs sind nur für einzeilige Transaktionen sicher. Sie müssen also sicherstellen, dass Ihre DB-Logik nicht mehrere Zeilen in einer Transaktion berührt.

  • ACID-Konformität mit mehreren Zeilen / Schlüsseln = Sie erhalten für jede Operation immer ein garantiertes Ergebnis. Dies ist eine Mindestanforderung als RDBMS. Im NoSQL-Bereich tun dies nur sehr wenige. Spanner, MarkLogic, VoltDB, FoundationDB. Ich bin mir nicht mal sicher, ob es mehr Lösungen gibt. Diese Art von DBs ist wirklich frisch und neu, daher ist meist nichts über ihre Fähigkeiten oder Einschränkungen bekannt.

Auf jeden Fall ist dies ein Vergleich mit Ausnahme von D (Urabilität). Vergessen Sie also nicht, auch das Haltbarkeitsattribut zu überprüfen. Es ist sehr schwer, die Haltbarkeit zu vergleichen, da die Reichweite zu groß wird. Ich kenne dieses Thema nicht gut ...

  • Keine Haltbarkeit. Sie werden jederzeit Daten verlieren.

  • Sicher auf der Festplatte gespeichert. Wenn Sie erhalten COMMIT OK, werden die Daten auf der Festplatte garantiert. Sie haben Daten verloren, wenn die Festplatte beschädigt wurde.

Auch bei ACID-kompatiblen DBs gibt es Unterschiede.

  • Manchmal ACID-konform / Sie benötigen eine Konfiguration / kein automatisches Etwas .. / Einige Komponenten sind nicht ACID-konform / sehr schnell, aber Sie müssen etwas dafür ausschalten ... / ACID-konform, wenn Sie ein bestimmtes Modul verwenden ... = wir Die Datensicherheit wird standardmäßig nicht gebündelt. Das ist ein Add-On, eine Option oder ein separater Verkauf. Vergessen Sie nicht, den richtigen Befehl herunterzuladen, zusammenzubauen, einzurichten und auszugeben. Auf jeden Fall kann die Datensicherheit stillschweigend ignoriert werden. Mach es selbst. Überprüfen Sie es selbst. Viel Glück, keinen Fehler zu machen. Jeder in Ihrem Team muss ein fehlerfreier DBA sein, um diese Art von DB sicher zu verwenden. MySQL.

  • Immer ACID-konform = Wir tauschen Datensicherheit nicht mit Leistung oder irgendetwas. Datensicherheit ist ein erzwungenes Bündel mit diesem DB-Paket. Die meisten kommerziellen RDBMS, PostgreSQL.

Oben ist die typische Implementierung der DB dargestellt. Trotzdem kann jeder andere Hardwarefehler die Datenbank beschädigen. Wie Speicherfehler, Datenkanalfehler oder andere mögliche Fehler. Sie benötigen also zusätzliche Redundanz, und eine echte DB in Produktionsqualität muss Fehlertoleranzfunktionen bieten.

  • Keine Redundanz. Sie verlieren alle Daten, wenn Ihre Daten beschädigt sind.

  • Backup. Sie erstellen eine Snapshot-Kopie / Wiederherstellung. Sie verlieren Daten nach der letzten Sicherung.

  • Online-Backup. Sie können eine Snapshot-Sicherung durchführen, während die Datenbank ausgeführt wird.

  • Asynchrone Replikation. Backup für jede Sekunde (oder einen bestimmten Zeitraum). Wenn der Computer ausfällt, garantiert diese Datenbank, dass die Daten durch einen Neustart wiederhergestellt werden. Sie verlieren Daten nach der letzten Sekunde.

  • Synchrone Replikation. Sichern Sie sofort für jedes Datenupdate. Sie haben immer eine exakte Kopie der Originaldaten. Verwenden Sie die Kopie, wenn der Ursprung bricht.

Bis jetzt sehe ich, dass vielen DB-Implementierungen viele davon fehlen. Und ich denke, wenn ihnen die richtige Unterstützung für ACID und Redundanz fehlt, werden Benutzer irgendwann Daten verlieren.

Eonil
quelle
5

"Es kommt darauf an" ist die Antwort - es gibt Konfigurationsoptionen, die hier erwähnt werden .

Kleiner Nitpick: Eine Datenbank kann dauerhaft sein, ist jedoch nicht ACID-konform, da ACID die Obermenge der Funktionen (ACID) ist. Ich glaube nicht, dass eine NoSQL-Datenbank behaupten kann, vollständig ACID zu sein, aber viele von ihnen behaupten möglicherweise, einzelne Teilanforderungen wie die Haltbarkeit zu erfüllen.

Morgan Tocker
quelle