Publicaré esto como una respuesta puramente para apoyar la conversación: Tim Mahy , nawroth y CraigTP han sugerido bases de datos viables. CouchDB sería mi preferido debido al uso de Erlang , pero hay otros por ahí.
Yo diría que ACID no contradice ni niega el concepto de NoSQL ... Si bien parece haber una tendencia siguiendo la opinión expresada por Dove , diría que los conceptos son distintos.
NoSQL es fundamentalmente sobre un simple valor de clave (por ejemplo, Redis) o un esquema de estilo de documento (pares de clave-valor recopilados en un modelo de "documento", por ejemplo, MongoDB) como una alternativa directa al esquema explícito en los RDBMS clásicos. Le permite al desarrollador tratar las cosas de forma asimétrica, mientras que los motores tradicionales han impuesto la misma rigidez en todo el modelo de datos. La razón por la que esto es tan interesante es porque proporciona una forma diferente de lidiar con el cambio , y para conjuntos de datos más grandes ofrece oportunidades interesantes para lidiar con los volúmenes y el rendimiento.
ACID proporciona principios que rigen cómo se aplican los cambios a una base de datos. De una manera muy simplificada, establece (mi propia versión):
(A) cuando hace algo para cambiar una base de datos, el cambio debería funcionar o fallar en su conjunto
(C) la base de datos debe permanecer consistente (este es un tema bastante amplio)
(I) si otras cosas están sucediendo al mismo tiempo, no deberían poder ver las cosas a mitad de la actualización
(D) si el sistema explota (hardware o software), la base de datos debe poder recuperarse; y si dice que terminó de aplicar una actualización, debe estar seguro
La conversación se vuelve un poco más emocionante cuando se trata de la idea de propagación y restricciones . Algunos motores RDBMS proporcionan la capacidad de imponer restricciones (por ejemplo, claves foráneas) que pueden tener elementos de propagación (a la cascada ). En términos más simples, una "cosa" puede tener una relación con otra "cosa" en la base de datos, y si cambia un atributo de uno puede requerir que se cambie el otro (actualizado, eliminado, ... muchas opciones). Las bases de datos NoSQL , al estar predominantemente (en este momento) enfocadas en grandes volúmenes de datos y alto tráfico, parecen estar abordando la idea de actualizaciones distribuidas que tienen lugar dentro de (desde la perspectiva del consumidor) marcos de tiempo arbitrarios. Esta es básicamente una forma especializada de replicación administrada a través detransacción - Entonces diría que si una base de datos distribuida tradicional puede soportar ACID, también puede hacerlo una base de datos NoSQL.
Buena respuesta. Puede tener NoSQL + ACID y no ACID-RDBMS (piense en MySQL + MyISAM). Me lo general considero NoSQL como "eventualmente consistentes". También
incluiré
+1 @gbn por la mención del teorema CAP. Estar más familiarizado con los db "nosql" ahora de lo que estaba entonces solo ha reforzado la separación de los conceptos. Además, las bases de datos clave-valor vs doc, ya que existen diferencias arquitectónicas.
ACTUALIZACIÓN (27 de julio de 2012): el enlace al artículo de Wikipedia se ha actualizado para reflejar la versión del artículo que estaba vigente cuando se publicó esta respuesta. ¡Tenga en cuenta que el artículo actual de Wikipedia ha sido ampliamente revisado!
NoSQL es un movimiento que promueve una clase poco definida de almacenes de datos no relacionales que rompen con una larga historia de bases de datos relacionales y garantías ACID.
y también:
El nombre era un intento de describir la aparición de un número creciente de almacenes de datos distribuidos no relacionales que a menudo no intentaban proporcionar garantías de ACID.
y
Los sistemas NoSQL a menudo brindan garantías de consistencia débil, como la consistencia eventual y las transacciones restringidas a elementos de datos individuales, a pesar de que uno puede imponer garantías ACID completas al agregar una capa de middleware complementaria.
En pocas palabras, diría que uno de los principales beneficios de un almacén de datos "NoSQL" es su distintivo falta de propiedades ACID . Además, en mi humilde opinión, cuanto más se intenta implementar y hacer cumplir las propiedades de ACID , más se aleja del "espíritu" de un almacén de datos "NoSQL", y más se acerca a un RDBMS "verdadero" (relativamente hablando, por supuesto )
Sin embargo, todo lo dicho, "NoSQL" es un término muy vago y está abierto a interpretaciones individuales, y depende en gran medida de cuánto punto de vista purista tenga. Por ejemplo, la mayoría de los sistemas RDBMS modernos no se adhieren a todos los de Edgar F. Codd 's 12 reglas de su modelo de relación !
Tomando un enfoque pragmático, parece que Apache CouchDB acerca más a encarnar tanto el cumplimiento de ACID mientras conserva la mentalidad de "NoSQL" no relacionalmente acoplada.
+1 No estoy seguro de estar de acuerdo con que la falta de ACID sea una característica clave de "NoSQL", pero realmente aprecio sus comentarios. En definitiva, debe tratarse de una solución que se ajuste.
AJ.
2
Edité (pendiente de revisión) para intentar aclarar aún más. No hay nada acerca de los modelos de datos NoSQL que impliquen que las transacciones ACID no sean posibles. Algunos sistemas distribuidos NoSQL no los tienen. Algunos realmente no tienen ninguna "capa de middleware".
Eric Bloch
2
Esto nunca fue correcto e incluso ha perdido su fuente. Realmente debería ser eliminado.
Lennart Regebro
2
Bueno, más descaradamente, esto: "en pocas palabras, diría que uno de los principales beneficios de un almacén de datos" NoSQL "es su clara falta de propiedades ACID". También implica que NoSQL y ACID de alguna manera son mutuamente excluyentes, lo que definitivamente es incorrecto. Este es un buen ejemplo de cuando un gran número de personas ignorantes votaron una respuesta incorrecta porque suena razonable. Que la mayoría de las bases de datos NoSQL no son compatibles con ACID se debe principalmente a que las personas que lo implementaron no sabían qué era / por qué era importante / no me importaba.
Lennart Regebro
@LennartRegebro - No implicaba tal cosa. El cumplimiento de ACID ha sido evitado por la mayoría de las bases de datos NoSQL actuales y existentes a favor de la velocidad / rendimiento y la consistencia eventual. Sin embargo, nunca dije que no se podía tener NoSQL con conformidad con ACID.
En primer lugar, podemos distinguir dos tipos de bases de datos NoSQL:
Bases de datos orientadas a los agregados;
Bases de datos orientadas a gráficos (por ejemplo, Neo4J).
Por diseño, ¡la mayoría de las bases de datos orientadas a gráficos son ACID !
Entonces, ¿qué pasa con los otros tipos?
En las bases de datos orientadas a los agregados, podemos poner tres subtipos:
Bases de datos NoSQL basadas en documentos (por ejemplo, MongoDB, CouchDB);
Clave / Valor Bases de datos NoSQL (por ejemplo, Redis);
Bases de datos de la familia de columnas NoSQL (por ejemplo, Hibase, Cassandra).
Lo que llamamos un Agregado aquí, es lo que Eric Evans definió en su Diseño Dirigido por Dominio como un Autosuficiente de Entidades y Objetos de Valor en un Contexto Limitado dado.
Como consecuencia, un agregado es una colección de datos con los que interactuamos como una unidad. Los agregados forman los límites para las operaciones ACID con la base de datos. (Martin Fowler)
Entonces, a nivel agregado, podemos decir que la mayoría de las bases de datos NoSQL pueden ser tan seguras como ACID RDBMS , con la configuración adecuada. De origen, si ajusta su servidor para la mejor velocidad, puede entrar en algo que no sea ACID. Pero la replicación ayudará.
Mi punto principal es que debe usar las bases de datos NoSQL tal como están, no como una alternativa (barata) a RDBMS. He visto demasiados proyectos abusando de las relaciones entre documentos. Esto no puede ser ACID. Si permanece en el nivel del documento, es decir, en los límites agregados, no necesita ninguna transacción. ¡Y sus datos estarán tan seguros como con una base de datos ACID, incluso si no es realmente ACID, ya que no necesita esas transacciones! Si necesita transacciones y actualiza varios "documentos" a la vez, ya no está en el mundo NoSQL, ¡así que use un motor RDBMS!
alguna actualización de 2019: a partir de la versión 4.0, para situaciones que requieren atomicidad para actualizaciones a múltiples documentos o consistencia entre lecturas a múltiples documentos, MongoDB proporciona transacciones de múltiples documentos para conjuntos de réplicas .
Hay casos en que hay un gran proceso / saga que maneja muchos agregados. Hay casos en que un comando enviado a un agregado puede desencadenar algunos eventos que cambian otros agregados. En estos casos, necesita almacenes de datos compatibles con ACID.
Tudor
1
@TudorTudor, pero en este caso está rompiendo uno de los principios de nosql, ya que lo está utilizando como rdbms. Solo necesita agregados más grandes o versiones de los documentos (como en couchdb). Los DB orientados a documentos Nosql son ácidos en los límites de documento / agregado.
Arnaud Bouchez
Ninguno de los que enumeras cumple con los ácidos. Mongo simplemente no es compatible con ACID. CouchDB pretende que es compatible con el ácido siempre que no esté actualizando dos documentos. Redis solo tiene "soporte parcial para transacciones". HBase es directamente no compatible con el ácido (de los desarrolladores) , ni Cassandra. Esta respuesta es, de hecho, simplemente incorrecta. Ninguna de estas bases de datos es compatible con ACID, y la mayoría de ellas lo poseen abiertamente con una simple búsqueda en Google.
Evan Carroll
@EvanCarroll Nunca escribí que MongoDB es compatible con ACID, en el mismo significado que con una transacción ACID RDBMS. No hay transacciones disponibles. Lo que escribí es que la mayoría de las bases de datos NoSQL pueden ser tan seguras como ACID RDBMS, con la configuración adecuada . Por ejemplo, compruebe el operador $ MongoDB aislado para una base de datos sin ningún clúster compartido. Nunca usaría MongoDB para el proceso financiero, pero podría confiar en su proceso de escritura hasta cierto punto, para operaciones similares a ACID, si la A para Atomicity es suficiente. Lo siento si mi respuesta es confusa.
Tiene transacciones adecuadas, por lo que puede actualizar varios elementos de datos dispares de forma ACID. Esto se utiliza como base para mantener los índices en una capa superior.
desafortunadamente no es de código abierto. Pero parece una muy buena base de datos.
Kevin Cox
Para agregar a la respuesta de @ Ken-Tindell, djondb también es NoSQL e implementa transacciones y es compatible con ACID. djondb.com Estoy de acuerdo en que NoSQL es solo un término para acuñar todas las bases de datos que no siguen las reglas tradicionales del RDBMS, no significa "deshacerse de los sistemas TX" u olvidarse de las relaciones.
Cross
3
Mi respuesta ha sido discutida por la adquisición de Foundation DB por parte de Apple.
Ken Tindell
1
foundationdb ahora es de código abierto por Apple
RBanerjee
17
En esta pregunta, alguien debe mencionar OrientDB : OrientDB es una base de datos NoSQL, una de las pocas, que admite transacciones totalmente ACID. ACID no es solo para RDBMS porque no es parte del álgebra relacional. Por lo tanto, es posible tener una base de datos NoSQL que admita ACID.
Esta característica es la que más extraño en MongoDB
ACID y NoSQL son completamente ortogonales. Uno no implica el otro.
Tengo un cuaderno en mi escritorio, lo uso para guardar notas sobre cosas que todavía tengo que hacer. Este cuaderno es una base de datos NoSQL. Lo consulto usando una búsqueda lineal con un "caché de página" para que no siempre tenga que buscar en cada página. También es compatible con ACID, ya que me aseguro de que solo escribo una cosa a la vez y nunca mientras la estoy leyendo.
NoSQL simplemente significa que no es SQL. Muchas personas se confunden y piensan que significa almacenamiento súper rápido altamente escalable-salvaje-oeste-oeste. No lo hace. No significa almacenamiento de valores clave o consistencia eventual. Todo lo que significa es "no SQL", hay muchas bases de datos en este planeta y la mayoría de ellas no son SQL [cita requerida] .
Puede encontrar muchos ejemplos en las otras respuestas, así que no necesito enumerarlos aquí, pero hay bases de datos que no son SQL con cumplimiento de ACID para varias operaciones, algunas son solo ACID para escrituras de un solo objeto, mientras que otras garantizan mucho más. Cada base de datos es diferente.
Solo para ser pedante, pero generalmente significa 'No solo SQL' :-)
shmish111
44
@ shmish111 no realmente. Significaba "No SQL" cuando se acuñó el término por primera vez. La "o" es pequeña, no capital después de todo. Posteriormente hubo intentos de recuperar el término como "No solo SQL" cuando algunos de estos (productos NoSQL) comenzaron a agregar interfaces de lenguaje de consulta similares a SQL.
ypercubeᵀᴹ
11
"NoSQL" no es un término bien definido. Es un concepto muy vago. Como tal, ni siquiera es posible decir qué es y qué no es un producto "NoSQL". No casi todos los productos de marca típica con la etiqueta son tiendas de valor clave.
La mejor respuesta. Cuando surge esta guerra de llamas, me gusta preguntarle a la otra parte qué características definitorias requieren explícitamente de una base de datos NoSQL y, a menudo, se superpone con las características que pueden encontrar en un RDBMS, no porque uno o RDBMS se ajusten al tema NoSQL sino simplemente porque su Los "requisitos" de las características son tan vagos que no se niegan por completo, características que se encuentran en (no necesariamente todos) los RDMBS. ¡+1 por tu comentario amigo!
StartupGuy
8
Sí, MarkLogic Server es una solución NoSQL (base de datos de documentos que me gusta llamar) que funciona con transacciones ACID
MarkLogic tiene transacciones ACID, transacciones de múltiples documentos, transacciones de múltiples estados de cuenta y soporte para XA, todo en todo el clúster / distribuido.
Para aquellos que buscan la transición de la biblioteca de "estanterías" de Python, descubrí que ZODB es casi inútil. No necesitaba volver a escribir todas mis funciones: solo tenía que acceder a ZODB como un diccionario como Shelve, pero es un orden de magnitud más rápido.
Michael Galaxy
8
Como uno de los creadores de NoSQL (fui uno de los primeros contribuyentes de Apache CouchDB, y orador en el primer evento NoSQL celebrado en CBS Interactive / CNET en 2009), estoy emocionado de ver que los nuevos algoritmos crean posibilidades que antes no existían. . El protocolo Calvin ofrece una nueva forma de pensar en restricciones físicas como CAP y PACELC .
En lugar de la replicación asíncrona activa / pasiva, o la replicación síncrona activa / activa, Calvin conserva la corrección y la disponibilidad durante las interrupciones de la réplica al usar un protocolo similar a RAFT para mantener un registro de transacciones. Además, las transacciones se procesan de manera determinista en cada réplica, eliminando la posibilidad de puntos muertos, por lo que el acuerdo se logra con una sola ronda de consenso. Esto lo hace rápido incluso en implementaciones de múltiples nubes en todo el mundo.
FaunaDB es la única implementación de la base de datos que utiliza el protocolo Calvin, por lo que es especialmente adecuada para cargas de trabajo que requieren integridad de datos de tipo mainframe con escala y flexibilidad NoSQL.
Si está buscando un almacén de clave / valor compatible con ACID, está Berkeley DB . Entre las bases de datos de gráficos, al menos Neo4j e HyperGraphDB ofrecen transacciones ACID (HyperGraphDB en realidad usa Berkeley DB para almacenamiento de bajo nivel en este momento).
[…] Una clase de sistemas modernos de gestión de bases de datos relacionales que buscan proporcionar el mismo rendimiento escalable de los sistemas NoSQL para cargas de trabajo de lectura-escritura de procesamiento de transacciones en línea (OLTP) mientras mantienen las garantías ACID de un sistema de base de datos tradicional.[1][2][3]
Sí, las transacciones ACID de varios documentos ahora son compatibles con MongoDB. Visite mongodb.com/transactions para obtener más información y videos de inmersión profunda sobre cómo se implementaron.
A diferencia de la persistencia o serialización de roll-your-own, db4o es seguro para transacciones ACID y permite consultas, replicación y cambios de esquema durante el tiempo de ejecución
Tarantool es una base de datos NoSQL completamente ácida. Puede emitir operaciones CRUD o procedimientos almacenados, todo se ejecutará con estricta conformidad con una propiedad ACID. También puede leer sobre eso aquí: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
¿Aerospike admite transacciones ACID de varias claves? AKAIK se limita a la transacción de una sola clave.
eonil
1
BergDB es una base de datos NoSQL ligera y de código abierto diseñada desde el principio para ejecutar transacciones ACID. En realidad, BergDB es "más" ACID que la mayoría de las bases de datos SQL en el sentido de que la única forma de cambiar el estado de la base de datos es ejecutar transacciones ACID con el nivel de aislamiento más alto (término SQL: "serializable"). Nunca habrá problemas con lecturas sucias, lecturas no repetibles o lecturas fantasmas.
En mi opinión, la base de datos sigue siendo altamente eficiente; pero no confíes en mí, creé el software. Pruébalo tú mismo en su lugar.
Muchas soluciones modernas de NoSQL no admiten transacciones ACID (actualizaciones atómicas aisladas de múltiples claves), pero la mayoría de ellas admiten primitivas que le permiten implementar transacciones en el nivel de la aplicación.
Si un almacén de datos admite la linealización por clave y compara y establece (atomicidad a nivel de documento), entonces es suficiente para implementar transacciones del lado del cliente, además tiene varias opciones para elegir:
Si necesita un nivel de aislamiento serializable, puede seguir el mismo algoritmo que Google utiliza para el sistema Percolator o Cockroach Labs para CockroachDB . He publicado un blog al respecto y creo una visualización paso a paso , espero que te ayude a comprender la idea principal detrás del algoritmo.
Si espera una alta contención pero está bien que tenga un nivel de aislamiento de lectura comprometida, eche un vistazo a las transacciones RAMP de Peter Bailis.
El tercer enfoque es utilizar transacciones compensatorias también conocidas como el patrón de saga. Fue descrito a finales de los 80 en el periódico Sagas , pero se hizo más actual con el aumento de los sistemas distribuidos. Consulte la charla Aplicación del patrón de la saga para obtener inspiración.
La lista de almacenes de datos adecuados para transacciones del lado del cliente incluye Cassandra con transacciones ligeras, Riak con cubos consistentes, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB y otros.
El creador de VoltDB mencionó que no se etiquetan a sí mismos como NoSql sino más bien como NewSql (todavía usan Sql pero con una mejor implementación que los RDBM construidos en los años ochenta)
Matt W
0
Si bien es solo un motor integrado y no un servidor, leveldb tiene WriteBatch y la capacidad de activar las Escrituras síncronas para proporcionar un comportamiento ACID.
No solo NoSQL no es compatible con ACID por diseño. El movimiento NoSQL abarca BASE (Básicamente disponible, estado blando, consistencia eventual) afirma ser lo contrario de ACID. La base de datos NoSQL a menudo se llama base de datos eventualmente consistente. Para comprender las diferencias, debe profundizar en el teorema CAP (también conocido como teorema de Brewer)
¡Creo que el puntero al teorema CAP es muy relevante para esta pregunta!
mxro
2
Algunas bases de datos NoSQL tienen transacciones ACID.
Eric Bloch
1
Algunos noSQL afirman ser compatibles con ACID, pero cuando profundiza en el interior, descubre que solo en algunos casos particulares son ACID, así que en mi humilde opinión, ya que no hay 'eventualmente ACID' definitivamente no son ACID
Ste
1
Básicamente estás aplicando incorrectamente CAP. CAP y ACID están poco relacionados en el mejor de los casos, pero CAP no impide que un sistema distribuido sea compatible con ACID. CAP describe las compensaciones necesarias de un sistema distribuido: un sistema NoSQL que es muy consistente puede no estar disponible durante una partición, pero eso no impide que sea compatible con ACID.
Respuestas:
Publicaré esto como una respuesta puramente para apoyar la conversación: Tim Mahy , nawroth y CraigTP han sugerido bases de datos viables. CouchDB sería mi preferido debido al uso de Erlang , pero hay otros por ahí.
Yo diría que ACID no contradice ni niega el concepto de NoSQL ... Si bien parece haber una tendencia siguiendo la opinión expresada por Dove , diría que los conceptos son distintos.
NoSQL es fundamentalmente sobre un simple valor de clave (por ejemplo, Redis) o un esquema de estilo de documento (pares de clave-valor recopilados en un modelo de "documento", por ejemplo, MongoDB) como una alternativa directa al esquema explícito en los RDBMS clásicos. Le permite al desarrollador tratar las cosas de forma asimétrica, mientras que los motores tradicionales han impuesto la misma rigidez en todo el modelo de datos. La razón por la que esto es tan interesante es porque proporciona una forma diferente de lidiar con el cambio , y para conjuntos de datos más grandes ofrece oportunidades interesantes para lidiar con los volúmenes y el rendimiento.
ACID proporciona principios que rigen cómo se aplican los cambios a una base de datos. De una manera muy simplificada, establece (mi propia versión):
La conversación se vuelve un poco más emocionante cuando se trata de la idea de propagación y restricciones . Algunos motores RDBMS proporcionan la capacidad de imponer restricciones (por ejemplo, claves foráneas) que pueden tener elementos de propagación (a la cascada ). En términos más simples, una "cosa" puede tener una relación con otra "cosa" en la base de datos, y si cambia un atributo de uno puede requerir que se cambie el otro (actualizado, eliminado, ... muchas opciones). Las bases de datos NoSQL , al estar predominantemente (en este momento) enfocadas en grandes volúmenes de datos y alto tráfico, parecen estar abordando la idea de actualizaciones distribuidas que tienen lugar dentro de (desde la perspectiva del consumidor) marcos de tiempo arbitrarios. Esta es básicamente una forma especializada de replicación administrada a través detransacción - Entonces diría que si una base de datos distribuida tradicional puede soportar ACID, también puede hacerlo una base de datos NoSQL.
Algunos recursos para leer más:
fuente
ACTUALIZACIÓN (27 de julio de 2012): el enlace al artículo de Wikipedia se ha actualizado para reflejar la versión del artículo que estaba vigente cuando se publicó esta respuesta. ¡Tenga en cuenta que el artículo actual de Wikipedia ha sido ampliamente revisado!
Bueno, según una versión anterior de un artículo de Wikipedia sobre NoSQL :
y también:
y
En pocas palabras, diría que uno de los principales beneficios de un almacén de datos "NoSQL" es su distintivo falta de propiedades ACID . Además, en mi humilde opinión, cuanto más se intenta implementar y hacer cumplir las propiedades de ACID , más se aleja del "espíritu" de un almacén de datos "NoSQL", y más se acerca a un RDBMS "verdadero" (relativamente hablando, por supuesto )
Sin embargo, todo lo dicho, "NoSQL" es un término muy vago y está abierto a interpretaciones individuales, y depende en gran medida de cuánto punto de vista purista tenga. Por ejemplo, la mayoría de los sistemas RDBMS modernos no se adhieren a todos los de Edgar F. Codd 's 12 reglas de su modelo de relación !
Tomando un enfoque pragmático, parece que Apache CouchDB acerca más a encarnar tanto el cumplimiento de ACID mientras conserva la mentalidad de "NoSQL" no relacionalmente acoplada.
fuente
Asegúrese de leer la introducción de Martin Fowler sobre las bases de datos NoSQL . Y el video correspondiente.
En primer lugar, podemos distinguir dos tipos de bases de datos NoSQL:
Por diseño, ¡la mayoría de las bases de datos orientadas a gráficos son ACID !
Entonces, ¿qué pasa con los otros tipos?
En las bases de datos orientadas a los agregados, podemos poner tres subtipos:
Lo que llamamos un Agregado aquí, es lo que Eric Evans definió en su Diseño Dirigido por Dominio como un Autosuficiente de Entidades y Objetos de Valor en un Contexto Limitado dado.
Entonces, a nivel agregado, podemos decir que la mayoría de las bases de datos NoSQL pueden ser tan seguras como ACID RDBMS , con la configuración adecuada. De origen, si ajusta su servidor para la mejor velocidad, puede entrar en algo que no sea ACID. Pero la replicación ayudará.
Mi punto principal es que debe usar las bases de datos NoSQL tal como están, no como una alternativa (barata) a RDBMS. He visto demasiados proyectos abusando de las relaciones entre documentos. Esto no puede ser ACID. Si permanece en el nivel del documento, es decir, en los límites agregados, no necesita ninguna transacción. ¡Y sus datos estarán tan seguros como con una base de datos ACID, incluso si no es realmente ACID, ya que no necesita esas transacciones! Si necesita transacciones y actualiza varios "documentos" a la vez, ya no está en el mundo NoSQL, ¡así que use un motor RDBMS!
alguna actualización de 2019: a partir de la versión 4.0, para situaciones que requieren atomicidad para actualizaciones a múltiples documentos o consistencia entre lecturas a múltiples documentos, MongoDB proporciona transacciones de múltiples documentos para conjuntos de réplicas .
fuente
FoundationDB cumple con ACID:
http://www.foundationdb.com/
Tiene transacciones adecuadas, por lo que puede actualizar varios elementos de datos dispares de forma ACID. Esto se utiliza como base para mantener los índices en una capa superior.
fuente
En esta pregunta, alguien debe mencionar OrientDB : OrientDB es una base de datos NoSQL, una de las pocas, que admite transacciones totalmente ACID. ACID no es solo para RDBMS porque no es parte del álgebra relacional. Por lo tanto, es posible tener una base de datos NoSQL que admita ACID.
Esta característica es la que más extraño en MongoDB
fuente
ACID y NoSQL son completamente ortogonales. Uno no implica el otro.
Tengo un cuaderno en mi escritorio, lo uso para guardar notas sobre cosas que todavía tengo que hacer. Este cuaderno es una base de datos NoSQL. Lo consulto usando una búsqueda lineal con un "caché de página" para que no siempre tenga que buscar en cada página. También es compatible con ACID, ya que me aseguro de que solo escribo una cosa a la vez y nunca mientras la estoy leyendo.
NoSQL simplemente significa que no es SQL. Muchas personas se confunden y piensan que significa almacenamiento súper rápido altamente escalable-salvaje-oeste-oeste. No lo hace. No significa almacenamiento de valores clave o consistencia eventual. Todo lo que significa es "no SQL", hay muchas bases de datos en este planeta y la mayoría de ellas no son SQL [cita requerida] .
Puede encontrar muchos ejemplos en las otras respuestas, así que no necesito enumerarlos aquí, pero hay bases de datos que no son SQL con cumplimiento de ACID para varias operaciones, algunas son solo ACID para escrituras de un solo objeto, mientras que otras garantizan mucho más. Cada base de datos es diferente.
fuente
"NoSQL" no es un término bien definido. Es un concepto muy vago. Como tal, ni siquiera es posible decir qué es y qué no es un producto "NoSQL". No casi todos los productos de marca típica con la etiqueta son tiendas de valor clave.
fuente
Sí, MarkLogic Server es una solución NoSQL (base de datos de documentos que me gusta llamar) que funciona con transacciones ACID
fuente
El abuelo de NoSQL: ZODB es compatible con ACID. http://www.zodb.org/
Sin embargo, es solo Python.
fuente
Como uno de los creadores de NoSQL (fui uno de los primeros contribuyentes de Apache CouchDB, y orador en el primer evento NoSQL celebrado en CBS Interactive / CNET en 2009), estoy emocionado de ver que los nuevos algoritmos crean posibilidades que antes no existían. . El protocolo Calvin ofrece una nueva forma de pensar en restricciones físicas como CAP y PACELC .
En lugar de la replicación asíncrona activa / pasiva, o la replicación síncrona activa / activa, Calvin conserva la corrección y la disponibilidad durante las interrupciones de la réplica al usar un protocolo similar a RAFT para mantener un registro de transacciones. Además, las transacciones se procesan de manera determinista en cada réplica, eliminando la posibilidad de puntos muertos, por lo que el acuerdo se logra con una sola ronda de consenso. Esto lo hace rápido incluso en implementaciones de múltiples nubes en todo el mundo.
FaunaDB es la única implementación de la base de datos que utiliza el protocolo Calvin, por lo que es especialmente adecuada para cargas de trabajo que requieren integridad de datos de tipo mainframe con escala y flexibilidad NoSQL.
fuente
Si está buscando un almacén de clave / valor compatible con ACID, está Berkeley DB . Entre las bases de datos de gráficos, al menos Neo4j e HyperGraphDB ofrecen transacciones ACID (HyperGraphDB en realidad usa Berkeley DB para almacenamiento de bajo nivel en este momento).
fuente
NewSQL
Este concepto que los colaboradores de Wikipedia definen como:
Referencias
[1]Nancy Lynch y Seth Gilbert, "Conjetura de Brewer y la viabilidad de servicios web consistentes, disponibles y tolerantes a la partición" , ACM SIGACT News, Volumen 33 Número 2 (2002), pág. 51-59.[2]"Brewer's CAP Theorem" , julianbrowne.com, consultado el 02-mar-2010[3]"Teorema de Brewers CAP en sistemas distribuidos" , royans.netfuente
MongoDB anunció que su versión 4.0 será compatible con ACID para transacciones de múltiples documentos.
Versión 4.2 se supone que es compatible con configuraciones fragmentadas.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
fuente
Se mencionó FoundationDB y en ese momento no era de código abierto. Ha sido abierto por Apple hace dos días: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Creo que es compatible con ACID.
fuente
eche un vistazo al teorema de CAP
EDITAR: RavenDB parece ser compatible con ACID
fuente
Para añadir a la lista de alternativas, otra base de datos NoSQL totalmente compatible con ACID es GT.M .
fuente
Hyperdex Warp http://hyperdex.org/warp/ Warp (característica ACID) es propietaria, pero Hyperdex es gratis.
fuente
db4o
http://www.db4o.com/about/productinformation/db4o/
fuente
Tarantool es una base de datos NoSQL completamente ácida. Puede emitir operaciones CRUD o procedimientos almacenados, todo se ejecutará con estricta conformidad con una propiedad ACID. También puede leer sobre eso aquí: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
fuente
MarkLogic también es compatible con ACID. Creo que es uno de los jugadores más importantes ahora.
fuente
La espera ha terminado.
NoSQL DB compatible con ACID está fuera ----------- eche un vistazo a citrusleaf
fuente
BergDB es una base de datos NoSQL ligera y de código abierto diseñada desde el principio para ejecutar transacciones ACID. En realidad, BergDB es "más" ACID que la mayoría de las bases de datos SQL en el sentido de que la única forma de cambiar el estado de la base de datos es ejecutar transacciones ACID con el nivel de aislamiento más alto (término SQL: "serializable"). Nunca habrá problemas con lecturas sucias, lecturas no repetibles o lecturas fantasmas.
En mi opinión, la base de datos sigue siendo altamente eficiente; pero no confíes en mí, creé el software. Pruébalo tú mismo en su lugar.
fuente
Muchas soluciones modernas de NoSQL no admiten transacciones ACID (actualizaciones atómicas aisladas de múltiples claves), pero la mayoría de ellas admiten primitivas que le permiten implementar transacciones en el nivel de la aplicación.
Si un almacén de datos admite la linealización por clave y compara y establece (atomicidad a nivel de documento), entonces es suficiente para implementar transacciones del lado del cliente, además tiene varias opciones para elegir:
Si necesita un nivel de aislamiento serializable, puede seguir el mismo algoritmo que Google utiliza para el sistema Percolator o Cockroach Labs para CockroachDB . He publicado un blog al respecto y creo una visualización paso a paso , espero que te ayude a comprender la idea principal detrás del algoritmo.
Si espera una alta contención pero está bien que tenga un nivel de aislamiento de lectura comprometida, eche un vistazo a las transacciones RAMP de Peter Bailis.
El tercer enfoque es utilizar transacciones compensatorias también conocidas como el patrón de saga. Fue descrito a finales de los 80 en el periódico Sagas , pero se hizo más actual con el aumento de los sistemas distribuidos. Consulte la charla Aplicación del patrón de la saga para obtener inspiración.
La lista de almacenes de datos adecuados para transacciones del lado del cliente incluye Cassandra con transacciones ligeras, Riak con cubos consistentes, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB y otros.
fuente
YugaByte DB admite txns distribuidos compatibles con ACID , así como compatibilidad con API Redis y CQL en la capa de consulta.
fuente
VoltDB es un participante que reclama el cumplimiento de ACID, y aunque todavía usa SQL, sus objetivos son los mismos en términos de escalabilidad
fuente
Si bien es solo un motor integrado y no un servidor, leveldb tiene WriteBatch y la capacidad de activar las Escrituras síncronas para proporcionar un comportamiento ACID.
fuente
El nivel de nodo UP es transaccional y se basa en leveldb https://github.com/rvagg/node-levelup#batch
fuente
Google Cloud Datastore es una base de datos NoSQL que admite transacciones ACID
fuente
DynamoDB es una base de datos NoSQL y tiene transacciones ACID .
fuente
No solo NoSQL no es compatible con ACID por diseño. El movimiento NoSQL abarca BASE (Básicamente disponible, estado blando, consistencia eventual) afirma ser lo contrario de ACID. La base de datos NoSQL a menudo se llama base de datos eventualmente consistente. Para comprender las diferencias, debe profundizar en el teorema CAP (también conocido como teorema de Brewer)
Visite http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
fuente