5.1 Conceptos y tipos de bases de datos NoSQL (documental, columnar, clave/valor y de grafos)

NoSQL - “Not Only SQL” - es una nueva categoría de bases de datos no-relacionales y altamente distribuidas.

Las bases de datos NoSQL nacen de la necesidad de:

Simplicidad en los diseños
Escalado horizontal
Mayor control en la disponibilidad

Pero cuidado, en muchos escenarios las BBDD relacionales siguen siendo la mejor opción.

5.1.1 Características de las bases de datos NoSQL

Libre de esquemas – no se diseñan las tablas y relaciones por adelantado, además de permitir la migración del esquema.
Proporcionan replicación a través de escalado horizontal.
Este escalado horizontal se traduce en arquitectura distribuida
Generalmente ofrecen consistencia débil
Hacen uso de estructuras de datos sencillas, normalmente pares clave/valor a bajo nivel
Suelen tener un sistema de consultas propio (o SQL-like)
Siguen el modelo BASE (Basic Availability, Soft state, Eventual consistency) en lugar de ACID (Atomicity, Consistency, Isolation, Durability)

El modelo BASE consiste en:

Basic Availability – el sistema garantiza disponibilidad, en términos del teorema CAP.
Soft state – el estado del sistema puede cambiar a lo largo del tiempo, incluso sin entrada. Esto es provocado por el modelo de consistencia eventual.
Eventual consistency – el sistema alcanzará un estado consistente con el tiempo, siempre y cuando no reciba entrada durante ese tiempo.

5.1.1.1 Teorema CAP

Es imposible para un sistema de cómputo distribuido garantizar simultáneamente:

Consistency – Todos los nodos ven los mismos datos al mismo tiempo
Availability – Toda petición obtiene una respuesta en caso tanto de éxito como fallo
Partition Tolerance – El sistema seguirá funcionando ante pérdidas arbitrarias de información o fallos parciales

Las razones para escoger NoSQL son:

Analítica
Gran cantidad de escrituras, análisis en bloque
Escalabilidad
Tan fácil como añadir un nuevo nodo a la red, bajo coste.
Redundancia
Están diseñadas teniendo en cuenta la redundancia
Rápido desarrollo
Al ser schema-less o schema on-read son más flexibles que schema on-write
Flexibilidad en el almacenamiento de datos
Almacenan todo tipo de datos: texto, imágenes, BLOBs
Gran rendimiento en consultas sobre datos que no implican relaciones jerárquicas
Gran rendimiento sobre BBDD desnormalizadas
Tamaño
El tamaño del esquema de datos es demasiado grande
Muchos datos temporales fuera de almacén principal

Razones para NO escoger NoSQL: * Consistencia y Disponibilidad de los datos son críticas * Relaciones entre datos son importantes + E.g. joins numerosos y/o importantes * En general, cuando el modelo ACID encaja mejor