Respuestas:
Un almacén de clave-valor proporciona el modelo de datos más simple posible y es exactamente lo que sugiere el nombre: es un sistema de almacenamiento que almacena valores indexados por una clave. Está limitado a consultar por clave y los valores son opacos , la tienda no sabe nada sobre ellos. Esto permite operaciones de lectura y escritura muy rápidas (un simple acceso al disco) y veo este modelo como una especie de caché no volátil (es decir, muy adecuado si necesita accesos rápidos por clave a datos de larga duración).
Una base de datos orientada a documentos amplía el modelo anterior y los valores se almacenan en un formato estructurado (un documento, de ahí el nombre) que la base de datos puede comprender. Por ejemplo, un documento podría ser una publicación de blog y los comentarios y las etiquetas almacenados de forma desnormalizada. Dado que los datos son transparentes , la tienda puede hacer más trabajo (como indexar campos del documento) y no está limitado a realizar consultas por clave. Como indiqué, tales bases de datos permiten obtener los datos de una página completa con una sola consulta y son muy adecuadas para aplicaciones orientadas al contenido (razón por la cual a grandes sitios como Facebook o Amazon les gustan).
Otros tipos de bases de datos NoSQL incluyen almacenes orientados a columnas , bases de datos de gráficos e incluso bases de datos de objetos . Pero esto va más allá de la cuestión.
Bueno, yo mismo estuve investigando NoSQL durante el último mes. Creo que en general se podría decir algo como
Una base de datos orientada a documentos, o almacén de documentos, es para almacenar, recuperar y administrar información orientada a documentos, que son datos semiestructurados. El almacén de valores clave es una herencia de la base de datos orientada a documentos. La diferencia radica en la forma en que se procesan los datos; en un almacén de valores clave, los datos se consideran intrínsecamente opacos a la base de datos, mientras que un sistema orientado a documentos se basa en la estructura interna del documento para extraer metadatos que el motor de la base de datos utiliza para una mayor optimización.
Si nos ocupamos de la diferencia entre MOngoDb y Cassandra. MongoDB actúa como una base de datos relacional. Su modelo de datos consiste en una base de datos en el nivel superior, luego colecciones que son como tablas en MySQL (por ejemplo) y luego documentos que están contenidos dentro de la colección, como filas en MySQL. Cada documento tiene un campo y un valor que es similar a las columnas y valores en MySQL. Los campos pueden ser clave / valor simple, por ejemplo, {'nombre': 'David Mytton'} pero también pueden contener otros documentos, por ejemplo, {'nombre': {'primero': David, 'último': 'Mytton'}}. En Cassandra, los documentos se conocen como "columnas", que en realidad son solo una clave y un valor. por ejemplo, {'clave': 'nombre', 'valor': 'David Mytton'}. También hay un campo de marca de tiempo que es para la replicación y consistencia internas. El valor puede ser un valor único pero también puede contener otra "columna". Estas columnas luego existen dentro de familias de columnas que ordenan los datos en función de un valor específico en las columnas, referenciado por una clave.
Pero, en el nivel superior hay un espacio de claves, que es similar a la base de datos MongoDB.