Bases de datos NoSQL en

entornos Big Data

M4 - Tecnologías de Big Data

Emilio Rodríguez / erodriguez@smartup.es / @emirodgar

Í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
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

¿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?
¿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.
Ejemplo para aclarar conceptos

SGBD - explorer.exe
(Software para gestionar los datos)

Base de datos - BD
(conjunto de datos)
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

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.
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.

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

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.
Metodología de diseño de bases de datos (relacional)

Diseño conceptual Diseño lógico Diseño físico

Este diseño es independiente En esta fase se ha concretado Se crea el soporte físico

del tipo/modelo de la base de el SGBD y se aplican los concreto.
datos. procesos de normalización.

Describen la realidad basada Describe las operaciones en

en conceptos y sus detalle.
relaciones.
Metodología de diseño de bases de datos

Lógica del negocio Modelo de datos

conceptual
basado en un
análisis de los
requisitos

Diseño conceptual Diseño lógico Diseño físico

Este diseño es independiente En esta fase se ha concretado Se crea el soporte físico

del tipo/modelo de la base de el SGBD y se aplican los concreto.
datos. procesos de normalización.

Describen la realidad basada Describe las operaciones en

en conceptos y sus detalle.
relaciones.
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.
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
Ejemplo de modelo entidad - relación

Relaciones
(1,N)
fecha
realiza Pedido importe
Atributos impuestos
nombre
dirección Cliente Entidad
teléfono (N,M)
contiene

nombre
precio Producto
cantidad

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.
Diseño conceptual: modelo entidad - relación

Diferentes notaciones para expresar la

cardinalidad
Metodología de diseño de bases de datos

Lógica del negocio Modelo de datos Modelo de

conceptual datos lógico
basado en un y esquema
análisis de los de la BD
requisitos

Diseño conceptual Diseño lógico Diseño físico

Este diseño es independiente En esta fase se ha concretado Se crea el soporte físico

del tipo/modelo de la base de el SGBD y se aplican los concreto.
datos. procesos de normalización.

Describen la realidad basada Describe las operaciones en

en conceptos y sus detalle, tablas y claves.
relaciones.
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).
Diseño lógico: modelo relacional

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: tipos de diseños del modelo relacional

[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: 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).
Dimensión Tabla de hechos Dimensión

Cliente Pedido Producto

Clave primaria idCliente Clave primaria idPedido Clave primaria idProducto

nombre Clave ajena idCliente cantidad

dirección Clave ajena idProducto nombre

ProductosPedido
teléfono fecha precio
idPedido
... importe ...
idProducto
impuestos
cantidad
...
precio
Diseño lógico: normalización de un modelo de datos

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
Esquema de base de datos relacional

Relación (claves)

Tipo de datos

Estructura (tablas)
Los diseños pueden llegar a ser complejos
MySQL Workbench para facilitar el diseño de BD relacionales
Metodología de diseño de bases de datos

Lógica del negocio Modelo de datos Modelo de datos

conceptual asociado al SGBD

Modelo ER Modelo Relacional BD Relacional

Diseño conceptual Diseño lógico Diseño físico

Este diseño es independiente En esta fase se ha concretado Se crea el soporte físico

del tipo/modelo de la base de el SGBD y se aplican los concreto.
datos. procesos de normalización.

Describen la realidad basada Describe las operaciones en

en conceptos y sus detalle.
relaciones.
3 - Bases de datos relacionales

3.1 - ¿Qué son las bases de datos relacionales?

3.2 - Lenguaje SQL

3.3 - Limitaciones
Base de datos relacional

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.
SQL: lenguaje para consultas en la base de datos

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

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).
 ACID
Atomicity, Consistency, Isolation and Durability
Atomicidad, Consistencia, Aislamiento y Durabilidad
● 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).
Transacción en base de datos relacional (ACID)

Inicio Inicio

Lectura Lectura

Escritura 1 Escritura 1 Cancelar

Escritura 2 Escritura 2

guardar guardar
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.

El 80 % de la información relevante
para un negocio se origina en
forma no estructurada.
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).
¿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.
¿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.

Práctica 1
Conociendo las bases de datos relacionales y el lenguaje SQL
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

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
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.
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.
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.

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.
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.

Son sistemas especializados

Informes Análisis de datos

Data warehouse
...

NoSQL
Bases de datos operativas SGBD especializados. Más de 200
posibilidades
MySQLpara adaptarse a cada
Oracle
operatividad (http://nosql-database.org)

Empresa 1 Empresa 2 Empresa 3

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.
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.
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.

El sistema devuelve los mismos valores para los mismos
Consistencia datos en un mismo instante de tiempo.

Partición
El sistema siempre devuelve información aunque es posible
Disponibilidad que eventualmente ésta no sea la más actualizada.
El sistema proporciona servicio a
pesar de posibles fallos en nodos
Triángulo NoSQL cuando hay partición (sistemas distribuidos)

Siempre habrá un nodo

funcionando tras una partición

Tolerancia a
particiones
(P)

Disponibilidad Consistencia
(A) (C)

AP: el sistema siempre está disponible, CP: el sistema siempre contiene una visión consistente de los
aunque temporalmente puede mostrar datos inconsistentes datos, aunque no esté totalmente disponible en presencia de
particiones.
Teorema CAP

Relacionales (CA) NoSQL (CP)

NoSQL (CA) Consistencia HBase
Neo4J (C) MongoDB
Redis
Aseguran ACID

Tolerancia a
Disponibilidad
particiones
(A)
(P)

NoSQL (AP)
Riak
Cassandra
CouchDB
ACID vs BASE

Teorema CAP
Eric Brewer
(2000)

SGBDR Muchas NoSQL

Modelo Modelo
ACID BASE
Gracias al almacenamiento distribuido y replicado,
(B)asically podemos concluir que siempre estará disponible aún
(A)tomicidad
(A)vailable cuando ocurran fallos. Una parte, al menos, podrá estar
accesible.

(C)onsistencia (S)oft State

La información puede ser volátil y no mantener
consistencia (algo que podría gestionar el desarrollador de
la aplicación).

(I) Aislamiento (E)ventually La información se propaga por todos los nodos,

Consistent garantizando, en algún momento, consistencia.

(D)urabilidad
NoSQL vs Relacional

Relacional NoSQL

Modelo ACID BASE

Teorema CAP
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.
Escalabilidad

Escalabilidad del software

Escalabilidad vertical Escalabilidad horizontal

Mejorar hardware existente Red de servidores

Fácil de implementar Crecimiento infinito

No afecta al software Tolerancia a fallos
Rápida y económica Soporta alta disponibilidad

Balanceo de cargas
Relacional

NoSQL
Relacional
vs
NoSQL
Funcionalidades a valorar en una base de datos

¿En qué debemos fijarnos?

Rendimiento Escalabilidad Flexibilidad Complejidad

¿Qué velocidad ¿Qué tipo de

¿Limitaciones ¿Cuánto cuesta
de ejecución escalado
para almacenar? de mantener?
tiene? soporta?
¿Qué tipos de ¿Necesita alguna
¿Cuántos ¿Requiere alguna
conectores arquitectura
recursos necesidad
ofrece? especial?
necesita? concreta?
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

Resumen de lo hablado

Base de datos relacional Base de datos NoSQL

Siguen un esquema de datos No se necesita esquema de datos
(información estructurada) (información sin estructura fija)

Garantizan integridad de los datos Su propósito no es garantizar la integridad

Normalizada - ACID No está normalizada - BASE

(sin anomalías en los datos) (puede haber anomalías)

Escalan en vertical Escalan en horizontal

Misma bases de datos para todos los proyectos Diferentes bases de datos para diferentes proyectos

Buen soporte En general, soporte poco maduro

Multiplataforma Plataformas más limitadas

Resumen de lo hablado

NoSQL: ventajas e inconvenientes

Ventajas Inconvenientes

Trabaja eficientemente con gran cantidad de datos Poco tiempo en el mercado si lo comparamos con las
(además de diferentes tipos y muy flexibles) 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)
Resumen de lo hablado

SQL vs NoSQL

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

Resumen de lo hablado

Conclusión
Relacional NoSQL

Centrado en las operaciones Centrado en el aspecto global de los datos

Estructuradas Semi estructuradas

Relacional Orientado a objetos

Consistente Consistencia eventual

Rígido Flexible

Sistema maduro Sistema emergente

Estable Escalable
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.
Los líderes tecnológicos

Google Amazon Facebook Twitter

2004 - BigTable 2007 - DynamoDB 2008 - Cassandra FlockDB

Google Cloud Amazon Web Services Cassandra FlockDB

pago pago Open source Open source

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

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.
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.
¿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]
La importancia de la arquitectura

De nada sirve tener la mejor BD

implementada si la arquitectura asociada
a la misma no es la adecuada.
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
La importancia de la arquitectura
La importancia de la arquitectura
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).
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.
Las bases de datos relacionales soportan gran capacidad de almacenamiento

1 terabyte = 1.000 gigabytes

¿Cuándo es la mejor opción?

¿Cuándo usar NoSQL?

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.

Ejercicio

Afianzando conceptos
¿Qué debemos usar si... Solución

Necesitamos implementar operaciones complejas (exactitud) Relacional

Las estructuras de los datos son variables NoSQL

Queremos analizar grandes volúmenes de datos NoSQL

Queremos hacer captura y procesado de eventos en tiempo real NoSQL

Queremos montar una tienda online Relacional

Necesitamos garantizar que no haya errores en la inserción Relacional

 NoSQL Relacional optimizada

- Sin dirección asistida

- Por debajo de 400ºC, sin frenos
- Sin marcha atrás
- Gasta rápidamente las ruedas
NOSQL optimizada y distribuida

NoSQL
No todas las carreteras están hechas para correr
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
Tipos de bases de datos NoSQL

Operaciones

Datos simples Datos complejos

Clave-Valor Columnas Documental Grafos

Ideal para datos no estructurados y semi estructurados Ideal para múltiples y

complejas relaciones entre
datos

Multimodelo: ArangoDB o OrientDB

Rendimiento según tamaño y operaciones

Clave - Valor
Tamaño de la base de datos
Columnas

Documental

Grafos

Relacionales

Complejidad de las operaciones y datos

Clave - Valor

Bases de datos Clave - Valor

Características Ventajas

Cada elemento es un par clave/valor. Almacena en JSON o Ideal para E/S con grandes cantidades
BLOB (objeto grande binario como archivos multimedia) de datos

Simple y potente. Permite trabajar con gran cantidad de datos en Buen rendimiento en operaciones en
operaciones sencillas. 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
BigTable, Redis, Memcached, Hazelcast, Riak
Clave - Valor

Dentro del valor de cada clave podemos incluir lo que queramos. No hay
un patrón establecido.

Clave Valor

1 {Nombre: Pipo, Raza: Boxer}

2 [Nombre: Rex]

3 {Raza: Pastor Alemán, Edad:5, Dueño:Emilio}

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

Práctica 2
NoSQL - Redis
Columnares

Bases de datos Columnares

Características Ventajas

La información se almacena en columnas en lugar Ideal para soluciones BI (consultar histórico)

de en filas como se hace en las BD relacionales

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

Cassandra, Hbase, Microsoft Azure

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.

Documentales

Bases de datos Documentales

Características Ventajas

La información se almacena como un documento Facilidad en el desarrollo y programación asociada

semi estructurado JSON, XML o BSON (JSON
codificado en binario)

Parte de Clave - Valor (misma velocidad) pero con Similares a BD relacionales que almacenan
una mayor flexibilidad gracias a los datos semi objetos como PostgreSQL, DB2, MS SQL Server u
estructurados (acceso a través de los documentos, Oracle.
definición de índices, etc)

Facilita la transición desde relacional

Permite búsquedas complejas y operaciones

dentro de los documentos
MongoDB, CouchBase, Firebase Realtime. Google Cloud Datastore
Documentales

Cada documento es flexible en cuanto a lo que almacena y cómo lo

almacena

Nombre: Raquel Nombre: Manuel

Apellido: García Apellido: Ortiz
Nombre: Emilio
Ciudad: Madrid Edad: 35
Estado: Casado
Edad: 25 Estado: Casado
Estado: Soltero Hijos: {
Julio:2,
Rosa:5
}
Clave: 1 Clave: 2 Clave: 3
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).

Práctica 3
NoSQL - MongoDB
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.

Grafos

Bases de datos Grafos

Características Ventajas

Se basan en nodos y sus relaciones (aristas). Facilita los problemas que se resuelven con grafos
Podemos consultar ambos.

Para funcionar de forma óptima, la estructura debe Garantiza ACID en transacciones

estar normalizada.

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

Neo4j, Giraph, Dgraph

Grafos

Madrid Pienso
Come

Vive en
Pastor
Tiene Alemán

Emilio Raquel
Primo de
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

Objetos

Bases de datos Orientadas a objetos

Características Ventajas

La información se representa mediante objetos Adaptación perfecta entre la programación y la

como los utilizados en los lenguajes de base de datos
programación orientada a objetos (POO)

A menudo son sustituidas por ORM (Object-

Relational Mapping) como Hibernate (Java),
Propel o Doctrine (PHP)

Ejemplos: Zope, Gemstone, Db4o

Difícilmente escalables

Db4o, ObjectStore
Multidimensionales

Bases de datos Multidimensionales

Características Ventajas

Se utilizan cubos OLAP (OnLine Analytical Análisis instantáneo de grandes cantidades de

Processing- array multidimensional) para organizar datos
los datos y expresar las relaciones entre ellos

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

Halo, IBM Cognos, Sisense, SAP BI

 Acceso Necesidad Operaciones
rápido complejas

Almacenar Almacenar

RAM Ilimitado Sin escalar Ilimitado

CAP Propiedades

AP CP ACID Disponibilidad

Cassandra Hbase RDBMS Hbase MongoDB

REDIS Riak MongoDB Neo4J MongoDB HBase
Voldemort CouchBase RavenDB CouchBase Cassandra
DynamoDB DynamoDB Riak
 -Find the right tool for the job-

Right data model for the right problem.

Right product for the right problem.
 La elección de un SGBD siempre
implica elegir un conjunto de
propiedades deseables frente otras.
5 - NewSQL

5.1 - ¿Qué es el NewSQL?

5.2 - Proyecto WebScaleSQL

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

WebScaleSQL

Proyecto open source (ya cancelado 2014 - 2016) mantenido por

ingenieros de Alibaba, Facebook, Google, LinkedIn y Twitter para
escalar MySQL.
6 - Lecturas interesantes

Recursos y lecturas para complementar la clase

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