¿Existe algún almacén de datos NoSQL 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:
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 :
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.
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.
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 .
FoundationDB cumple con ACID:
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.
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.
"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.
Sí, MarkLogic Server es una solución NoSQL (base de datos de documentos que me gusta llamar) que funciona con transacciones ACID
El abuelo de NoSQL: ZODB es compatible con ACID. http://www.zodb.org/
Sin embargo, es solo Python.
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).
Este concepto que los colaboradores de Wikipedia definen como:
[…] 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]
[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.net
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
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.
Para añadir a la lista de alternativas, otra base de datos NoSQL totalmente compatible con ACID es GT.M .
Hyperdex Warp http://hyperdex.org/warp/ Warp (característica ACID) es propietaria, pero Hyperdex es gratis.
db4o
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
MarkLogic también es compatible con ACID. Creo que es uno de los jugadores más importantes ahora.
La espera ha terminado.
NoSQL DB compatible con ACID está fuera ----------- eche un vistazo a citrusleaf
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.
YugaByte DB admite txns distribuidos compatibles con ACID , así como compatibilidad con API Redis y CQL en la capa de consulta.
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
El nivel de nodo UP es transaccional y se basa en leveldb https://github.com/rvagg/node-levelup#batch
DynamoDB es una base de datos NoSQL y tiene transacciones 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)
Visite http://www.julianbrowne.com/article/viewer/brewers-cap-theorem