2
In realtà c'era FoundationDB che era compatibile con l'acido. Ora Apple l'ha afferrato
—
l'utente senza cappello il
Risposte:
Pubblicherò questo come una risposta puramente a supporto della conversazione: Tim Mahy , Nawroth e CraigTP hanno suggerito database praticabili. CouchDB sarebbe il mio preferito a causa dell'uso di Erlang , ma ce ne sono altri là fuori.
Direi che ACID non contraddice o nega il concetto di NoSQL ... Mentre sembra che ci sia una tendenza che segue l'opinione espressa da Dove , direi che i concetti sono distinti.
NoSQL si basa fondamentalmente sul semplice schema chiave-valore (ad esempio Redis) o sullo stile di documento (coppie chiave-valore raccolte in un modello di "documento", ad esempio MongoDB) come alternativa diretta allo schema esplicito nei classici RDBMS. Permette allo sviluppatore di trattare cose in modo asimmetrico, mentre i motori tradizionali hanno imposto la stessa rigidità nel modello di dati. Il motivo per cui è così interessante è perché offre un modo diverso di gestire i cambiamenti e per insiemi di dati più grandi offre interessanti opportunità per gestire volumi e prestazioni.
ACID fornisce i principi che regolano il modo in cui le modifiche vengono applicate a un database. In un modo molto semplificato, afferma (la mia versione):
La conversazione diventa un po 'più eccitabile quando si tratta dell'idea di propagazione e vincoli . Alcuni motori RDBMS offrono la possibilità di imporre vincoli (ad es. Chiavi esterne) che possono avere elementi di propagazione (a cascata ). In termini più semplici, una "cosa" potrebbe avere una relazione con un'altra "cosa" nel database e, se si modifica un attributo di uno, potrebbe essere necessario modificare l'altro (aggiornato, eliminato, ... molte opzioni). I database NoSQL , essendo prevalentemente (al momento) focalizzati su elevati volumi di dati e traffico elevato, sembrano affrontare l'idea di aggiornamenti distribuiti che avvengono all'interno (dal punto di vista del consumatore) di intervalli di tempo arbitrari. Questa è sostanzialmente una forma specializzata di transazione di replica gestita tramite - quindi direi che se un database distribuito tradizionale può supportare ACID, così può fare un database NoSQL.
Alcune risorse per ulteriori letture:
AGGIORNAMENTO (27 luglio 2012): il collegamento all'articolo Wikipedia è stato aggiornato per riflettere la versione dell'articolo che era attuale al momento della pubblicazione di questa risposta. Si prega di notare che l' attuale articolo di Wikipedia è stato ampiamente rivisto!
Bene, secondo una versione precedente di un articolo di Wikipedia su NoSQL :
NoSQL è un movimento che promuove una classe vagamente definita di archivi di dati non relazionali che si infrangono con una lunga storia di database relazionali e garanzie ACID.
e anche:
Il nome era un tentativo di descrivere l'emergere di un numero crescente di archivi di dati distribuiti non relazionali che spesso non tentavano di fornire garanzie ACID.
e
I sistemi NoSQL forniscono spesso garanzie di coerenza debole come l'eventuale coerenza e transazioni limitate a singoli elementi di dati, anche se è possibile imporre garanzie ACID complete aggiungendo un livello middleware supplementare.
Quindi, in breve, direi che uno dei principali vantaggi di un archivio dati "NoSQL" è la sua netta mancanza di proprietà ACID . Inoltre, IMHO, più si cerca di implementare e applicare le proprietà ACID , più lontano dallo "spirito" di un archivio dati "NoSQL" si ottiene e più si avvicina a un "vero" RDBMS che si ottiene (relativamente parlando, ovviamente ).
Tuttavia, tutto ciò che ha detto, "NoSQL" è un termine molto vago ed è aperto a interpretazioni individuali e dipende fortemente da quanto di un punto di vista purista hai. Ad esempio, la maggior parte dei nostri giorni RDBMS sistemi in realtà non aderiscono a tutti di Edgar F. Codd 's 12 regole del suo modello di relazione !
Adottando un approccio pragmatico, sembrerebbe che il CouchDB di Apache si avvicini di più all'incarnazione di entrambi gli ACID-compliance mantenendo allo stesso tempo una mentalità "NoSQL" non accoppiata.
Assicurati di leggere l'introduzione di Martin Fowler sui database NoSQL . E il video corrispondente.
Innanzitutto, possiamo distinguere due tipi di database NoSQL:
In base alla progettazione, la maggior parte dei database orientati ai grafici sono ACID !
Quindi, per quanto riguarda gli altri tipi?
Nei database orientati agli aggregati, possiamo inserire tre sottotipi:
Ciò che qui chiamiamo un aggregato , è ciò che Eric Evans ha definito nel suo design guidato dal dominio come autosufficiente di entità e oggetti valore in un dato contesto limitato.
Di conseguenza, un aggregato è una raccolta di dati con cui interagiamo come unità. Gli aggregati formano i limiti per le operazioni ACID con il database. (Martin Fowler)
Quindi, a livello di aggregazione, possiamo dire che la maggior parte dei database NoSQL può essere sicura come ACID RDBMS , con le impostazioni appropriate. Di origine, se ottimizzi il tuo server per la massima velocità, potresti entrare in qualcosa di non ACID. Ma la replica aiuterà.
Il mio punto principale è che devi usare i database NoSQL così come sono, non come alternativa (economica) a RDBMS. Ho visto troppi progetti abusare delle relazioni tra documenti. Questo non può essere ACID. Se rimani a livello di documento, ovvero a confini aggregati, non hai bisogno di alcuna transazione. E i tuoi dati saranno al sicuro come con un database ACID, anche se non veramente ACID, dal momento che non hai bisogno di quelle transazioni! Se hai bisogno di transazioni e aggiorni più "documenti" contemporaneamente, non sei più nel mondo NoSQL - usa invece un motore RDBMS!
alcuni aggiornamenti del 2019: a partire dalla versione 4.0, per situazioni che richiedono atomicità per gli aggiornamenti di più documenti o coerenza tra le letture di più documenti, MongoDB fornisce transazioni multi-documento per set di repliche .
FoundationDB è conforme ACID:
Dispone di transazioni appropriate, quindi è possibile aggiornare più elementi di dati diversi in modo ACID. Questo è usato come base per mantenere gli indici ad un livello superiore.
In questa domanda qualcuno deve menzionare OrientDB : OrientDB è un database NoSQL, uno dei pochi, che supporta transazioni completamente ACID. ACID non è solo per RDBMS perché non fa parte dell'algebra relazionale. Quindi è possibile avere un database NoSQL che supporti ACID.
Questa funzione è quella che mi manca di più in MongoDB
ACID e NoSQL sono completamente ortogonali. Uno non implica l'altro.
Ho un taccuino sulla mia scrivania, lo uso per tenere appunti su cose che devo ancora fare. Questo notebook è un database NoSQL. Lo interrogo usando una ricerca lineare con una "cache di pagina", quindi non devo sempre cercare ogni pagina. È inoltre conforme ACID, poiché mi assicuro di scrivere solo una cosa alla volta e mai mentre la sto leggendo.
NoSQL significa semplicemente che non è SQL. Molte persone si confondono e pensano che significhi archiviazione estremamente scalabile-selvaggio-ovest-super-veloce. Non Non significa archivio valori-chiave o eventuale coerenza. Tutto ciò che significa è "non SQL", ci sono molti database in questo pianeta e la maggior parte di essi non sono SQL [citazione necessaria] .
Puoi trovare molti esempi nelle altre risposte, quindi non ho bisogno di elencarli qui, ma ci sono database non SQL con conformità ACID per varie operazioni, alcuni sono solo ACID per le scritture di singoli oggetti mentre altri garantiscono molto di più. Ogni database è diverso.
"NoSQL" non è un termine ben definito. È un concetto molto vago. Pertanto, non è nemmeno possibile dire cosa sia e cosa non sia un prodotto "NoSQL". Non quasi tutti i prodotti tipicamente marchiati con l'etichetta sono negozi di valore-chiave.
Sì, MarkLogic Server è una soluzione NoSQL (database di documenti che mi piace chiamarlo) che funziona con le transazioni ACID
Il nonno di NoSQL: ZODB è conforme ACID. http://www.zodb.org/
Tuttavia, è solo Python.
Come uno dei creatori di NoSQL (sono stato uno dei primi collaboratori di Apache CouchDB e un relatore al primo evento NoSQL tenutosi alla CBS Interactive / CNET nel 2009) sono entusiasta di vedere nuovi algoritmi creare possibilità che prima non esistevano . Il protocollo Calvin offre un nuovo modo di pensare a vincoli fisici come CAP e PACELC .
Invece della replica asincrona attiva / passiva o della replica sincrona attiva / attiva, Calvin mantiene la correttezza e la disponibilità durante le interruzioni della replica utilizzando un protocollo simile a RAFT per mantenere un registro delle transazioni. Inoltre, le transazioni vengono elaborate in modo deterministico in ogni replica, eliminando il potenziale per deadlock, quindi l'accordo viene raggiunto con un solo giro di consenso. Questo lo rende veloce anche su distribuzioni multi-cloud in tutto il mondo.
FaunaDB è l'unica implementazione di database che utilizza il protocollo Calvin, rendendolo adatto in modo univoco ai carichi di lavoro che richiedono integrità dei dati simili a mainframe con scalabilità e flessibilità NoSQL.
Se stai cercando un archivio di chiavi / valori conforme ACID, c'è Berkeley DB . Tra i database dei grafici almeno Neo4j e HyperGraphDB offrono transazioni ACID (HyperGraphDB attualmente utilizza DB Berkeley per l'archiviazione di basso livello).
Questo concetto che i contributori di Wikipedia definiscono come:
[...] una classe di moderni sistemi di gestione di database relazionali che cercano di fornire le stesse prestazioni scalabili dei sistemi NoSQL per i carichi di lavoro di lettura-scrittura di elaborazione delle transazioni online (OLTP), pur mantenendo le garanzie ACID di un sistema di database tradizionale.
[1][2][3]
[1]Nancy Lynch e Seth Gilbert, "Congettura di Brewer e fattibilità di servizi web coerenti, disponibili e tolleranti alla partizione" , ACM SIGACT News, Volume 33 Numero 2 (2002), pag. 51-59.
[2] "Brewer's CAP Theorem" , julianbrowne.com, recuperato il 02-mar-2010
[3] "Teorema di Brewers CAP su sistemi distribuiti" , royans.net
MongoDB ha annunciato che la sua versione 4.0 sarà conforme ACID per le transazioni multi-documento.
Versione 4.2 si suppone che lo supporti con configurazioni frammentate.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB è stato menzionato e al momento non era open source. È stato aperto da Apple due giorni fa: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Credo che sia conforme ACID.
Per aggiungere alla lista di alternative, un altro database pienamente compatibile ACID NoSQL è GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (funzione ACID) è proprietario, ma Hyperdex è gratuito.
db4o
A differenza della persistenza roll-your-own o della serializzazione, db4o è sicuro per le transazioni ACID e consente di eseguire query, repliche e modifiche dello schema durante il runtime
Tarantool è un database NoSQL completamente ACID. È possibile emettere operazioni CRUD o stored procedure, tutto verrà eseguito in stretta conformità con una proprietà ACID. Puoi anche leggere questo qui: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic è anche compatibile ACID. Penso che sia uno dei più grandi giocatori ora.
BergDB è un database NoSQL leggero e open source progettato dall'inizio per eseguire transazioni ACID. In realtà, BergDB è "più" ACID rispetto alla maggior parte dei database SQL, nel senso che l' unico modo per cambiare lo stato del database è eseguire transazioni ACID con il livello di isolamento più elevato (termine SQL: "serializzabile"). Non ci saranno mai problemi con letture sporche, letture non ripetibili o letture fantasma.
A mio avviso, il database è ancora altamente performante; ma non fidarti di me, ho creato il software. Provalo tu stesso.
Molte moderne soluzioni NoSQL non supportano le transazioni ACID (aggiornamenti multi-chiave isolati atomici), ma la maggior parte di esse supporta primitive che consentono di implementare transazioni a livello di applicazione.
Se un archivio dati supporta la linearizzabilità per chiave e il confronto e l'insieme (atomicità a livello di documento), è sufficiente implementare le transazioni sul lato client, oltre a te hai diverse opzioni tra cui scegliere:
Se hai bisogno di un livello di isolamento serializzabile, puoi seguire lo stesso algoritmo utilizzato da Google per il sistema Percolator o Cockroach Labs per CockroachDB . Ne ho scritto un blog e ho creato una visualizzazione dettagliata , spero che ti possa aiutare a capire l'idea principale dietro l'algoritmo.
Se ti aspetti un alto livello di contesa, ma per te va bene avere il livello di isolamento Read Committed, dai un'occhiata alle transazioni RAMP di Peter Bailis.
Il terzo approccio consiste nell'utilizzare transazioni compensative note anche come modello di saga. È stato descritto alla fine degli anni '80 nel documento Sagas , ma è diventato più attuale con l'aumento dei sistemi distribuiti. Si prega di consultare il discorso sull'applicazione del modello Saga per ispirazione.
L'elenco di archivi di dati adatti per le transazioni lato client include Cassandra con transazioni leggere, Riak con bucket coerenti, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB e altri.
YugaByte DB supporta txns distribuiti conformi ACID e compatibilità API Redis e CQL sul livello di query.
VoltDB è un concorrente che rivendica la conformità ACID e mentre utilizza ancora SQL, i suoi obiettivi sono gli stessi in termini di scalabilità
Il nodo levelUP è transazionale e basato su leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB è un database NoSQL e ha transazioni ACID .
Non solo NoSQL non è conforme alla progettazione ACID. Il movimento NoSQL abbraccia la BASE (disponibile in pratica, stato morbido, eventuale consistenza) dichiarata contraria all'ACID. I database NoSQL sono spesso chiamati database a consistenza finale. Per capire le differenze dovresti approfondire il teorema della CAP (alias teorema di Brewer)
Visita http://www.julianbrowne.com/article/viewer/brewers-cap-theorem