mongodb - relacional - caracteristicas base de datos columnar
¿Cómo se diferencia el NoSQL orientado a columnas del orientado a documentos? (3)
Los tres tipos de bases de datos NoSQL sobre las que he leído son clave-valor, orientadas a columnas y orientadas a documentos.
La clave-valor es bastante directa: 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 otra.
Columna orientada parece ser muy similar al documento orientado en el sentido de que no se especifica una estructura.
Entonces, ¿cuál es la diferencia entre estos dos y por qué usarías uno sobre el otro?
Miré específicamente a MongoDB y a 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 que no haya conflicto o pérdida de datos. Cada usuario obtendría su propia "mesa".
En "insertar", para usar palabras rdbms, basado en documentos es más consistente y directo. Tenga en cuenta que cassandra le permite lograr consistencia con la noción de quórum, pero eso no se aplicará a todos los sistemas basados en columnas y eso reducirá la disponibilidad. En un sistema de escritura una vez / lectura a menudo pesado, vaya a MongoDB. También considérelo si siempre planea leer toda la estructura del objeto. Un sistema basado en documentos está diseñado para devolver el documento completo cuando lo obtiene, 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. La escritura no necesita hacerse en el mismo servidor, una fila puede estar contenida en múltiples archivos de múltiples servidores. En el enorme sistema de datos en rápida evolución, ve a Cassandra. También considérelo si planea tener una gran cantidad de datos por clave, y no tendrá que cargarlos todos en cada consulta. En "seleccionar", Cassandra te permite cargar solo la columna que necesitas.
También tenga en cuenta que Mongo DB está escrito en C ++, y está en su segunda versión principal, mientras que Cassandra necesita ejecutarse en una JVM, y su primera versión principal está en lanzamiento de versión desde ayer (pero las versiones de 0.X se convirtieron en producciones de gran compañía 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 escala también, pero no tan elegantemente como Cassandra.
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 columna no necesitan estar predefinidos, es decir, la estructura no es fija. Las columnas en una fila se almacenan en orden de acuerdo a 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 permitir determinados tipos de consulta). Cassandra puede manejar estructuras tan grandes de manera eficiente, y puede recuperar rangos específicos de columnas.
Existe otro nivel de estructura (no tan común) llamado supercolumnas, donde una columna contiene (sub) columnas anidadas.
Puede pensar en la estructura general como hashtable / dictionary anidado, con 2 o 3 niveles de clave.
Familia de columna normal:
row
col col col ...
val val val ...
Familia de Super Columna:
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 usar para dividir o agrupar sus datos.
Ver 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 - este último generalmente inserta documentos enteros (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 (se usa para conciliar actualizaciones en el clúster distribuido).
Los valores de la columna de Cassandra son solo bytes, pero pueden escribirse como texto ASCII, UTF8, números, fechas, etc.
Por supuesto, podría usar Cassandra como una tienda de documentos primitiva al insertar columnas que contengan JSON, pero no obtendrá todas las características de una tienda real orientada a documentos.
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.