Aunque esta es una pregunta de años ...
En resumen, puede entender ACID como garantía de integridad / seguridad de los datos en cualquier circunstancia esperada . Al igual que en la programación genérica, todos los dolores de cabeza provienen de subprocesos múltiples.
El mayor problema en NoSQL es principalmente ACI. D (urabilidad) suele ser un problema separado.
Si su base de datos es de un solo subproceso, por lo que solo un usuario puede acceder a la vez, eso es nativamente compatible con ACI. Pero estoy seguro de que prácticamente ningún servidor puede tener este lujo.
Si su base de datos necesita ser multiproceso (servir a múltiples usuarios / clientes simultáneamente), debe necesitar una transacción compatible con ACI. O obtendrá corrupción de datos silenciosa en lugar de una simple pérdida de datos. Lo cual es mucho más horrible. Simplemente, esto es exactamente lo mismo con la programación genérica de subprocesos múltiples. Si no tiene un mecanismo adecuado como el bloqueo, obtendrá datos indefinidos. Y el mecanismo en DB llamó el cumplimiento total de ACID .
Muchas bases de datos YesSQL / NoSQL se anuncian a sí mismas compatibles con ACID, pero en realidad, muy pocas de ellas lo hacen.
Sin cumplimiento de ACID = Obtendrá resultados siempre indefinidos en un entorno multiusuario (cliente). Ni siquiera pienso qué tipo de DB hace esto.
Fila única / clave compatible con ACID = Obtendrá un resultado garantizado si modifica solo un valor a la vez. Pero resultado indefinido (= corrupción de datos silenciosa) para la actualización simultánea de múltiples filas / claves. La mayoría de las bases de datos NoSQL actualmente populares, incluidas Cassandra, MongoDB, CouchDB, ... Este tipo de bases de datos son seguras solo para transacciones de una sola fila. Por lo tanto, debe garantizar que su lógica de base de datos no toque varias filas en una transacción.
Cumplimiento de ACID de múltiples filas / claves = Siempre obtendrá resultados garantizados para cualquier operación. Estos son requisitos mínimos como un RDBMS. En el campo NoSQL, muy pocos de ellos hacen esto. Llave inglesa, MarkLogic, VoltDB, FoundationDB. Ni siquiera estoy seguro de que haya más soluciones. Este tipo de bases de datos son realmente nuevas y frescas, por lo que no se sabe nada sobre su capacidad o limitación.
De todos modos, esta es una comparación, excepto D (urabilidad). Así que no olvides comprobar también el atributo de durabilidad. Es muy difícil comparar la durabilidad porque el rango se vuelve demasiado amplio. No conozco bien este tema ...
Sin durabilidad. Perderá datos en cualquier momento.
Almacenado de forma segura en el disco. Cuando llegue COMMIT OK, los datos están garantizados en el disco. Perdió datos si se rompe el disco.
Además, hay diferencias incluso en las bases de datos compatibles con ACID.
A veces cumple con ACID / necesita configuración / no hay algo automático .. / algunos componentes no cumplen con ACID / muy rápido pero necesita apagar algo para esto ... / Cumple con ACID si usa un módulo específico ... = nosotros no agrupará la seguridad de los datos por defecto. Es un complemento, una opción o una venta por separado. No olvide descargar, ensamblar, configurar y emitir el comando adecuado. De todos modos, la seguridad de los datos puede ignorarse en silencio. Hazlo tu mismo. Compruébalo tú mismo. Buena suerte para no cometer ningún error. Todos en su equipo deben ser DBA perfectos para usar este tipo de DB de manera segura. MySQL
Siempre compatible con ACID = No intercambiamos seguridad de datos con rendimiento ni nada. La seguridad de los datos es un paquete forzado con este paquete de base de datos. La mayoría de los RDBMS comerciales, PostgreSQL.
Arriba está la implementación típica de DB. Pero aún así, cualquier otra falla de hardware puede dañar la base de datos. Como error de memoria, error de canal de datos o cualquier otro error posible. Por lo tanto, necesita redundancia adicional, y la DB de calidad de producción real debe ofrecer características de tolerancia a fallas.
Sin redundancia Pierdes todos los datos si tus datos están dañados.
Apoyo. Realiza una copia instantánea / restauración. Pierde datos después de la última copia de seguridad.
Copia de seguridad en línea. Puede hacer una copia de seguridad de la instantánea mientras se ejecuta la base de datos.
Replicación asincrónica. Copia de seguridad por cada segundo (o período especificado). Si la máquina está apagada, esta base de datos garantiza recuperar los datos simplemente reiniciando. Pierdes datos después del último segundo.
Replicación sincrónica. Copia de seguridad inmediata para cada actualización de datos. Siempre tiene una copia exacta de los datos originales. Use la copia si el origen se rompe.
Hasta ahora, veo que muchas implementaciones de bases de datos carecen de muchas de estas. Y creo que si carecen de ACID y soporte de redundancia adecuados, los usuarios eventualmente perderán datos.