¿En qué se diferencia NoSQL orientado a columnas del orientado a documentos?

90

Los tres tipos de bases de datos NoSQL sobre los que he leído es clave-valor, orientada a columnas y orientada a documentos.

El valor clave es bastante sencillo: una clave con un valor simple.

He visto bases de datos orientadas a documentos descritas como clave-valor, pero el valor puede ser una estructura, como un objeto JSON. Cada "documento" puede tener todas, algunas o ninguna de las mismas claves que otro.

La orientación a columnas parece ser muy similar a la orientación a documentos en el sentido de que no especifica una estructura.

Entonces, ¿cuál es la diferencia entre estos dos y por qué usarías uno sobre el otro?

He analizado específicamente MongoDB y Cassandra. Básicamente necesito una estructura dinámica que pueda cambiar, pero que no afecte a otros valores. Al mismo tiempo, necesito poder buscar / filtrar claves específicas y ejecutar informes. Con CAP, AP es lo más importante para mí. Los datos pueden "eventualmente" sincronizarse entre nodos, siempre y cuando no haya conflicto o pérdida de datos. Cada usuario obtendría su propia "tabla".

Luke
fuente

Respuestas:

41

En Cassandra, cada fila (dirigida por una clave) contiene una o más "columnas". Las columnas son en sí mismas pares clave-valor. Los nombres de las columnas no necesitan estar predefinidos, es decir, la estructura no es fija. Las columnas de una fila se almacenan en orden de acuerdo con sus claves (nombres).

En algunos casos, puede tener un gran número de columnas en una fila (por ejemplo, para actuar como un índice para habilitar tipos particulares de consulta). Cassandra puede manejar estructuras tan grandes de manera eficiente y usted puede recuperar rangos específicos de columnas.

Hay un nivel adicional de estructura (que no se usa tan comúnmente) llamado supercolumnas, donde una columna contiene (sub) columnas anidadas.

Puede pensar en la estructura general como una tabla hash / diccionario anidado, con 2 o 3 niveles de clave.

Familia de columnas normal:

row
    col  col  col ...
    val  val  val ...

Familia de súper columnas:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

También hay estructuras de nivel superior (familias de columnas y espacios de claves) que se pueden utilizar para dividir o agrupar sus datos.

Vea también esta pregunta: Cassandra: ¿Qué es una subcolumna?

O los enlaces de modelado de datos de http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: comparación con bases de datos orientadas a documentos: estas últimas suelen insertar documentos completos (normalmente JSON), mientras que en Cassandra puede abordar columnas individuales o supercolumnas y actualizarlas individualmente, es decir, funcionan en un nivel diferente de granularidad. Cada columna tiene su propia marca de tiempo / versión (que se usa para conciliar las actualizaciones en el clúster distribuido).

Los valores de la columna Cassandra son solo bytes, pero se pueden escribir como texto ASCII, UTF8, números, fechas, etc.

Por supuesto, podría usar Cassandra como un almacén de documentos primitivo insertando columnas que contienen JSON, pero no obtendría todas las características de una tienda orientada a documentos real.

ADN
fuente
5
Una familia de columnas es como una mesa. Una fila es como una fila de una tabla. Las columnas son una especie de columnas de base de datos, excepto que se pueden definir sobre la marcha, por lo que puede tener una tabla muy escasa en algunos casos, o puede tener diferentes columnas en cada fila.
ADN
1
Depende de la base de datos. En MongoDB (orientado a documentos) también puede actualizar cada clave.
David Raab
1
Si eso es cierto, ¿cómo se define MongoDB como una base de datos orientada a documentos mientras que Cassandra está orientada a columnas? ¿En qué se diferencian?
Lucas
3
@Luke El orientado a columnas se parece mucho a un RDBMS sin esquema, pero además de su estructura flexible, la principal diferencia es que no es relacional.
user327961
1
@ user327961 Pero MongoDB también es como un RDBMS sin esquema, y ​​tampoco es relacional.
huggie
55

La principal diferencia es que los almacenes de documentos (por ejemplo, MongoDB y CouchDB) permiten documentos arbitrariamente complejos, es decir, subdocumentos dentro de subdocumentos, listas con documentos, etc., mientras que los almacenes de columnas (por ejemplo, Cassandra y HBase) solo permiten un formato fijo, por ejemplo, estricto de un nivel o diccionarios de dos niveles.

Theo
fuente
En este caso, mongo (documento) puede hacer lo que cassendra (columna) puede. Entonces, ¿por qué se necesita Column?
sanjay patel
1
Es una compensación entre diferentes características, con un diseño orientado a columnas, el motor de almacenamiento puede ser mucho más eficiente que un motor de almacenamiento orientado a documentos. MongoDB tiene que reescribir todo el documento en el disco si crece, pero Cassandra no tiene que hacerlo (esto es una simplificación, por supuesto, hay muchos detalles en esto). Esto hace que Cassandra sea mucho más rápida cuando se trata de escribir.
Theo
29

En "insertar", para usar palabras rdbms, Document-based es más consistente y directo. Tenga en cuenta que cassandra le permite lograr coherencia con la noción de quórum, pero eso no se aplicará a todos los sistemas basados ​​en columnas y eso reduce la disponibilidad. En un sistema pesado de escritura única / lectura a menudo, elija MongoDB. También considérelo si siempre planea leer la estructura completa del objeto. Un sistema basado en documentos está diseñado para devolver el documento completo cuando lo recibe, y no es muy sólido para devolver partes de toda la fila.

Los sistemas basados ​​en columnas como Cassandra son mucho mejores que los basados ​​en documentos en "actualizaciones". Puede cambiar el valor de una columna sin siquiera leer la fila que la contiene. En realidad, la escritura no debe realizarse en el mismo servidor, una fila puede estar contenida en varios archivos de varios servidores. En un enorme sistema de datos de rápida evolución, elija Cassandra. También considérelo si planea tener una gran cantidad de datos por clave y no necesitará cargarlos todos en cada consulta. En "seleccionar", Cassandra le permite cargar solo la columna que necesita.

También considere que Mongo DB está escrito en C ++ y se encuentra en su segunda versión principal, mientras que Cassandra necesita ejecutarse en una JVM, y su primera versión principal está en versión candidata desde ayer (pero las versiones 0.X se convirtieron en producciones de empresa importante ya).

Por otro lado, el diseño de Cassandra se basó en parte en Amazon Dynamo, y está construido en su núcleo para ser una solución de alta disponibilidad, pero eso no tiene nada que ver con el formato basado en columnas. MongoDB también se escala, pero no con tanta gracia como Cassandra.

usuario327961
fuente
1
¿Qué hay de malo en que un software se escriba en C ++ en comparación con Java?
Nayuki
@Nayuki Ahora, soy consciente de que hay cargas de trabajo de alta contención donde la recolección de basura perezosa del modelo de administración de memoria de Java superará en teoría al modelo de administración "manual" de C ++, pero en términos generales, no es difícil superar a Java escribiendo un equivalente programa en C ++, al menos siempre que desactive Excepciones y RTTI. Y si hace un buen uso de las corrutinas sin pila y las funciones reanudables, bueno, personalmente no he visto a Java vencer a mi C ++ todavía.
patrickjp93
0

Diría que la principal diferencia es la forma en que cada uno de estos tipos de bases de datos almacena físicamente los datos.
Con los tipos de columna, los datos se almacenan en columnas que pueden permitir operaciones de agregación / consultas eficientes en una columna en particular.
Con los tipos de documentos, el documento completo se almacena lógicamente en un lugar y generalmente se recupera como un todo (no es posible una agregación eficiente en "columnas" / "campos").

El bit confuso es que una "fila" de columna ancha se puede representar fácilmente como un documento, pero, como se mencionó, se almacenan de manera diferente y se optimizan para diferentes propósitos.

Miguel
fuente