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 ([Link].
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: [Link]
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 ([Link]., 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:
[Link]
Arquitectura Base de Datos NoSQL
En general, proveen consistencia débil (weak consistency),
como [Link]. 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