Cuanto más leo sobre NoSQL, más me empieza a parecer una base de datos orientada a columnas.¿Cuál es la diferencia entre NoSQL y una base de datos orientada a columnas?
¿Cuál es la diferencia entre NoSQL (por ejemplo, CouchDB, Cassandra, MongoDB) y una base de datos orientada a columnas (por ejemplo, Vertica, MonetDB)?
Algunas bases de datos NoSQL son bases de datos orientadas a columnas, y algunas bases de datos SQL también están orientadas a columnas. Si la base de datos está orientada a columna o fila es un detalle de implementación de almacenamiento físico de la base de datos y puede ser cierto tanto para bases de datos relacionales como no relacionales (NoSQL).
Vertica, por ejemplo, es una base de datos relacional orientada a columnas por lo que en realidad no calificaría como un datastore NoSQL.
Un datastore de "movimiento NoSQL" se define mejor como una base de datos no relacional, compartida, nada, horizontalmente escalable sin (necesariamente) garantías ACID. Algunas bases de datos orientadas a columnas se pueden caracterizar de esta manera. Además de las tiendas de columnas, las implementaciones de NoSQL también incluyen tiendas de documentos, almacenes de objetos, tiendas de tuplas y almacenes de gráficos.
Como escribió @tuinstoel, la article responde a su pregunta en el punto 3:
3. Interfaz. El grupo A se distingue por ser parte del movimiento NoSQL y normalmente no tiene tiene una interfaz SQL tradicional. El grupo B admite interfaces estándar de SQL .
Una base de datos NoSQL es un paradigma diferente de las bases de datos basadas en esquemas tradicionales. Están diseñados para escalar y almacenar documentos como datos json. Obviamente tienen una forma de consultar información, pero debe esperar una sintaxis como eval ("persona = * y edad> 10) para recuperar datos. Incluso si son compatibles con la interfaz SQL estándar, están destinados a otra cosa, por lo tanto, si le gusta SQL debe atenerse a las bases de datos tradicionales
Una base de datos orientada a columnas es diferente de las bases de datos orientadas a filas tradicionales debido a cómo almacenan datos. Al almacenar una columna completa en lugar de una fila, puede minimizar el acceso al disco al seleccionar un pocas columnas de una fila que contiene muchas columnas. En las bases de datos orientadas a filas no hay diferencia si selecciona solo uno o todos los campos de una fila.
Sin embargo, debe pagar una inserción más cara. Insertar una nueva fila causará muchas operaciones de disco, dependiendo de la cantidad de columnas
Pero no hay diferencia con las bases de datos tradicionales en términos de SQL, ACID, claves externas y cosas por el estilo.
Sugiero leer el taxonomy section de la entrada de wikipedia NoSQL para obtener una idea de cuán diferentes son las bases de datos NoSQL de una base de datos tradicional orientada a esquemas. Estar orientado a columnas implica filas y columnas, lo que implica un esquema (bidimensional), mientras que las bases de datos NoSQL tienden a ser sin esquema (almacenes clave-valor) o tienen contenidos estructurados pero sin un esquema formal (almacenes de documentos).
Para almacenes de documentos, la estructura y el contenido de cada "documento" son independientes de otros documentos en la misma "colección". Agregar un campo suele ser un cambio de código en lugar de un cambio de base de datos: los documentos nuevos obtienen una entrada para el nuevo campo, mientras que los documentos más antiguos se consideran que tienen un valor nulo para el campo inexistente.Del mismo modo, "eliminar" un campo podría significar que simplemente deja de consultarlo en su código en lugar de tomarse la molestia de eliminarlo de cada documento (a menos que el espacio sea un bien escaso, y luego tiene la opción de eliminar solo aquellos con los contenidos más grandes). Compare esto con la forma en que se debe cambiar una tabla completa para agregar o eliminar una columna en una base de datos tradicional de filas/columnas.
Los documentos también pueden contener listas y otros documentos anidados. He aquí un documento de muestra de MongoDB (un post de un blog u otro foro), representado como JSON:
{
_id : ObjectId("4e77bb3b8a3e000000004f7a"),
when : Date("2011-09-19T02:10:11.3Z"),
author : "alex",
title : "No Free Lunch",
text : "This is the text of the post. It could be very long.",
tags : [ "business", "ramblings" ],
votes : 5,
voters : [ "jane", "joe", "spencer", "phyllis", "li" ],
comments : [
{ who : "jane", when : Date("2011-09-19T04:00:10.112Z"),
comment : "I agree." },
{ who : "meghan", when : Date("2011-09-20T14:36:06.958Z"),
comment : "You must be joking. etc etc ..." }
]
}
Nota cómo "comentarios" es una lista de documentos anidados con su propia estructura independiente. Las consultas pueden "acceder" a estos documentos desde el documento externo, por ejemplo, para buscar publicaciones que tienen comentarios de Jane o publicaciones con comentarios de un cierto rango de fechas.
En resumen, dos de las principales diferencias típicas de las bases de datos NoSQL son la falta de un esquema (formal) y los contenidos que van más allá de la orientación bidimensional de una base de datos de fila/columna tradicional.
Así es como lo veo: Las bases de datos orientadas a columnas se ocupan de la manera en que los datos se almacenan físicamente en el disco. Como su nombre lo sugiere, cada columna se almacena en su propio espacio/archivo. Esto permite 2 cosas importantes:
NoSQL por el contrario son una nueva generación de bases de datos que definen los niveles agregados "lógicos" para explicar los datos. Algunos consideran que los datos tienen una relación jerárquica (agregando que es un "nodo"), mientras que otros tratan los datos como documentos (que es el nivel agregado). No dictan la estrategia de almacenamiento físico (algunos pueden hacer, pero abstraídos del usuario final).
Además, todo el movimiento NoSQL tiene más que ver con datos no estructurados, o más bien conjuntos de datos cuyo esquema no puede ser predefinido o desconocido de antemano, y por lo tanto no puede ajustarse al modelo relacional estricto.
bases de datos orientada a la columna todavía se ocupan de datos relacionales, a pesar de eliminar la necesidad de índice etc.
Distinguishing between coloumn stores Leer este blog. Esto responde tu pregunta.
NoSQL es término usado para No sólo SQL, que cubre cuatro categorías principales - valor-clave, Documento, familia de columnas y bases de datos del gráfico.
Las bases de datos de valor-clave son ideales para aplicaciones que tienen lecturas y escrituras pequeñas frecuentes junto con modelos de datos simples. Estos registros se almacenan y recuperan utilizando una clave que identifica de manera única el registro, y se utiliza para encontrar rápidamente los datos dentro de la base de datos.
e.g. Redis, Riak, etc.
bases de datos de documentos tienen capacidad de almacenar atributos que varían junto con grandes cantidades de datos
por ejemplo MongoDB, CouchDB etc.
familia Columna bases de datos están diseñados para grandes volúmenes de datos, leer y escribir el rendimiento y alta disponibilidad
por ejemplo, Cassandra, etc. HBase
La base de datos Graph es una base de datos que usa estructuras de gráficos para consultas semánticas con nodos, bordes y propiedades para representar y almacenar datos
por ejemplo Neo4j, etc. InfiniteGraph
Antes de entender NoSQL, usted tiene que entender algunos conceptos clave.
Coherencia - Todos los servidores del sistema tendrán los mismos datos, de modo que cualquier persona que use el sistema obtendrá la misma copia independientemente de qué servidor responda a su solicitud.
Disponibilidad - El sistema siempre responderá a una solicitud (incluso si no se trata de los datos más recientes o consistentes en todo el sistema o simplemente un mensaje que dice que el sistema no funciona).
Tolerancia de partición - El sistema continúa funcionando como un todo, incluso si los servidores individuales fallan o no pueden ser alcanzados.
La mayoría de las veces, solo dos de las tres propiedades estarán satisfechas con las bases de datos NoSQL.
Desde su pregunta,
CouchDB: AP (disponibilidad & partición) de base de datos & Documento
Cassandra: AP (disponibilidad & partición) de base de datos de la familia & Columna
MongoDB: CP (Coherencia & partición) de base de datos & Documento
Vertica: CA (Coherencia & disponibilidad) base de datos de la familia & Columna
MonetDB: ACID (atomicidad consistencia aislamiento Durabilidad) & Base de datos relacional
Desde: http://blog.nahurst.com/visual-guide-to-nosql-systems
Tener un vistazo a este article1, article2 y ppt para varios escenarios para seleccionar un determinado tipo de base de datos.
Distingue dos tipos de almacenes de columnas: http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html – tuinstoel
Es estructurado (columnar) vs No estructurado/Semi-estructurado (nosql). Piénsalo así. –