Anche se questa è una domanda vecchia di anni ...
In breve, puoi comprendere ACID come garanzia di integrità / sicurezza dei dati in qualsiasi circostanza prevista . Come nella programmazione generica, tutti i mal di testa provengono dal multi-threading.
Il problema più grande su NoSQL è principalmente ACI. D (urabilità) è di solito un problema separato.
Se il tuo DB è a thread singolo - quindi solo un utente può accedere contemporaneamente -, è nativamente conforme ACI. Ma sono sicuro che praticamente nessun server può avere questo lusso.
Se il tuo DB deve essere multi-thread - servire più utenti / client contemporaneamente - è necessario disporre di una transazione conforme ACI. Oppure otterrai una corruzione silenziosa dei dati anziché una semplice perdita di dati. Il che è molto più orribile. Semplicemente, questo è esattamente lo stesso con la programmazione multi-thread generica. Se non si dispone di un meccanismo adeguato come il blocco, si otterranno dati non definiti. E il meccanismo in DB chiamato conformità completamente ACID .
Molti database YesSQL / NoSQL si pubblicano come compatibili con ACID, ma in realtà pochissimi di loro lo fanno davvero.
Nessuna conformità ACID = Otterrai un risultato sempre indefinito nell'ambiente multiutente (client). Non penso nemmeno che tipo di DB faccia questo.
Riga singola / chiave Conformità ACID = Otterrai un risultato garantito se modifichi solo un singolo valore alla volta. Ma risultato indefinito (= danneggiamento silenzioso dei dati) per l'aggiornamento simultaneo di più righe / chiavi. La maggior parte dei DB NoSQL attualmente popolari, inclusi Cassandra, MongoDB, CouchDB, ... Questo tipo di DB è sicuro solo per le transazioni a riga singola. Quindi è necessario garantire che la logica del DB non tocchi più righe in una transazione.
Conformità ACID a più righe / chiavi = Otterrete sempre risultati garantiti per qualsiasi operazione. Si tratta di requisiti minimi come RDBMS. Nel campo NoSQL, pochi di loro lo fanno. Spanner, MarkLogic, VoltDB, FoundationDB. Non sono nemmeno sicuro che ci siano più soluzioni. Questi tipi di DB sono davvero nuovi e nuovi, quindi non si sa quasi nulla delle loro capacità o limitazioni.
Comunque, questo è un confronto tranne D (urabilità). Quindi non dimenticare di controllare anche l'attributo di durabilità. È molto difficile confrontare la durabilità perché la gamma diventa troppo ampia. Non conosco bene questo argomento ...
Nessuna durata. Perderai i dati in qualsiasi momento.
Archiviato in modo sicuro su disco. Quando ottieni COMMIT OK, i dati sono garantiti sul disco. Hai perso i dati in caso di rottura del disco.
Inoltre, ci sono differenze anche sui DB conformi ACID.
A volte conforme ACID / è necessaria la configurazione / nessuna opzione automatica .. / alcuni componenti non sono compatibili ACID / molto veloci ma è necessario disattivare qualcosa per questo ... / conforme ACID se si utilizza un modulo specifico ... = noi non raggrupperà la sicurezza dei dati per impostazione predefinita. È un componente aggiuntivo, un'opzione o venduto separatamente. Non dimenticare di scaricare, assemblare, configurare ed emettere il comando corretto. Ad ogni modo, la sicurezza dei dati può essere ignorata silenziosamente. Fallo da solo. Controllalo tu stesso. Buona fortuna a non commettere errori. Tutti i membri del team devono essere DBA impeccabili per utilizzare questo tipo di DB in modo sicuro. MySQL.
Sempre conforme ACID = Non scambiamo la sicurezza dei dati con prestazioni o altro. La sicurezza dei dati è un pacchetto forzato con questo pacchetto DB. RDBMS più commerciale, PostgreSQL.
Sopra è la tipica implementazione di DB. Tuttavia, qualsiasi altro errore hardware può danneggiare il database. Come errore di memoria, errore del canale dati o altri possibili errori. Quindi è necessaria una ridondanza aggiuntiva e un DB di qualità di produzione reale deve offrire funzionalità di tolleranza agli errori.
Nessuna ridondanza. Si perdono tutti i dati se i dati sono danneggiati.
Backup. Si esegue la copia / ripristino dell'istantanea. Si perdono dati dopo l'ultimo backup.
Backup online. È possibile eseguire il backup dell'istantanea mentre il database è in esecuzione.
Replica asincrona. Backup per ogni secondo (o periodo specificato). Se la macchina è inattiva, questo DB ha garantito il recupero dei dati al solo riavvio. Si perdono dati dopo l'ultimo secondo.
Replica sincrona. Effettua immediatamente il backup per ogni aggiornamento dei dati. Hai sempre una copia esatta dei dati originali. Usa la copia se l'origine si interrompe.
Fino ad ora, vedo che l'implementazione di molti DB manca di molti di questi. E penso che se mancano il corretto supporto ACID e ridondanza, gli utenti alla fine perderanno i dati.