Base de

Datos III

Prof. Robert Espinoza Domínguez

Introducción a las Bases de Datos

NoSQL
Agenda

 Aparición de la tecnología NoSQL

 ¿Por qué los RDBMS no sirven?
 Bases de datos NoSQL
 Ranking de Gestores de Base de Datos
 NoSQL – Principios
 ¿Porque se necesita NoSQL?
 Características de NoSQL
 Modelos de consistencia: BASE
 Teorema CAP
 Clasificación de cada base de datos NoSQL según el
teorema CAP
Agenda

 Transacciones ACID
 Transacciones BASE
 ACID vs BASE
 Arquitectura Base de Datos NoSQL
 Aplicaciones NoSQL
 Taxonomía NoSQL
 Ventajas NoSQL
 Críticas a NoSQL
 Resumen
Aparición de la tecnología NoSQL
Aparición de la tecnología NoSQL

 Desde los años 80, la mayoría de los sistemas de

información almacenan sus datos en gestores
relacionales
 Aplicaciones de banca
 CRM (Costumer Relationship Management)
 ERP (Enterprise Resource Planning)
 Sistemas sanitarios
 Sistemas académicos
 Etc.
 Básicamente, estos recogen procesos operacionales
que gestionan datos simples y estructurados (p.ej.
transacciones bancarias, compras,…)
Aparición de la tecnología NoSQL

 Las BD relacionales (R-DBMS) se caracterizan por:

 Utilizar un modelo de datos simple (basado en tablas y
relaciones entre tablas)
 Ofrecer herramientas para garantizar la integridad de
datos y la consistencia de la información (ACID)
 Utilizar un lenguaje de interrogación estándar, simple y
potente
 Proporcionar utilidades para asegurar el acceso,
manipulación y la privacidad de los datos
 Ofrecer utilidades para la auditoría y recuperación de
datos
 Garantizar la independencia del esquema lógico y físico
 Llevan en el mercado más de 40 años
Aparición de la tecnología NoSQL

 Pero los servicios de redes sociales como Facebook,

Twitter o Ebay aparecieron; éstos necesitaban dar
servicio a miles de usuarios concurrentes y responder
millones de preguntas diarias y la tecnología relacional
no ofrecía ni el nivel de escalabilidad ni el rendimiento
adecuado.
 Paralelamente, los avances en virtualización
condujeron a la construcción de nodos de computación
en la nube (cloud computing), que a su vez requería
nodos de almacenamiento (cloud storage).
Aparición de la tecnología NoSQL

 Las aplicaciones web generan grandes volúmenes de

información:
 Datos a escala web con millones de transacciones.
 NoSQL mejor rendimiento de lecturas y escrituras en
sistemas de almacenamiento.
 Consultas que saturan el servidor de base de datos
relacional en segundos.
Aparición de la tecnología NoSQL

 Cambios de esquema de datos frecuentes.

 Aplicaciones sociales sin base de datos transaccional
eficiente.
 NoSQL tienen mejor nivel de disponibilidad y
escalabilidad.
 El gran crecimiento de volúmenes de datos requiere de
soluciones escalables.
Aparición de la tecnología NoSQL

Escalabilidad
 Propiedad deseable de un sistema, una red o un
proceso, que indica su habilidad para reaccionar y
adaptarse sin perder calidad.
 Se requiere de sistemas distribuidos (cluster).
Aparición de la tecnología NoSQL

Bases de Datos Distribuida

 Conjunto de múltiples bases de datos lógicamente
relacionadas, las cuales se encuentran distribuidas en
diferentes espacios lógicos y geográficos e
interconectados por una red de comunicaciones.
Aparición de la tecnología NoSQL

 IBM estima que en 2020 se generen 40 zetabytes de

datos frente a los 3,2 del 2015.
 El 95% de la información en internet es información
no estructurada.
 Aparición de la tecnología NoSQL

Entendiendo el término Big Data:

 Las 3 V’s (2013)
 Volume: gran cantidad de datos
 Velocity: necesidad de ser analizados rápidamente
 Variety: datos estructurados y no estructurados, densos y
dispersos, conectados y desconectados
 Ahora, 7 V’s (2016)
 Variability: datos cuyo significado cambia
constantemente
 Veracity: veracidad, precisión
 Visualisation: presentar los datos de forma comprensible
 Value: extraer información para la toma de decisiones
¿Por qué los RDBMS no sirven?

 Los RDBMS presentan varios cuellos de botella:

 Gestión de Log: Redo log, Undo log.
 Control de concurrencia.
 Protocolos de transacciones distribuidas.
 Administración de buffers.
 Interfaces CLI (JDBC, ODBC, etc.).
 No son adecuadas para información no estructurada
 SOLUCIÓN:
 Implementar modelos alternativos que se ajusten a lo que
realmente se necesita.
 Google, Facebook, Amazon diseñan su solución propia.
Bases de datos NoSQL

 NoSQL es un término utilizado para describir un

conjunto de bases de datos que se diferencian de las
bases de datos relacionales (RDBMS) en los
siguientes aspectos:
 Esquema prescindible, desnormalización, escalan
horizontalmente y en sus premisas no está garantizar
ACID
 El término fue acuñado por primera vez en 1998 por
Carlo Strozzi e instaurado en 2009 por Eric Evans
 Evans sugiere mejor referirse a esta familia de BD de
nueva generación como “Big Data” mientras que
Strozzi considera ahora que NoREL es un mejor
nombre.
Bases de datos NoSQL
 Ranking de Gestores de Base de Datos

Fuente: https://db-engines.com/en/ranking
NoSQL - Principios

 Tanto las bases de datos NoSQL como las relacionales

son tipos de Almacenamiento Estructurado.
 La principal diferencia radica en cómo guardan los
datos (p.ej., el almacenamiento de una factura):
 En RDBMS separaríamos la información en diferentes
tablas (cliente, factura, detalle_factura, etc.) y luego el
aplicativo, ejecutaría el JOIN y mapearía esta consulta
SQL para mostrárselo al usuario.
 En NoSQL, simplemente se guarda la factura como una
unidad, sin separar los datos.
NoSQL - Principios

 NoSQL no siempre es la mejor solución

 Si tus datos son relacionales, quedarte con tu RDBMS
sería la opción correcta.
 NoSQL se basa en los siguientes principios:
 El control transaccional ACID no es importante.
 Los JOINs tampoco lo son. En especial los complejos y
distribuidos. Se persigue la desnormalización.
 Algunos elementos relacionales son necesarios y
aconsejables: claves (keys).
 Gran capacidad de escalabilidad y de replicación en
múltiples servidores.
¿Porque se necesita NoSQL?

 Desafíos de gestión de información son difíciles de

resolver con tecnología de bases de datos
relacionales:
 Base de datos relacional a escala de tráfico con alto
costo en rendimiento, disponibilidad, etc.
 Crecimiento desproporcionado del tamaño del esquema
de base de datos.
 Base de datos ha sido desnormalizada por razones de
rendimiento o por conveniencia para utilizar los datos en
una aplicación.
 Se genera muchos datos temporales (carrito de compras,
personalización de portales).
¿Porque se necesita NoSQL?

 Dataset con gran cantidad texto e imágenes.

 Consultas contra datos que no implican relaciones
jerárquicas sencillas; recomendaciones o consultas de
inteligencia de negocios (BI).
 Se usa transacciones locales que no necesitan ser
durables.
 Características de NoSQL

NoSQL – "not only SQL” – es una categoría general de

sistemas de gestión de bases de datos que difiere de los
RDBMS en diferente modos:
 No tiene esquemas fijos.

 No se diseñan las tablas por adelantado.

 Permite migración de esquemas sin reiniciar/parar.
 No intenta garantizar transacciones (ACID)
 Eventualmente consistentes en un nodo del clúster.
Características de NoSQL

 Fáciles de usar en clúster de balanceo de carga.

 Facilitan escalabilidad horizontal.
 Guardan datos persistentes (no sólo cachés).
 No permite JOINs.
 Sistema de consulta propio en lugar de un lenguaje de
consulta estándar.
Modelos de consistencia: BASE

 Las RDBMS nos permiten definir la estructura de un

esquema que demanda reglas rígidas y garantizan ACID:
 Atomicity - todo o nada

 Consistency - coherencia de los datos

 Isolation - serialización de transacciones

 Durability - los cambios son permanentes

 Pero estas transacciones ACID son más estrictas que lo que

el dominio de la aplicación requiere en muchos casos.
 Por ello NoSQL debilita los requistios de: consistencia
inmediata, datos actuales y precisión de respuesta con
objeto de ganar escalabilidad  Teorema CAP .
 En vez de usar ACID, se utiliza el término BASE para
describir una estrategia de consistencia más optimista.
Teorema CAP

 Consistencia (Consistency)
 Availability (Disponibilidad)
 Partition Tolerance (Tolerancia a la partición)
Teorema de CAP

Consistencia de Base de Datos

 Toda transacción que se realice sobre la base de
datos, debe cambiar los datos de la base de datos en
estado consistente a otro estado consistente de la
base de datos.
 Al realizar una consulta o inserción siempre se tiene que
recibir la misma información, con independencia del nodo
o servidor que procese la petición.
Teorema de CAP

Disponibilidad de Base de Datos

 Asegurarse de que los datos de la base de datos estén
disponibles. Si se produce una anomalía, introducir
una base de datos con funciones que se adapten a las
necesidades de su organización.
 Que todos los clientes puedan leer y escribir, aunque se
haya caído uno de los nodos.
Teorema de CAP

Tolerancia a la Partición de Base de Datos

 Capacidad de la base de datos a seguir funcionando,
aún en caso de producirse algún fallo en la base de
datos. Observar que los fallos pueden ser no
intencionados o intencionados.
 Los sistemas distribuidos pueden estar divididos en
particiones (generalmente de forma geográfica). Así que
esta condición implica, que el sistema tiene que seguir
funcionando aunque existan fallos o caídas parciales que
dividan el sistema.
 Teorema de CAP

Teorema de Brewer
 Es imposible para un
sistema computacional
distribuido ofrecer
simultáneamente las
siguiente garantías:
 Consistencia.
 Disponibilidad.
 Tolerancia a la partición
Clasificación de cada base de datos
NoSQL según el teorema CAP
 Para ser escalables y distribuidas, las bases de datos
NoSQL, siguen distintos métodos, por lo que no todas
cumplen los mismos puntos del teorema CAP.
 AP: garantizan disponibilidad y tolerancia a particiones,
pero no la consistencia, al menos de forma total. Algunas
de ellas consiguen una consistencia parcial a través de la
replicación y la verificación.
 CP: garantizan consistencia y tolerancia a particiones.
Para lograr la consistencia y replicar los datos a través
de los nodos, sacrifican la disponibilidad.
 CA: garantizan consistencia y disponibilidad, pero tienen
problemas con la tolerancia a particiones. Este problema
lo suelen gestionar replicando los datos.
 Clasificación de cada base de datos
NoSQL según el teorema de CAP
 Hay que tener en cuenta, que esta clasificación no es
definitiva, ya que algunos de estos sistemas NoSQL
pueden configurarse para cambiar su comportamiento.
Transacciones ACID
Transacciones BASE

 Basically Available (disponibilidad como prioridad)

 Está operativo la mayoría del tiempo ante fallos gracias al
almacenamiento distribuido y replicado para asegurar la
disponibilidad de la base de datos.
 Soft state (consistencia delegada)
 Los datos en las diferentes réplicas no tienen que ser
mutuamente consistentes en todo momento. La
consistencia se delega a la gestión externa al motor de
base de datos.
 Eventually Consistent (consistencia eventual)
 Se asegura la consistencia solo después de que pase
cierto tiempo.
Transacciones BASE

 En resumen:
 Consistencia débil – datos obsoletos OK
 Prima la disponibilidad
 Respuestas aproximadas OK
 Agresivamente optimista, disponibilidad aunque fallen
nodos
ACID vs BASE

 En el mundo relacional estamos familiarizados con las

transacciones ACID, que garantizan la consistencia y
estabilidad de las operaciones pero requieren bloqueos
sofisticados:
 Las base de datos NoSQL son repositorios de
almacenamiento más optimistas, siguen el modelo
BASE.
 BASE es una alternativa flexible a ACID para aquellos
almacenes de datos que no requieren un adherencia
estricta a las transacciones
 ACID vs BASE:
http://queue.acm.org/detail.cfm?id=1394128
Arquitectura Base de Datos NoSQL

 En general, proveen consistencia débil (weak consistency),

como p.ej. consistencia eventual, o transacciones
restringidas a elementos de datos simples.
 Emplean una arquitectura distribuida (distributed
architecture), donde los datos están almacenados de forma
redundante en varios servidores. A menudo utilizan tablas
hash distribuidas.
 Generalmente ofrecen estructuras de datos simples (simple
data structures) como arrays asociativos o estructuras clave-
valor.
 Las consultas se realizan exclusivamente por key o índice.
 Las consultas complejas se realizan mediante una
infraestructura de procesamiento externo tal como
MapReduce.
Aplicaciones NoSQL

 Aplicaciones más complejas, los desarrolladores

deben ser conscientes del comportamiento de las
transacciones BASE que soporta la tecnología elegida.
 Deben elegir para cada caso, si aceptan datos
inconsistentes o si se configurará el repositorio de
datos con consistencia en tiempo de lectura, aunque
esto suponga un retraso en la respuesta (esto es,
verificar que en todas las réplicas se tiene el mismo
dato o repararlo si no es así).
Aplicaciones NoSQL

 Su uso es adecuado para aquéllas que:

 Manejan volúmenes ingentes de datos
 Tienen una frecuencia alta de accesos de lectura y
escritura
 Con cambios frecuentes en los esquemas de datos
 Y que no requieren consistencia ACID
 Casos de aplicación:
 Servicios Web2.0 (redes sociales, blogs, etc.)
 Aplicaciones IoT (internet de las cosas)
 Almacenamiento de perfiles sociales
 Juegos sociales
 Gestión de contenidos
Taxonomía NoSQL
Taxonomía NoSQL

 Los principales tipos de almacenamiento de NoSQL

son:
 Base de Datos Clave-Valor.
 Base de Datos Documentos.
 Base de Datos Familia de Columnas.
 Base de Datos en Grafo.
 Otros tipos:
 Base de Datos Multivalor.
 Base de Datos Orientada a Objetos.
 Base de Datos tabular.
 Base de Datos de arrays.
Ventajas de NoSQL

 Evitar la complejidad innecesaria, (transacciones

BASE)
 Alto rendimiento, centrado en la disponibilidad.
 Empleo de hardware más económico.
 Realizar sharding (partición de la base de datos) en
soluciones de cluster de RDBMS.
 NoSQL almacena la información de modos más
flexibles, sin un formato predefinido.
 Es sencillo distribuir los datos entre sistemas sin
mecanismo complejos de migración.
 Esto beneficia la escalabilidad horizontal, añadiendo
nodos para distribuir la carga.
Ventajas de NoSQL

 El pensamiento “One-size-fits-all” (mismo tamaño para

todos) estaba y sigue estando equivocado.
 Enormes islas de datos sin relación entre ellas.
 Valor de las transacciones de usuario muy bajo.
 La integridad de los datos no es crítica.
 Particionar y distribuir un modelo de datos
centralizado es caro y difícil.
 Aplicar sharding (fragmentación)
 Sistemas de administración diseñados para la
fragmentación.
Críticas a NoSQL

 Cada gestor NoSQL posee propia interfaz no

estándar
 No existe un líder claro.
 Escalabilidad no tan simple.
 Reestructuración de modelos desarrollo de
aplicaciones.
 Se simplifica el teorema CAP y se elige 2 de 3.
 Modelos de datos sin esquema de datos, mala
decisión de diseño.
 NoSQL requiere los mejores especialistas.
Resumen

 En NoSQL, los datos se recuperan, en general, de

forma más rápida que en RDBMS, sin embargo las
consultas que se puede realizar son más limitadas. La
complejidad se traslada a la aplicación.
 Si tu aplicación requiere soporte transaccional, debes
usar un RDBMS.
 NoSQL no es adecuado para aplicaciones que
generen informes con consultas complejas (necesidad
de JOINs), aunque tienen buena conexión con
entornos como MapReduce, que permite paralelizar
operaciones complejas como agregaciones, filtros, etc.
 La tendencia actual es hacia la combinación de
sistemas SQL y NoSQL