Evaluación

Calificación
Niveles de calificación Descripción
Juicio de aprobación
Alcanzado de manera
5 Aprobado, no requiere tutoría
sobresaliente
Aprobado, pero requiere esfuerzo
4 Alcanzado de manera notable
del estudiante
Parcialmente superado, pero con Aprobado, requiere esfuerzo del
3
evidencias estudiante y tutoría
Reprobado, requiere un alto
No alcanzado / no demostrado
2 esfuerzo del estudiante y tutoría
por evidencias
intensiva
 Contenido
semana 1
Tema 1. Introducción a Base
de Datos NoSQL
1. Definición y características de
bases de datos NoSQL
1.1 Estado del arte
1.1.1 Big data
1.1.2 Sistemas tradicionales de
almacenamiento de datos
a. Base de datos relacionales
b. Base de datos NoSQL
La 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
La 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!!!

 La aparición de la
tecnología NoSQL
• Pero… los servicios de redes
sociales como Facebook, Twitter o
Ebay aparecieron; estos 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
 Cambio en la arquitectura
de las aplicaciones
Aplicación Aplicació
1990’s: Aplicación n
Integración de
bases de datos

BD
2010’s: Nube

Aplicaciones en la nube

Almacenamiento Cómputo Red

Virtualización - Servicios en la nube

Cambio en los requisitos de las
aplicaciones
BD relacional
Relational database
Datos
Requirement
Requisitos deofla aplicación
transaccionales
R application

e
n Aplicaciones
d Web
i
m Servicios de redes
i sociales
e
n
Servicios
t geoposicionados
o

Complejidad de los datos

 El término Big Data
•Entendiendo el término BIG DATA: las 3 V’s (2013)
• Volume: gran cantidad de datos
• Velocity: necesidad de ser analizados rápidamente
• Variety: datosestructurados 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
 Big data y su
importancia
en el mundo
digital
Definiciones adicionales de
Big data…
Microsoft: “Big Data es un término cada vez más
utilizado para describir el proceso de aplicación de alta
potencia de cómputo, machine learning y de inteligencia
artificial a información masiva y a menudo de gran
complejidad.”, (Microsoft, 2012)”.

Mayer-Schönberger & Cuckier: “Big Data se

refiere a nuestra capacidad creciente hacer
cálculos a vastas colecciones de información,
analizarla instantáneamente y sacar conclusiones
profundas de ellas.”, (Viktor Mayer-Schönberger,
2013).
IBM: “Big Data está siendo generado por todo lo que
nos rodea en cada momento. Cada proceso digital e
intercambio de medios sociales lo produce. Sistemas,
sensores y dispositivos móviles lo transmiten. Big Data
está llegando desde múltiples fuentes a una velocidad
alarmante, volumen y variedad.”, (IBM, 2014).
 Big data : El cuarto
paradigma Científico…
• Chen y Chun-Yang (2014) plantean que el
fenómeno Big Data, que da lugar a la Ciencia
de Datos, se presenta como un cuarto
paradigma científico debido a los cambios que
las crecientes aplicaciones intensivas en datos
están provocando en la ciencia. Los otros tres
paradigmas habrían sido la Ciencia Empírica
(explicación de la naturaleza basada en
experiencia empírica), Ciencia Teórica (Leyes
de Newton y Kepler) y la Ciencia
Computacional (simulación científica).

• En términos más generales, la realidad no se

explica por sí sola y por lo tanto un empirismo
radical no es sostenible ya que forma parte de
un sistema. De esta manera, un dato ya es una
 Análisis de
Big data: Un
esquema
conceptual
Big data:
60
Segundos
en
internet…
 Estado de la adopción de Big
data por industria-Caso España
 ¿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.).
• SOLUCIÓN:
• Implementar modelos alternativos que se
ajusten a lo que realmente se necesita.
• Google, Facebook, Amazon diseñan su
solución propia.
 • NoSQL – es un término utilizado para
describir un conjunto de bases de datos que
se diferencian de las bases de datos
El término relacionales (RDBMS) en los siguientes
aspectos:
NoSQL • Esquema prescindible,
desnormalización, escalan
horizontalmente y en sus premisas no
está garantizar ACID
• El término fue acuñado por primera vez
 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, líneas_factura,…) 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
 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 4 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.
NoSQL:
arquitectura
• En general, proven 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
 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 require 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.
 El teorema CAP
• Teorema de Brewer: “es imposible para un sistema
computacional distribuido ofrecer simultáneamente las
siguientes tres garantías”:

• Consistencia (Consistency)– todos los nodos vean los

mismos datos al mismo tiempo
• Disponibilidad (Availability) – garantizar que los
clientes encuentran una copia de los datos solicitados,
aunque haya nodos caídos en el clúster.
• Tolerancia a la partición (Partition) – el sistema
continúa funcionando a pesar de la pérdida de
mensajes o fallos parciales del sistema.

• Equivalente a:
“You can have it good,
you can have it fast,
 NoSQL: Modelos
de consistencia

• Basically Available, está operativo la mayoría del

tiempo
• Soft state, los datos en las diferentes réplicas
no tienen que ser mutuamente consistentes en
todo momento.
• Eventually Consistent, se asegura la consistencia
solo después de que pase cierto tiempo.
• En resumen:
• Consistencia débil – datos obsoletos OK
• Prima la disponibilidad
• Respuestas aproximadas OK
• Agresivamente optimista, disponibilidad,
aunque fallen nodos
• ACID vs BASE:
http://queue.acm.org/detail.cfm?id=1394128
 NoSQL:
aplicaciones
Deben elegir para cada caso, si aceptan datos inconsistentes o
si se configurá 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í).
NoSQL:
aplicaciones

• 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
 NoSQL: taxonomía

DynomiteDB

Voldemo
rt

© Ian Robinson et al.

(2015)
 BD clave-valor:
•Los datoscaracterísticas
se almacenan basados en una
única clave (key), en un hash-map
•El valor asociado con la key es opaco, un
blob (El valor almacenado junto con la
clave se describe como un "blob", lo que
significa que el sistema no interpreta ni
procesa este valor)
•Alto rendimiento para operaciones CRUD
básicas pero bajo para atender consultas
complejas o manejar datos
interconectados
•Operaciones atómicas a nivel de key
 BD clave-valor: casos
de uso
•Adecuada para:
•Información de sesión en aplicaciones web
•Perfiles y preferencias de usuario
•Carritos de la compra

•No aptas para aplicaciones que requieren

•Datos interconectados (servicios de redes
sociales, recomendadores,…)
•Consistencia para un conjunto de keys
•Búsquedas por la información almacenada en
 BD documental:
características
•Datos almacenados como documentos
•Documentos contienen su propio
metadatos
•Similares a las clave-valor pero lo
almacenado en valor es visible y se
puede consultar
•Esquema flexible
•Operaciones atómicas a nivel de
documento
BD documental: casos
de
•Adecuada para:
uso
•Blogs
•Event logging
•Datos operacionales y meta datos para
aplicaciones web y móviles

•No aptas para aplicaciones que requieren

•Consistencia para un conjunto de
documentos
•O si sus datos son densos, entonces
encajan mejor en un modelo relacional
 Familia de columnas:
características
•Los datos se almacenan en familias de
columnas; cada fila tiene una key y una o
varias columnas. Las columnas no tienen
que ser las mismas en cada fila.
•Estructura: Mapa multidimensional
•Operaciones atómicas a nivel de fila (row)
 Familia de columnas: casos de
uso
• Adecuada para:
• Blogs
• Event logging
• Contadores
• Tiempo de validez por columna (TTL, Time-To-Live). El TTL
permite que los datos asociados a una clave se eliminen
automáticamente después de un período de tiempo
determinado

• No aptas para aplicaciones que requieren

• Transacciones ACID para operaciones de lectura/escritura
 BD grafos:
características
• Los datos se almacenan como nodos (vértices) y
enlaces (links – relationships)
• Están orientadas a analizar las relaciones (caminos
mínimos, adyacencias, medidas de centralidad,…) y no
a computar agregaciones
• No se recomienda sharding ya que atravesar grafos en
distintas máquinas es difícil y costoso.
• Escalabilidad vertical
• ACID, similar a las BD relacionales
 BD grafos: casos
de uso
•Adecuada para:
•Almacenar datos conectados
•Aplicaciones espaciales o de rutas
•Motores de recomendación

•No aptas para aplicaciones que requieren

•Actualizaciones frecuentes de todos o un
subconjunto de propiedades de nodos y
enlaces
•Requisitos de escalabilidad horizontal
 NoSQL:
resumiendo - 29
-

• 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 require 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..
Gracias por su atención!!!