El fenómeno NoSQL

Bases de datos a gran escala

Máster en Tecnologías y Aplicaciones en Ingeniería Informática

1

Historia

80’s: Aparición de las BDRs

• Persistencia
• Gestión de la concurrencia. Transacciones
• SQL
• Informes

Problemas de las BDR

• Impedance Mismatch
• Modelos de memoria y de almacenamiento diferentes
• Luego llegaron los ORM (Hibernate, …)

​

​

90’s Aparición de las BDOO

• Década del crecimiento de los lenguajes OO
• Evitar la impedance mismatch
• El modelo relacional exige que los valores de columna sean simples. No pueden contener estructura (registros anidados, listas, …)
• Guardar las estructuras de memoria (OO) en disco
• Sin mappings
• No tuvieron éxito

Uso de las BD como BD de integración

• Dominio de las BDR durante más de 20 años (Insólito!!!)
• Aplicaciones diferentes interactuando sobre un conjunto de datos común y consistente
• ↓ No está lo que necesita una aplicación, sino lo que necesitan todas
• ↓ Necesidades de rendimiento e indexación diferentes difíciles de acometer

Uso de las BD como BD de aplicación

• BD accedida sólo por una aplicación
• Estructura de la BD conocida sólo por el equipo de desarrollo de la aplicación
• Control de la integridad trasladado a la aplicación
• Interacción con la BD a través de servicios, no con SQL
• Aplicaciones aisladas de efecto de los cambios

Llegaron los datos a gran escala

• Servicios
• Google: Finales de los 90
• Amazon: Mediados de los 90
• Youtube: 2005
• Facebook: 2004
• …
• Grandes conjuntos de datos
• Redes sociales
• Registro de actividad con logs
• …

Solución al problema del crecimiento

• Escalado vertical
• Grandes aumentos de coste
• Existen límites que no se pueden sobrepasar

Solución de Google para el crecimiento

Escalado horizontal con commodity hardware

Problema de SQL en clústers

• SQL fue diseñado para ejecutarse en una máquina
• SQL no funciona muy bien en clústers
• Consulta, integridad referencial, transacciones, consistencia, …

​

​

Bueno para SQL

Malo para SQL

La revolución de Google y Amazon

• Desarrollo de nuevos sistemas de almacenamiento

• Originaron una nueva corriente en Bases de datos

Origen del término NoSQL

• Propuesta por Carlo Strozzi
• Finales de los 90
• Tablas como archivos ASCII
• Base de datos manipulada con scripts de shell, no con SQL
• Hashtag de Twitter propuesto por John Oskarsson, empleado de Last.fm, para una reunión sobre BD distribuidas open source
• Realmente
• Grupo de BD que no están bajo el paraguas SQL
• No existe una definición de NoSQL
• Muchas ofrecen lenguajes de consulta “inspirados” en SQL

NoSQL según Wikipedia

• A NoSQL or Not Only SQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. Motivations for this approach include simplicity of design, horizontal scaling and finer control over availability. The data structure (e.g. key-value, graph, or document) differs from the RDBMS, and therefore some operations are faster in NoSQL and some in RDBMS.

Características de las BD NoSQL

• No relacional
• Suelen ser Open Source
• Suelen ser amigas de los clústers, salvo las orientadas a grafos
• Sin esquema
• Utiles para BD a escala Web
• No suelen soportar transacciones ACID, salvo las orientadas a grafos

Productos NoSQL

• http://nosql-database.org
• Actualmente (2024) unos 225

Entonces, qué es NoSQL

• Categoría de BD que
• Difiere de BD tradicionales (BDR)
• No requieren de esquemas fijos
• Escalan horizontalmente
• Las BD NoSQL suelen ser sin esquema
• No hay un esquema definido a priori
• Permiten tratar con datos no uniformes
• No obstante, siempre tiende a haber un esquema implícito

2

Principales modelos de datos en NoSQL

Principales categorías de productos NoSQL (según su modelo de datos)

Familia de columnas

Documentos

Clave-valor

Orientadas a grafos

Modelo Clave-valor

• La base de datos no sabe nace acerca del contenido del valor (valor simple, documento complejo, imagen, …)
• Se puede almacenar lo que se quiera
• Búsquedas sólo por la clave
• Es como un HashMap persistente

Modelo Documento

• Documento
• Estructura de datos “compleja”
• No hay esquema
• Conjunto de documentos
• Admiten
• Consultas sobre datos
• Recuperar partes

Clave-valor vs. Documento

• Ambas almacenan la estructura compleja en la BD
• Clave-valor: Opaco
• Documento: Transparente
• La frontera no está clara
• Algunas BD Clave-valor almacenan Metadatos usados por índices para permitir consultas
• Las BD de documentos identifican los docs con un ID

Agregados

• Colección de objetos relacionados que queremos tratar como una unidad
• BD orientadas a agregados
• Clave-valor. Agregado: Valor
• Documentos. Agregado: Documento
• Familia de columnas. Agregado. Registro
• BDR tienden a separar los datos en tablas diferentes
• Los agregados facilitan el almacenamiento en clústers

Esquema e Instancia de Pedidos para BDR

Pedidos como agregados

Otra forma de Pedidos como agregados

BD Clave-valor y de documentos

• BD Clave-valor y de documentos son orientadas a agregados
• BD como un conjunto de agregados con su ID o clave usada para acceder a los datos
• Visión del agregado
• Opaco en BD Clave-valor (son un chorro de bits “sin sentido”)
• Acceso sólo por clave
• Libertad para almacenar cualquier cosa en el valor
• Visible en BD de documentos
• Consultas por campos de los agregados
• Recuperación de parte del agregado
• Indices sobre el contenido del agregado

Familia de columnas (FC)

• También para BD orientadas a agregados
• Varias FC
• FC: Cosas que combinen bien
• Agregado:
• Row Key + Nombre FC

BD de familias de columnas

• También son orientadas a agregados
• Modelo tabular donde cada fila puede tener un número de columnas diferente
• Normalmente, la unidad de almacenamiento es la fila
• Hay escenarios que se benefician de un cambio de enfoque:
• Sólo queremos un grupo de columnas de un grupo de filas
• La estructura de almacenamiento ahora son los grupos de columnas para todas esas filas

BD orientadas a agregados vs. no orientadas

• Modo de agregación determinado por el patrón de acceso
• BDR son ajenas a los agregados

Modelo de agregación útil para clústers

• Los agregados tienden a estar juntos
• No distribuir datos que tienden a ser accedidos conjuntamente
• Cada agregado en un nodo

BD orientadas a grafos

• Mayoría BD NoSQL necesitan clusters
• Modelos de datos orientados a agregados
• Registros de gran tamaño con relaciones sencillas
• BD orientadas a grafos
• Registros pequeños
• Interconexiones complejas
• Características
• No orientadas a agregados
• Buenas para tratar con relaciones entre cosas

Ejemplo

• Usos
• Redes sociales
• Preferencias productos

BDR vs BD orientadas a grafos

• BDR
• Definir claves ajenas
• Hacer joins
• Rendimiento bajo en muy relacionadas
• BDOG
• Fácil expresar relaciones
• Lenguaje de consulta diseñado para recorrer grafos

BD orientadas a agregados vs BDOG

• Relaciones en BD orientadas a grafos usando IDs (en documentos, familias de columnas, …)
• Inconvenientes;
• Eficiencia baja
• Lenguaje de consulta no adecuado
• BD orientadas a agregados
• Usadas en clústers
• Transacciones a nivel de agregado
• BD orientadas a grafos
• Usadas en servidor único
• Transacciones sobre nodos y arcos

3

Problemas de los modelos basado en agregados

Qué ocurre cuando no queremos acceder según lo agregado?

• Modelo de agregación útil cuando se almacenan juntos datos a los que se suele acceder en la forma agregada
• Pero, ¿y para conocer beneficios por producto? – Debemos recorrer todos los pedidos
• Una solución puede ser construir índices sobre los elementos internos (si es posible)

​

Distintas formas de agregación

• Otra solución
• ¿Cambiar la forma de agregación?
• Solución no válida si no es la forma habitual de interacción

BD orientadas a agregados vs. no orientadas

• Suelen ser una característica clave en las BD NoSQL
• No obstante, no todas lo son (p.e. Neo4j)
• BD orientadas a agregados
• Buen rendimiento cuando las interacciones son sobre agregados
• BD no orientadas a agregados
• Buen rendimiento cuando las interacciones utilizan datos organizados/agrupados de cualquier forma

​

Modelado de relaciones en BD de agregados

• Proporcionar una referencia
• Añadir el ID de cliente a los datos agregados de pedido
• Supone hacer dos interacciones con la BD
• Accedemos al pedido y obtenemos el ID del cliente
• Con el ID del cliente recuperamos sus datos
• En las BD clave-valor esto no es tan natural (el valor es opaco)
• Colocar las referencias como metadatos
• Posibles problemas al actualizar
• La atomicidad sólo es garantizada a nivel de agregado

Modelo Blogs en relacional

Modelo Blogs en BD documentos

¿Anidar o no anidar?

• El criterio para anidar es que se muestre a la vez que el documento en el que se accede (p.e. Una entrada de blog mostrará los tags y los comentarios -> tags y comentarios se anidan)
• Además, a los comentarios no se suele acceder si no es a través de los posts. El comentario no se aplica a más de un post
• Con las etiquetas es diferente. Sí aparecen más de una vez. ¿Pero es habitual renombrar una etiqueta para las anomalías de actualización?
• A los autores se puede acceder aparte (Desanidar)
• El documento ocupa más de 16MB (desanidar)

Incluir los datos del agregado y componentes

Usar referencias

Agregados y referencias en Real Time Analytics

• ¿En qué pedidos se ha vendido un producto?
• Almacenar de varias formas según en patrón de acceso

Modelo en una BD orientada a columnas

¿Y las vistas materializadas?

• Vistas que almacenan sus datos en disco
• VM almacenará los datos para el nuevo tipo de acceso
• Actualización de VMs
• Mantener la VM fresca. Actualizarla al actualizar los datos base
• Posible carga de trabajo excesiva e inncesaria en algunos casos (p.e. Consulta de productos vendidos sobre datos no frescos)
• Actualización periódica en función del dominio
• Construcción de VMs
• A cargo de la BD: Hay que proporcionar el modo de cálculo
• Fuera de la BD: Acceso a datos, cálculo, escritura en la BD

Vistas Materializadas guardando datos resumidos

• Y guardar datos resumidos en el agregado?
• Incluir en el pedido un elemento para datos resumidos
• Evita entregar a los programas todo el agregado
• En BD de familias de columnas, usar familias de columnas para VMs
• Actualizar la VM se hace en la misma operación atómica

4

Panorama actual

Bases de datos de aplicación

Persistencia políglota

• RDBMS y NoSQL son complementarias
• Hay que saber dónde usar cada una de ellas
• Usar modelos diferentes para necesidades diferentes

Bases de datos encapsuladas como servicios

• Reducen el impacto sobre elecciones del tipo de almacenamiento