Este documento describe las bases de datos NoSQL y su aplicación en entornos de Big Data. Introduce conceptos clave como las bases de datos relacionales tradicionales y sus limitaciones para datos masivos y no estructurados. Explica que las bases de datos NoSQL ofrecen mayor escalabilidad y flexibilidad para almacenar y procesar diferentes tipos de datos.

1. Bases de datos NoSQL en
entornos Big Data
M4 - Tecnologías de Big Data
Emilio Rodríguez / erodriguez@smartup.es / @emirodgar

2. Índice
1- Conociendo las bases de datos
2- Metodología de diseño de base de datos
3- Bases de datos relacionales
4- Bases de datos NoSQL
5- Concepto NewSQL
6- Recursos y lecturas

3. 1 - Conociendo las bases de datos
1.1 - ¿Qué son las bases de datos?
1.2 - Características
1.3 - Ventajas
1.4 - Posibles problemas

4. ¿Qué son las bases de datos?
BD: Una base de datos es un conjunto de
datos pertenecientes a un mismo contexto.
¿Una carpeta de mi ordenador con varios documentos se considera una
base de datos?

5. ¿Qué son los sistemas gestores de bases de datos?
SGBD: Sistema Gestor de Bases de Datos
(DBMS - Data Base Management System)
Es el conjunto de programas que nos permite interactuar con la base de
datos.

6. Ejemplo para aclarar conceptos
SGBD - explorer.exe
(Software para gestionar los datos)
Base de datos - BD
(conjunto de datos)

7. Características de una sistema gestor de bases de datos
Las características principales de un SGBD son:
- Almacenar gran cantidad de información
- Fácil organización de la información
- Recuperación de forma rápida y flexible

8. Ventajas de los SGBD
Ventajas que aportan los SGBD:
- Independencia de los datos con los programas y procesos. Esto permite modificar los
datos sin tener que modificar el código de las aplicaciones.
- Mayor seguridad. Tanto en el acceso como en en los backups.
- Acceso eficiente a los datos. Más fácil, cómodo y rápido al estar bien organizados.
- Ayudan a mantener una baja redundancia en los datos. Solo los buenos diseños de BD
tienen poca redundancia lo cual también implica menor espacio de almacenamiento.

9. Problemas al diseñar y trabajar con BD
Posibles problemas al diseñar y trabajar con BD:
- Bases de datos inadecuadas o ineficientes.
- El mantenimiento es difícil/costoso.
- La documentación es limitada.
- Datos redundantes o inconsistentes.

10. 2 - Metodología de diseño de bases de datos
2.1 - Diseño conceptual
2.2 - Diseño lógico
2.3 - Diseño físico

11. Aclarando conceptos sobre los modelos de datos
Los modelos de datos
nos ayudan a reproducir una realidad que
deseamos almacenar
en un sistema informático.

12. Metodología de diseño de bases de datos (relacional)
Diseño conceptual
Este diseño es independiente
del tipo/modelo de la base de
datos.
Describen la realidad basada
en conceptos y sus
relaciones.
Diseño lógico
En esta fase se ha concretado
el SGBD y se aplican los
procesos de normalización.
Describe las operaciones en
detalle.
Diseño físico
Se crea el soporte físico
concreto.

13. Metodología de diseño de bases de datos
Modelo de datos
conceptual
basado en un
análisis de los
requisitos
Diseño conceptual
Este diseño es independiente
del tipo/modelo de la base de
datos.
Describen la realidad basada
en conceptos y sus
relaciones.
Diseño lógico
En esta fase se ha concretado
el SGBD y se aplican los
procesos de normalización.
Describe las operaciones en
detalle.
Diseño físico
Se crea el soporte físico
concreto.
Lógica del negocio

14. Aclarando conceptos sobre los modelos de datos
El Modelo CONCEPTUAL es una descripción teórica de los datos
y sus relaciones. Representamos una realidad.
● Su descripción debe ser rigurosa.
● Debe recoger toda la funcionalidad que queremos representar.
● Aislar la representación de requisitos de usuarios o empresa.
● Independiente de cualquier SGBD.

15. Diseño conceptual: modelo entidad - relación
El modelo entidad - relación (ER) es el más
utilizado para el diseño conceptual de
bases de datos.
Se compone de tres elementos:
● Entidades
● Atributos
● Relaciones entre entidades

16. Cliente
Pedidorealiza
contiene
nombre
dirección
teléfono
fecha
importe
impuestos
(1,N)
(N,M)
Producto
nombre
precio
cantidad
Ejemplo de modelo entidad - relación
Aunque cambie el modelo físico de la BD, el modelo conceptual no se verá afectado.
Conocer más sobre el modelo entidad - relación y sus diferentes notaciones.
Entidad
Atributos
Relaciones

17. Diseño conceptual: modelo entidad - relación
Diferentes notaciones para expresar la
cardinalidad

18. Metodología de diseño de bases de datos
Diseño conceptual
Este diseño es independiente
del tipo/modelo de la base de
datos.
Describen la realidad basada
en conceptos y sus
relaciones.
Modelo de
datos lógico
y esquema
de la BD
Diseño lógico
En esta fase se ha concretado
el SGBD y se aplican los
procesos de normalización.
Describe las operaciones en
detalle, tablas y claves.
Diseño físico
Se crea el soporte físico
concreto.
Lógica del negocio Modelo de datos
conceptual
basado en un
análisis de los
requisitos

19. Aclarando conceptos sobre los modelos de datos
El Modelo LÓGICO representa el conjunto de componentes del
SGBD para estructurar y manipular los datos:
● Estructuras de datos para definir y construir la BD.
● Operaciones para manipular y consultar datos.
● Mecanismos para aplicar restricciones de integridad (claves
primarias y ajenas/secundarias/foráneas).

20. En el diseño lógico convertimos el modelo conceptual
(hemos usado entidad/relación) a un modelo lógico.
El modelo lógico más utilizado es el modelo relacional
(estrella o copo de nieve).
Cada relación del modelo de datos será una tabla cuyos campos (columnas)
serán los atributos. Otros modelos lógicos son Codasyl y Jerárquico.
Diseño lógico: modelo relacional

21. [Análisis]: Diseño en estrella: una sola tabla de hechos
relacionada con múltiples tablas de dimensiones (un nivel).
● Ideal para el análisis pero ocupa más espacio (redundancia en los contenidos).
[Almacenamiento]: Diseño en copo de nieve: múltiples relaciones
entre las tablas (varios niveles).
● No hay redundancia de datos (normalizado) pero ofrece peor rendimiento en análisis.
Diseño lógico: tipos de diseños del modelo relacional

22. Pedido
idPedido
idCliente
idProducto
fecha
importe
impuestos
...
Cliente
idCliente
nombre
dirección
teléfono
...
Producto
idProducto
cantidad
nombre
precio
...
Clave primaria
Clave ajena
Clave ajena
Clave primaria Clave primaria
Tabla de hechos DimensiónDimensión
Diseño lógico: creación de un modelo relacional
¿Vemos algo raro en este modelo?
Si cada pedido puede contener varios productos, el modelo no se adapta a dicha premisa. Necesitamos
otra tabla intermedia entre pedido y producto (ProductosPedido). Diseño en copo de nieve ya que tiene
varios niveles (no todo depende de la tabla de hechos).
ProductosPedido
idPedido
idProducto
cantidad
precio

23. Normalización de modelo de datos
Consiste en aplicar un conjunto de normas para asociar atributos a
entidades con el objetivo de prevenir anomalías.
● Se evita la duplicidad de datos
● Se garantiza la integridad referencial (datos incoherentes)
● Se evita la pérdida de información
Diseño lógico: normalización de un modelo de datos

24. Esquema de base de datos relacional
Relación (claves)
Tipo de datos
Estructura (tablas)

25. Los diseños pueden llegar a ser complejos

26. MySQL Workbench para facilitar el diseño de BD relacionales

27. Metodología de diseño de bases de datos
Modelo de datos
conceptual
Diseño conceptual
Este diseño es independiente
del tipo/modelo de la base de
datos.
Describen la realidad basada
en conceptos y sus
relaciones.
Modelo de datos
asociado al SGBD
Diseño lógico
En esta fase se ha concretado
el SGBD y se aplican los
procesos de normalización.
Describe las operaciones en
detalle.
Diseño físico
Se crea el soporte físico
concreto.
Lógica del negocio
Modelo ER Modelo Relacional BD Relacional

28. 3 - Bases de datos relacionales
3.1 - ¿Qué son las bases de datos relacionales?
3.2 - Lenguaje SQL
3.3 - Limitaciones

29. Una base de datos relacional es un tipo de base de datos
que cumple con el modelo relacional.
● Se compone de varias tablas y relaciones.
● Cada tabla dispone de varios campos (columnas) y registros (filas).
● Las tablas se relacionan a través de claves (primarias y foráneas/ajenas).
● Trabaja con datos estructurados.
● Garantizan integridad de los datos.
Base de datos relacional

30. El lenguaje principal de una base de datos
relacional es SQL (Structured Query Language).
Ofrece funcionalidades para:
● Definir (DDL - alteramos estructuras de las tablas)
● Manipular (DML - trabajamos con los datos)
● Controlar (DCL - acceso a los datos).
SQL: lenguaje para consultas en la base de datos

31. A la hora de manipular los datos, SQL nos permite leer, insertar,
modificar y eliminar registros. El SGBD (relacional) garantiza la
integridad de los datos tras cada acción.
También permite realizar transacciones
(soporta las propiedades ACID).
SQL: lenguaje para consultas en la base de datos

32. ACID
Atomicity, Consistency, Isolation and Durability
Atomicidad, Consistencia, Aislamiento y Durabilidad

33. ● Atomicidad: o se ejecuta todo o no se ejecuta nada.
● Consistencia: mantiene la coherencia de los datos (solo se
ejecuta lo que garantiza integridad referencial).
● Aislamiento: las transacciones no se solapan entre sí. Cada
una es independiente del resto.
● Durabilidad: su ejecución persiste en el tiempo aunque falle
el sistema (se almacena y se recupera).

34. Transacción en base de datos relacional (ACID)
Lectura
Escritura 1
Escritura 2
Lectura
Escritura 1
Escritura 2
Cancelar
Inicio Inicio
guardar guardar

35. Realidad actual
Una base de datos relacional normalizada asegura ACID y nos
ayuda a solventar un problema tecnológico el 99% de las veces.
Cuando trabajamos con grandes cantidades de datos, la
escalabilidad y la velocidad se resienten y no ofrecen resultados
óptimos. También presentan dificultades con datos no
estructurados.
O es muy caro o se rompe el esquema relacional.

36. El 80 % de la información relevante
para un negocio se origina en
forma no estructurada.

37. Tipos de datos
● Estructurados: Siguen una estructura fija, de tipo conocido y
pueden ser ordenados y procesados fácilmente (clientes, ventas,
trabajadores). BD relacional.
● Semiestructurados: Se almacenan como objetos o documentos sin
estructura uniforme (XML, JSON, etc).
● No estructurados: no tienen estructura interna identificable o útil.
Son datos en bruto y no organizados (ficheros de texto,
comunicaciones internas, imágenes, sonidos, etc).

38. ¿Cuál es el problema del SQL?
1. Diseñado para bases de datos relacionales.
2. Es rígido (no da mucha flexibilidad).
3. Es independiente de las aplicaciones (aprender a usarlo).
4. Relaciones entre objetos sencillas pueden provocar consultas
complejas en tiempo y recursos.

39. ¿Cuál es el problema de los sistemas relacionales?
1. Bajo rendimiento en alta frecuencia de lecturas y escrituras.
2. No soportan cambios en los esquemas de datos de forma
dinámica y están “limitados” a datos estructurados.
3. No escalan de forma sencilla ni barata (para trabajar con un
gran volumen de datos).
4. La normalización implica un peor rendimiento.

40. Práctica 1
Conociendo las bases de datos relacionales y el lenguaje SQL

41. 4 - Bases de datos NoSQL
4.1 - ¿Qué implica el concepto NoSQL?
4.2 - NoSQL vs Relacional
4.3 - Características y ventajas
4.4 - NoSQL en grandes arquitecturas
4.5 - Tipos de bases de datos NoSQL

42. Orígenes del término
Carlo Strozzi definió el concepto NoSQL en 1998 como un SGBDR sin
SQL. En 2009, Eric Evans lo impulsó y diferenció de los SGBDR.
“... is not an SQL database but rather a shell-level tool...”
+ funcionalidades
+ libertad

43. El término NoSQL
El término NoSQL se refiere a Not Only SQL (no solo
SQL) englobando a las bases de datos que no son
relacionales. ¿NoREL?
No es un sustituto de los SGBDR sino una
alternativa.

44. NoSQL vs Relacional
Bajo NoSQL englobamos el conjunto de SGBD para gestionar
datos en entornos donde las BD relacionales no son la mejor
solución:
1. Se necesitan esquemas de base de datos más flexibles (podemos trabajar
sin haber especificado previamente una estructura).
2. El lenguaje SQL no es la mejor aproximación para trabajar con los datos.
3. Necesidad de sistemas distribuidos para gestionan grandes volúmenes de
datos con alta disponibilidad.

45. Implicaciones de un esquema de datos flexible
Disponer de un esquema de datos flexible (schemaless) implica:
1. No hay un esquema de base de datos predefinido.
a. No tenemos que crear tablas ni definir relaciones.
2. El esquema puede variar para datos de una misma entidad.
a. No hay condicionantes a la hora de almacenar datos. No se busca uniformidad.
3. El gestor de la BD puede no ser consciente del esquema de la BD.
a. No necesita saber qué ni cómo se está almacenando. Complica el trabajo entre equipos.
Facilita la inserción y acceso rápido de grandes volúmenes de información.

46. Alternativas al lenguaje SQL
No utilizar el lenguaje SQL implica:
1. Algunas BD ofrecen su propio lenguaje de creación y manipulación mucho
más óptimo (match entre lenguaje y BD).
2. Cada BD proporciona drivers de acceso para múltiples lenguajes. Puede
haber limitaciones.

47. Sistemas distribuidos
Necesitar un sistema distribuido implica:
1. Trabajamos con un volumen tan grande de datos que no es posible ubicarlos
en un único sitio físico.
2. Hay que ofrecer mecanismos para coordinar las diferentes bases de datos
distribuidas y ser conscientes de sus limitaciones (CAP).
3. Implica un conocimiento adicional a las BDs tradicionales.

48. Data warehouse
Bases de datos operativas
Son sistemas especializados
Empresa 1 Empresa 2 Empresa 3
MySQL Oracle
...
Informes Análisis de datos
NoSQL
SGBD especializados. Más de 200
posibilidades para adaptarse a cada
operatividad (http://nosql-database.org)

49. Principales diferencias del NoSQL
Las principales diferencias de NoSQL frente a RDBMS son:
1. No están limitadas a datos estructurados (semi y sin estructura).
2. Esquema de datos flexible.
3. No suelen ofrecer SQL como lenguaje.
4. En general, son distribuidas (commodity).
5. En general, no garantizan propiedades del modelo ACID.
6. Frecuentemente son de código abierto.

50. Principales inconvenientes
Las principales inconvenientes de las BD NoSQL:
1. Falta de estándares (demasiados tipos).
2. La gestión de un esquema de BD puede ser complejo.
3. Dificultad en la administración de la BD.
4. Más limitadas en funcionalidades.
5. Falta de madurez.
6. Falta de especialistas y curva de aprendizaje.

51. Teorema CAP
Teorema CAP
Es imposible garantizar en un sistema distribuido simultáneamente
(C)onsistencia, (A)Disponibilidad y (P)Tolerancia a partición.
Solo podemos garantizar dos de ellas.
Partición
Consistencia
Disponibilidad
El sistema devuelve los mismos valores para los mismos
datos en un mismo instante de tiempo.
El sistema siempre devuelve información aunque es posible
que eventualmente ésta no sea la más actualizada.
El sistema proporciona servicio a
pesar de posibles fallos en nodos

52. Triángulo NoSQL cuando hay partición (sistemas distribuidos)
Consistencia
(C)
Tolerancia a
particiones
(P)
Disponibilidad
(A)
Siempre habrá un nodo
funcionando tras una partición
AP: el sistema siempre está disponible,
aunque temporalmente puede mostrar datos inconsistentes
CP: el sistema siempre contiene una visión consistente de los
datos, aunque no esté totalmente disponible en presencia de
particiones.

53. Teorema CAP
Consistencia
(C)
Relacionales (CA)
NoSQL (CA)
Neo4J
Aseguran ACID
NoSQL (CP)
HBase
MongoDB
Redis
NoSQL (AP)
Riak
Cassandra
CouchDB
Tolerancia a
particiones
(P)
Disponibilidad
(A)

54. ACID vs BASE
SGBDR
Modelo
ACID
(A)tomicidad
(C)onsistencia
(I) Aislamiento
(D)urabilidad
Modelo
BASE
(B)asically
(A)vailable
(S)oft State
(E)ventually
Consistent
Gracias al almacenamiento distribuido y replicado,
podemos concluir que siempre estará disponible aún
cuando ocurran fallos. Una parte, al menos, podrá estar
accesible.
La información se propaga por todos los nodos,
garantizando, en algún momento, consistencia.
La información puede ser volátil y no mantener
consistencia (algo que podría gestionar el desarrollador de
la aplicación).
Eric Brewer
Teorema CAP
(2000)
Muchas NoSQL

55. NoSQL vs Relacional
Relacional NoSQL
Modelo ACID
Teorema CAP
BASE

56. Escalabilidad
Escalabilidad del software
Es la capacidad del software para adaptarse a las necesidades de
rendimiento a medida que el número de usuarios crece, las
transacciones aumentan y la base de datos empieza a experimentar
problemas en grandes cargas.

57. Escalabilidad del software
NoSQL
Relacional
Escalabilidad
Escalabilidad vertical
Mejorar hardware existente
Escalabilidad horizontal
Red de servidores
Fácil de implementar
No afecta al software
Rápida y económica
Crecimiento infinito
Tolerancia a fallos
Soporta alta disponibilidad
Balanceo de cargas

58. Relacional
vs
NoSQL

59. Funcionalidades a valorar en una base de datos
¿En qué debemos fijarnos?
Rendimiento Escalabilidad Flexibilidad Complejidad
¿Qué velocidad
de ejecución
tiene?
¿Cuántos
recursos
necesita?
¿Qué tipo de
escalado
soporta?
¿Requiere alguna
necesidad
concreta?
¿Limitaciones
para almacenar?
¿Qué tipos de
conectores
ofrece?
¿Cuánto cuesta
de mantener?
¿Necesita alguna
arquitectura
especial?

60. Diferencias por funcionalidad
Funcionalidad Relacional NoSQL
Rendimiento Medio Alto
Escalabilidad Costosa Alto
Flexibilidad Bajo Alto
Complejidad Fácil Depende
Consistencia Alto Depende
Fiabilidad Alto Depende

61. Resumen de lo hablado
Base de datos relacional
Siguen un esquema de datos
(información estructurada)
Garantizan integridad de los datos
Normalizada - ACID
(sin anomalías en los datos)
Escalan en vertical
Misma bases de datos para todos los proyectos
Buen soporte
Multiplataforma
Base de datos NoSQL
No se necesita esquema de datos
(información sin estructura fija)
Su propósito no es garantizar la integridad
No está normalizada - BASE
(puede haber anomalías)
Escalan en horizontal
Diferentes bases de datos para diferentes proyectos
En general, soporte poco maduro
Plataformas más limitadas

62. Resumen de lo hablado
Ventajas Inconvenientes
Trabaja eficientemente con gran cantidad de datos
(además de diferentes tipos y muy flexibles)
Poco tiempo en el mercado si lo comparamos con las
relacionales (+30 años)
Sistemas fácilmente escalables Necesitamos mecanismos de control fuera de las bases
de datos (por lo general, no suelen soportar ACID)
Funcionan en máquinas con pocos recursos (distribuido) Falta de estandarización (muchos tipos y sin un estándar
definido como las relacionales)
Evitamos cuellos de botella (distribuido) Pobre soporte multiplataforma (principalmente Linux) y de
herramientas administrativas (consola)
NoSQL: ventajas e inconvenientes

63. Resumen de lo hablado
SQL NoSQL
Es el único lenguaje de consulta de las relacionales Pueden tener diversos lenguajes de consulta (flexibilidad)
Utilizan tablas como modelo de almacenamiento Utilizan diversos formatos de almacenamiento (JSON,
XML, grafos, etc)
Las operaciones JOIN son muy comunes No se suelen hacer operaciones JOIN
Se basa en una arquitectura centralizada Se basa en una arquitectura distribuida
SQL vs NoSQL

64. Resumen de lo hablado
Relacional
Centrado en las operaciones
Estructuradas
Relacional
Consistente
Rígido
Sistema maduro
Estable
Conclusión
NoSQL
Centrado en el aspecto global de los datos
Semi estructuradas
Orientado a objetos
Consistencia eventual
Flexible
Sistema emergente
Escalable

65. Los líderes tecnológicos
Empresas como Google, Facebook,
Amazon o Twitter han sido las impulsoras
del NoSQL ya que no era posible operar
en bases relacionales con tal cantidad
de datos de forma eficiente.

66. Los líderes tecnológicos
Google Amazon Facebook Twitter
2004 - BigTable 2007 - DynamoDB 2008 - Cassandra FlockDB
Google Cloud
pago
Amazon Web Services
pago
Cassandra
Open source
FlockDB
Open source

67. Mezcla de bases de datos
Pero… ¿se han pasado al NoSQL?
● Google usa MariaDB (MySQL adaptado y personalizado).
● Facebook utiliza MyRocks, un MySQL adaptado y personalizado.
● Twitter hace uso de MySQL adaptado y personalizado.
[+ info]: Proyecto para escalar MySQL

68. Mezcla de bases de datos
Entonces… ¿utilizan NoSQL o no?
● Google Cloud es un contenedor de aplicaciones y servicios que ofrece
soluciones NoSQL como SQL. Su motor interno de almacenaje es BigTable.
● Facebook ha desarrollado y utiliza rocksDB (base de datos clave-valor open
source basada en LevelDB, de Google).
● Twitter utiliza Hbase. También cuenta con FlockDB, su propia base de datos
asociada a grafos.

69. Mezcla de bases de datos
Entonces… ¿qué es lo ideal?
La solución más óptima es una mezcla de ambas.
Para trabajar con datos estructurados o funcionalidades donde se necesita
integridad referencial, debemos utilizar BD relacionales.
Para funcionalidades donde necesitemos un alto rendimiento o una solución
distribuida sin necesidad de asegurar consistencia total, NoSQL.

70. ¿Qué arquitectura de datos utiliza Twitter?
Arquitectura de Twitter
● [rel] MySQL para almacenamiento de usuarios y tweets [+info]
● [nosql] FlockDB para almacenar los grafos sociales (followers) [+info]
● [nosql] Snowflake (Cassandra) para generar IDs únicos [+info]
● [nosql] Redis: para generar los timelines [+info]
● [nosql] Hadoop, Pig, Hive y Hbase: [+info]
● Gizzard: Framework para trabajar con información distribuida [+info]
● Apache Lucene: API para realizar búsquedas [+info]

71. La importancia de la arquitectura
De nada sirve tener la mejor BD
implementada si la arquitectura asociada
a la misma no es la adecuada.

72. La importancia de la arquitectura
Forocoches
1.500.000 usuarios registrados
230.000 visitantes al día
255.000.000 mensajes disponibles
3.000.000 mensajes nuevos al mes

73. La importancia de la arquitectura

74. La importancia de la arquitectura

75. Emular NoSQL en una Relacional
¿Se puede emular una BD NoSQL en una BD relacional?
● No utilizar JOINS.
● No crear ni utilizar esquemas de datos.
● Realizar búsquedas solo por clave primaria o índice.
● No usar índices autoincrementales. Mejor un GUID.
● No usar transacciones a nivel de BD (hacerlo en código).
● Almacenar objetos JSON (o similar).
● No utilizar funcionalidades avanzadas (disparadores, vistas, etc).

76. Lo realmente importante
Big Data no trata solo de cantidad sino
de calidad y eficiencia.
Se busca la optimización para evitar problemas de
escalabilidad y rendimiento.

77. Las bases de datos relacionales soportan gran capacidad de almacenamiento
1 terabyte = 1.000 gigabytes

78. ¿Cuándo es la mejor opción?
Debemos usar NoSQL cuando...
El volumen de datos operacional (no histórico) es muy grande.
Escritura y lectura se realiza de forma masiva (sensores / sistemas distribuidos).
Necesitamos tiempo de respuesta rápidos en sistemas operacionales complejos (identificar matrículas).
La información no es apta para ser consultada con lenguaje SQL.
Trabajamos con tipos de datos flexibles y diversos (documentos, grafos, objetos, etc).
Escalar la solución tecnológica es difícil y muy costoso.
¿Cuándo usar NoSQL?

79. Ejercicio
¿Qué debemos usar si...
Necesitamos implementar operaciones complejas (exactitud)
Las estructuras de los datos son variables
Queremos analizar grandes volúmenes de datos
Queremos hacer captura y procesado de eventos en tiempo real
Queremos montar una tienda online
Necesitamos garantizar que no haya errores en la inserción
Afianzando conceptos
Solución
Relacional
NoSQL
NoSQL
NoSQL
Relacional
Relacional

80. Relacional optimizadaNoSQL
- Sin dirección asistida
- Por debajo de 400ºC, sin frenos
- Sin marcha atrás
- Gasta rápidamente las ruedas

81. NoSQL
NOSQL optimizada y distribuida

82. No todas las carreteras están hechas para correr

83. Tipos de bases de datos NoSQL según su modelo (cómo se almacenan los datos)
Tipos de bases de datos NoSQL según
modelo de datos
● Clave - Valor
● Documental
● Columnas
● Grafos

84. Ideal para múltiples y
complejas relaciones entre
datos
Ideal para datos no estructurados y semi estructurados
Tipos de bases de datos NoSQL
Clave-Valor Columnas Documental Grafos
Datos simples Datos complejos
Multimodelo: ArangoDB o OrientDB
Operaciones

85. Rendimiento según tamaño y operaciones
Tamañodelabasededatos
Complejidad de las operaciones y datos
Relacionales
Clave - Valor
Columnas
Documental
Grafos

86. Clave - Valor
Características Ventajas
Cada elemento es un par clave/valor. Almacena en JSON o
BLOB (objeto grande binario como archivos multimedia)
Ideal para E/S con grandes cantidades
de datos
Simple y potente. Permite trabajar con gran cantidad de datos en
operaciones sencillas.
Buen rendimiento en operaciones en
tiempo real (streaming)
Eficiente en lectura y escritura
Dispone de pocas funcionalidades. Limitado en las búsquedas
Si no tenemos cuidado, podemos generar falta de consistencia
en los datos ya que la BD ignora la estructura del valor
almacenado
Bases de datos Clave - Valor
BigTable, Redis, Memcached, Hazelcast, Riak

87. Clave - Valor
Clave Valor
1 {Nombre: Pipo, Raza: Boxer}
2 [Nombre: Rex]
3 {Raza: Pastor Alemán, Edad:5, Dueño:Emilio}
Dentro del valor de cada clave podemos incluir lo que queramos. No hay
un patrón establecido.

88. Clave - Valor
Redis
Sus operaciones son atómicas y persistentes (CP). Su principal
ventaja es que trabaja en memoria RAM aunque también puede
hacerlo en disco (ofrece mayor velocidad que otras soluciones).
Sin soporte para Windows, Ideal para acciones en tiempo real.
Probar online / 11 casos en los que usar Redis

89. Práctica 2
NoSQL - Redis

90. Columnares
Características Ventajas
La información se almacena en columnas en lugar
de en filas como se hace en las BD relacionales
Ideal para soluciones BI (consultar histórico)
Orientado a lectura pero no ofrece JOINS Trabajan bien con gran cantidad de datos
El rendimiento en escritura es bajo
Facilita el cálculo de datos agregados
Bases de datos Columnares
Cassandra, Hbase, Microsoft Azure

91. Columnares
Cassandra
Creado inicialmente por Facebook, utiliza su propio lenguaje de
consulta: CQL (Cassandra Query Language) similar al SQL pero
no permite hacer JOINS. Garantiza la escalabilidad y
disponibilidad (AP) y es multiplataforma.
Dispone de una interfaz agradable.
Lo utilizan portales como Twitter, Reddit, NetFlix o Instagram.

92. Documentales
Características Ventajas
La información se almacena como un documento
semi estructurado JSON, XML o BSON (JSON
codificado en binario)
Facilidad en el desarrollo y programación asociada
Parte de Clave - Valor (misma velocidad) pero con
una mayor flexibilidad gracias a los datos semi
estructurados (acceso a través de los documentos,
definición de índices, etc)
Similares a BD relacionales que almacenan
objetos como PostgreSQL, DB2, MS SQL Server u
Oracle.
Facilita la transición desde relacional
Permite búsquedas complejas y operaciones
dentro de los documentos
Bases de datos Documentales
MongoDB, CouchBase, Firebase Realtime. Google Cloud Datastore

93. Documentales
Cada documento es flexible en cuanto a lo que almacena y cómo lo
almacena
Nombre: Raquel
Apellido: García
Ciudad: Madrid
Edad: 25
Estado: Soltero
Clave: 1
Nombre: Manuel
Apellido: Ortiz
Edad: 35
Estado: Casado
Hijos: {
Julio:2,
Rosa:5
}
Clave: 2
Nombre: Emilio
Estado: Casado
Clave: 3

94. Documentales
MongoDB
Almacena la información en BSON (JSON + binario). Dispone de
funcionalidades de las BD relacionales como son los índices y la
posibilidad de hacer consultas complejas.
Es una de las NoSQL más utilizadas (CP).

95. Práctica 3
NoSQL - MongoDB

96. Documentales
CouchDB
La interfaz se basa en peticiones HTTP a través de una API y el
lenguaje para interactuar es javascript.
Almacena datos en JSON y permite generar vistas (agrupación de
documentos equivalente al JOIN).
Sin soporte en Windows.

97. Grafos
Características Ventajas
Se basan en nodos y sus relaciones (aristas).
Podemos consultar ambos.
Facilita los problemas que se resuelven con grafos
Para funcionar de forma óptima, la estructura debe
estar normalizada.
Garantiza ACID en transacciones
Eficiente navegación a través de las relaciones Gran tiempo de respuesta al navegar entre
relaciones (no se necesitan JOINS)
No funciona bien con consultas genéricas Sin esquema de datos (implícito en su estructura)
No hay un modelo estándar
Bases de datos Grafos
Neo4j, Giraph, Dgraph

98. Grafos
Emilio Raquel
Pastor
AlemánTiene
Madrid
Vive en
Primo de
Pienso
Come

99. Grafos
Neo4j
La relación entre nodos funciona a modo de índice natural y nos
permite explotar, de forma rápida y óptima, las relaciones entre
datos. (CA)
[+ info]: Entendiendo los grafos y casos de éxito de Neo4J

100. Objetos
Características Ventajas
La información se representa mediante objetos
como los utilizados en los lenguajes de
programación orientada a objetos (POO)
Adaptación perfecta entre la programación y la
base de datos
A menudo son sustituidas por ORM (Object-
Relational Mapping) como Hibernate (Java),
Propel o Doctrine (PHP)
Ejemplos: Zope, Gemstone, Db4o
Difícilmente escalables
Bases de datos Orientadas a objetos
Db4o, ObjectStore

101. Multidimensionales
Características Ventajas
Se utilizan cubos OLAP (OnLine Analytical
Processing- array multidimensional) para organizar
los datos y expresar las relaciones entre ellos
Análisis instantáneo de grandes cantidades de
datos
Se usan en datawarehouses y datamarts
principalmente
Su objetivo principal es recuperar, filtrar y realizar
cruces de ingentes cantidades de datos, con el fin
de generar informes en tiempo récord
Bases de datos Multidimensionales
Halo, IBM Cognos, Sisense, SAP BI

102. MongoDB
HBase
Cassandra
Riak
RDBMS
Neo4J
RavenDB
Necesidad
Almacenar
Acceso
rápido
Operaciones
complejas
REDIS
Almacenar
AP
Cassandra
Riak
Voldemort
CP
Hbase
MongoDB
CouchBase
DynamoDB
CAP
IlimitadoRAM
ACID Disponibilidad
Hbase
MongoDB
CouchBase
DynamoDB
Propiedades
Sin escalar Ilimitado

103. -Find the right tool for the job-
Right data model for the right problem.
Right product for the right problem.

104. La elección de un SGBD siempre
implica elegir un conjunto de
propiedades deseables frente otras.

106. 5 - NewSQL
5.1 - ¿Qué es el NewSQL?
5.2 - Proyecto WebScaleSQL

107. Qué es NewSQL
“NewSQL es una clase de SGBDR (relacionales) que tratan de
conseguir el mismo rendimiento escalable de sistemas NoSQL
para el procesamiento de transacciones en línea (lectura-
escritura), manteniendo durante las cargas de trabajo las garantías
ACID de un sistema de base de datos”
NewSQL = Relacional + distribuida

111. WebScaleSQL
Proyecto open source (ya cancelado 2014 - 2016) mantenido por
ingenieros de Alibaba, Facebook, Google, LinkedIn y Twitter para
escalar MySQL.

112. 6 - Lecturas interesantes
Recursos y lecturas para complementar la clase

113. Lecturas interesantes

114. Lecturas interesantes

115. Lecturas interesantes

116. Lecturas interesantes

117. Lecturas interesantes

118. Lecturas interesantes

119. Lecturas interesantes

120. Lecturas interesantes

121. Lecturas interesantes

122. Lecturas interesantes

123. Lecturas interesantes

124. Lecturas interesantes

125. Lecturas interesantes

126. Bases de datos NoSQL
en entornos Big Data
Emilio Rodríguez / erodriguez@smartup.es / @emirodgar