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.