De acuerdo con Wikipedia NoSQL article, hay muchas implementaciones de NoSQL.Qué almacenamiento NoSQL para elegir
¿Cuál es la diferencia entre almacenes orientados a documentos y valores clave (como las personas los mencionan con más frecuencia)?
Aquí hay una publicación de blog que escribí, Visual Guide to NoSQL Systems, que ilustra las principales diferencias entre algunos de los sistemas más populares. La mayor diferencia entre ellos es cuál de los dos siguientes eligen optimizar para: consistencia, disponibilidad y tolerancia de partición.
La idea de que puede elegir dos es engañosa: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html – TTT
En un documento de nivel y clave/valor son bastante similares: ambos devolverán un objeto cuando solicite una clave. En clave/valor puro ese objeto será una cadena simple, aunque puede ser un objeto complejo serializado. Una base de datos de documentos amplía esto con funciones para trabajar con este objeto, como la funcionalidad de actualización parcial o la indexación de búsqueda.
Más allá de eso, tendrá que pensar en sus requisitos específicos: NOSQL abarca una gran cantidad de sistemas diferentes y, a diferencia de las bases de datos SQL, todos tienen ventajas/desventajas bastante diferentes para un escenario específico.
En mi opinión, realmente no veo cómo Cassandra no es consistente. No puede hacer actualizaciones consistentes, pero nunca he trabajado con un modelo de base de datos donde las actualizaciones son un requisito, a diferencia de las actualizaciones con versiones consistentes (a veces llamadas actualizaciones versionadas incluso si no son realmente actualizaciones.
También Cassandra puede ser completamente ACID si hace que su modelo de datos sea ACID. En lugar de usar la transacción de base de datos, realice una transacción de la misma forma que los bancos. La transacción no es un cambio de datos mulit sino un objeto de datos real
Cuenta bancaria no tiene dinero en ellos. Tienen transacciones y el estado actual de sus cuentas se calcula a partir de las transacciones. Estas transacciones no son una característica de la base de datos, sino una parte del modelo de datos. No necesitan estar instantáneamente disponibles para todos los nodos para ser consistentes, porque ellos son yo mmutable.
No he encontrado un caso donde hacer que los datos sean inmutables no resuelve el problema de coherencia. Esto combinado con hacer que las transacciones formen parte del modelo de datos como datos inmutables (una vez que se lee una gran cantidad) se cumplen los requisitos de ACID.
Atomic: una transacción como un objeto/fila inmutable exclusivo se convierte en atómico sin ningún objeto de base de datos complejo para admitirlo.
Consistencia: una operación o transacción de base de datos se puede diseñar en el modelo de datos para que sea coherente. Todo lo que se necesita es realmente que sea inmutable (nunca se modificó después de la creación)
Aislamiento - Una transacción que hace es que su propio objeto de datos no debe interferir con otros y, por lo tanto, está aislado.
Durabilidad: si se pierde una transacción de datos inmutables, es equivalente a restaurar la base de datos a su estado anterior. Si los datos no se pierden, entonces está en su estado posterior a la transacción. En cualquier caso, cumple con los requisitos de durabilidad de ACID.
Es cierto que no se pueden lograr varias cosas en el modelo de datos "bancario". La información de su cuenta no puede tener una fila ACID con una cantidad fija de dinero. Si bien las transacciones en sí mismas son ACID, eso no significa que los datos que dependen de ellas puedan serlo. Esto se debe a que es posible que todas las transacciones aún no sean visibles desde todos los nodos. Incluso pueden estar en otra base de datos de bancos.Por lo tanto, el saldo de su cuenta no puede lograr la coherencia de ACID, pero no hay ninguna razón para que tenga dicho requisito, siempre y cuando todos los datos importantes tengan consistencia ACID, lo que hace.
Utilicé la base de datos del banco como ejemplo porque a menudo se usa como ejemplo sobre cómo hacer transacciones SQL con retrotracción en el saldo de la cuenta, algo que NUNCA sucede en implementaciones reales ... porque las transacciones bancarias deben soportar multinivel asincrónico. transacciones de base de datos, o en otras palabras, transacciones entre bancos.
También puede relacionar esto con un sistema de archivos. Cassandra (por ejemplo) puede darle una vista consistente de una instantánea inmutable de un archivo. No se garantiza que tenga una vista de la última instantánea, pero una instantánea. Con esto lo hace tan consistente como CVS/SVN o CODA.
En su mayoría depende de sus necesidades. – Htbaa
Esta es una pregunta acerca de NoSQL en absoluto, no relacionada con las necesidades de alguien. –
bien, dependiendo de su situación, la mejor opción cambiará porque no tienen todas las mismas características. ¿Necesitas una solución altamente escalable? o es solo una pequeña tienda? ¿Necesitas realizar búsquedas? o simplemente buscar por llaves? ¿Es principalmente leído? ¿Escribir? ¿Ambos? el rendimiento difiere de uno a otro. Por lo tanto, la pregunta que le pide que precise sus requisitos –