Descripción completa de las Bases de Datos de tipo NoSQL. Comparación con los modelos relacionales. Tipologías y softwares más extendidos. Ámbito geoespacial: ¿qué funcionalidades existen en las bases de datos NoSQL para el tratamiento de datos espaciales?
Las marcas automotrices con más ventas de vehículos (2024).pdf
Bases de datos NoSQL (+ ámbito geoespacial)
1. Bases de datos NoSQL
Definición, comparación con modelo relacional, tipos, software y ámbito geoespacial
Valentín Sastre Calvi
Big Data para Geoservicios
Ingeniería en Geoinformación y Geomática
Universitat Politècnica de Catalunya
Curso 2019-2020
2. Índice
1- Introducción y contexto histórico
2- Modelo relacional
3- Modelo NoSQL
3.1- Fundamentos y comparación con modelo relacional
3.2- Clasificación y software
4- NoSQL en el ámbito geospacial
3. 1- Introducción y contexto histórico
Smartphones
Redes sociales
Sensores
Exceden la capacidad de los sistemas de
gestión de datos tradicionales:
las bases de datos relacionales
Enormes conjuntos de datos
4. 1- Introducción y contexto histórico
1884: Tarjetas perforadas (Herman Hollerith) -> Utilizadas en el censo de EEUU
~1950: Cintas magnéticas -> Ámbito industrial -> Automatización
~1960: Discos -> Acceso a información sin saber “dónde está” - > Velocidad
~1970: Edgar Frank Codd -> BASES DE DATOS RELACIONALES -> Oracle
~1980-90: Lenguaje SQL -> Excel, Access... & World Wide Web
~2000: Dominio de IBM, Microsoft y Oracle & internet -> Google
5. 2- Modelo relacional
· Modelo de datos más extendido -> Base del “SQL”, Structured Query Language
· Estructura la información utilizando relaciones (tablas) -> Forma de grid (rejilla): filas y columnas
· Cada relación se forma a partir de atributos (columnas), cada tupla (fila) tiene un valor por atributo.
· Una entidad es un objeto sobre el que se almacena información y está formado por atributos, uno (o
varios) de los cuales es único (no se repite) y que se llamará clave primaria.
· Las relaciones o “asociaciones” entre entidades se dividen en general entre 1-1, 1-N y N-N.
8. 3- Modelo NoSQL
3.1- Fundamentos y comparación con el modelo relacional
No existe una definición inequívoca y precisa del concepto NoSQL.
Etimológicamente, NoSQL surge como acrónimo (Not only SQL), enfatizando el estilo de consulta.
Recoge los modelos de BBDD no relacionales que, de alguna u otra manera, cumplan con estas
características:
Estas características hacen a los almacenes de datos NoSQL especialmente adecuados para su uso en la nube.
· Simples y flexibles (schema-free)
· Alto rendimiento y disponibilidad (AP en la teoría CAP)*
· Escalabilidad horizontal (arquitectura distribuida)
· No suelen soportar transacciones (ACID)
*
9. 3- Modelo NoSQL
3.1- Fundamentos y comparación con el modelo relacional
Aspecto Modelo relacional Modelo NoSQL
Esquemas, modelos y estructuras
de datos
Esquema E-R. Tablas con relaciones y
restricciones.
Schemaless. No define relaciones ni restricciones.
Soporta datos no estructurados.
Arquitectura de computación Una única “ubicación”. Computación distribuida. Varios nodos que forman
un clúster (EH).
Escalabilidad Tienden a la escalabilidad vertical (mejora
hardware).
Tienden a la escalabilidad horizontal (agrega
nodos).
Lenguaje de consulta SQL. CQL, JSON...
Transacciones ACID (soporta transacciones). BASE (Basically Available, Soft-state, Eventually
consistent) (no soporta tr.)
10. 3. Modelo NoSQL
3.2- Clasificación y software
Clave - valor
Modelo sencillo basado en pares de clave-valor, formando un “diccionario”. -> La clave identifica el valor y se utiliza
para acceder a este.
Almacena los datos como “tablas hash”, con dos columnas: key & value. El valor puede ser de cualquier tipo.
El almacenamiento distribuido se basa en la repartición de la información en nodos a partir de las claves
(imposibilitando establecer relaciones o estructuras) -> Alta escalabilidad pero menor consistencia.
Al ser los valores “opacos” para el sistema, no permiten la consulta ni la indexación a nivel de datos (solo se pueden
realizar consultas por las claves).
Pueden ser in-memory (mantienen los datos en memoria) o in-disk (o persistentes, mantienen los datos en disco).
Soportan transacciones (ACID) en casos en el que la clave sea única.
11. 3. Modelo NoSQL
3.2- Clasificación y software
Clave - valor
Debido a su capacidad de gestión de grandes cantidades de datos y procesamiento de flujos constantes de
operaciones de lectura y escritura, sus aplicaciones más frecuentes son:
- Gestión de sesiones a gran escala
- Almacenamiento de perfiles y preferencias de usuario
- Recomendaciones de productos, últimos productos vistos en tienda online...
- Servicios de anuncios publicitarios y hábitos de compra que resulten en anuncios y cupones personalizados a
tiempo real
Ejemplo (base de empleados):
12. 3. Modelo NoSQL
3.2- Clasificación y software
Clave - valor
Software más popular: (open-source)
Utilizado para aplicaciones caché, agentes de mensajes y cola debido a su almacenamiento en memoria, a pesar de
permitir también ser utilizado como BBDD persistente/duradera mediante la realización de snapshots (capturas del
estado de la base de datos en momentos concretos) o mediante un sistema de journaling, que transmite cada
modificación o inserción de datos.
Permite ejecutar millones de peticiones por segundo a tiempo real, por lo que se utiliza en ámbitos como el
publicitario, económico-financiero, sanidad, videojuegos o IoT; en tareas de caché, adm. de sesiones, análisis en
tiempo real, datos geoespaciales, chats, streaming de contenido multimedia, etc.
13. 3. Modelo NoSQL
3.2- Clasificación y software
Documentales
Suponen una derivación de las bases key-value, utilizando claves para localizar documentos dentro del data store.
Utilizan generalmente el lenguaje JSON (o BSON) para describir los documentos, que pueden contener estructuras
complejas de datos, como objetos anidados, y no requiere de un esquema fijado.
Algunos sistemas agrupan los documentos en colecciones, haciendo necesario que cada documento tenga ID único.
La escalabilidad horizontal se realiza de igual manera que en las bases clave-valor, particionando el espacio clave.
Ejemplo (base de empleados):
14. 3. Modelo NoSQL
3.2- Clasificación y software
Documentales
Software más popular: (open-source)
Puede contener múltiples colecciones heterogéneas de documentos. Campos típicos de aplicación de MongoDB
son las series temporales y el IoT, las apps, el comercio electrónico y el pago telemático, las analíticas, la inteligencia
artificial, los catálogos, los videojuegos...
Son catálogos de carácter semiestructurado que soportan búsquedas por campos (indexables), consultas de rangos
y expresiones regulares.
Pueden usarse como sistemas gestores de archivos, explotando su escalabilidad horizontal, así como su capacidad
de replicación en varios servidores.
15. 3. Modelo NoSQL
3.2- Clasificación y software
Orientadas a columnas
Se organizan en columnas en lugar de filas. Esto aporta una gran eficacia en consultas analíticas como las listas de
selecciones, en las que se suelen leer unos pocos atributos pero que necesitan recuperar todas las instancias del
elemento.
Cada columna se almacena de forma contigua en ubicaciones separadas en disco. Los operadores de lectura
columnares se distinguen de los orientados a filas en que son capaces de “traducir” las posiciones de los valores en
localizaciones de disco, combinando y reconstruyendo si es necesario, tuplas de diferentes columnas.
Este aumento en la velocidad de lectura contrasta en una cierta ineficiencia en los procesos de escritura. Por ello,
este tipo de soluciones se aplica en contextos con altos índices de lectura pero bajos de escritura.
16. 3. Modelo NoSQL
3.2- Clasificación y software
Orientadas a columnas
Ejemplo (base de empleados):
En este caso, para remarcar la diferencia con las bases de datos orientadas a filas (relacionales SQL), cabe destacar
la secuencia de almacenamiento en memoria de cada una de las estructuras de organización de los datos. En una
base de datos relacional tradicional, los datos se almacenarían de la forma
‘12345678A’,’Juan Pérez’,’90123456B’,‘Ana López’,’78901234C’,’Ángel García’
haciendo que, por ejemplo, para recuperar todos los nombres, sea inevitable leer todos los DNIs. Sin embargo, en
las bases de datos columnares, la secuencia de datos almacenados sería
‘12345678A’,’90123456B’,’78901234C’,’Juan Pérez’,’Ana López’,’Ángel García’
17. 3. Modelo NoSQL
3.2- Clasificación y software
Orientadas a columnas
Software más popular: y
HBase divide cada tabla en familias de columnas. Cada fila se identifica con una clave de fila. Cada celda
(intersección entre fila y columna) guarda un historial de cambios (contenido y timestamp).
Cassandra destaca por su tolerancia a particiones y su disponibilidad (frente a la consistencia y la disponibilidad que
garantiza HBase). Es altamente escalable horizontalmente, siendo sus datasets divisibles y distribuibles a lo largo
del clúster basándose en la asignación de un token único que es calculado para cada registro. Tiene su propio
lenguaje de consultas (CQL), derivado del SQL.
18. 3. Modelo NoSQL
3.2- Clasificación y software
Orientadas a columnas
Software más popular: y
19. 3. Modelo NoSQL
3.2- Clasificación y software
Grafos
Tienen su origen en la teoría de grafos, concepto matemático usado para representar un conjunto de datos,
conocidos como vértices o nodos, y los enlaces o aristas que los interconectan. Este tipo de BBDD pueden
administrar de forma eficiente las relaciones entre diferentes nodos de datos.
Su enfoque se especializa en gestión de información altamente interconectada. Eficaz en entornos como las redes
sociales, el reconocimiento de patrones, los análisis de dependencia, los sistemas de recomendación y la resolución
de problemas de path-finding en sistemas de navegación.
En estas bases de datos, tanto los nodos como las aristas también constan
de propiedades individuales en forma de clave-valor.
20. 3. Modelo NoSQL
3.2- Clasificación y software
Grafos
Software más popular: (open-source)
Utiliza un modelo de datos que utiliza un grafo de propiedadas etiquetadas. Por ello, sus unidades básicas son los
nodos, las relaciones, las propiedades y las etiquetas (que definen el tipo de los nodos y las relaciones).
Es schemaless, por lo que varios nodos de un mismo tipo pueden tener diferentes propiedades. El hecho de ser
libres de esquema, no quita el hecho de que la estructura de los datos sea la protagonista del modelo.