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

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".

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.

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.

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.

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.