Bases de datos NO relacionales

En apartados anteriores, habíamos visto como las bases de datos relacionales supusieron la solución para el problema de redundancia que surgía cuando usábamos los ficheros planos para almacenar los datos. No obstante, las bases de datos relacionales presentaban otros problemas, y no tardaron en surgir otras alternativas de bases de datos que organizaban los datos de forma diferente, y que son conocidas en su conjunto como bases de datos no relacionales. En este post, recorreremos estas bases de datos, describiendo brevemente los distintos tipos y explicando como estructuran los datos para su almacenamiento.

La rigidez de las bases de datos relacionales

Al abandonar los ficheros planos y empezar a usar las bases de datos relacionales, solucionamos el problema de redundancia. Ya no teníamos que repetir datos en varias filas y además reducíamos sensiblemente el número de errores en la introducción de los datos, lo que obviamente redundaba en una notable mejora de la calidad de los mismos.

Sin embargo, la manera de estructurar los datos que proponen las bases de datos relacionales es muy rígida, obliga a emplear estructuras muy estrictas en las que manejamos un número fijo de campos que además tienen que almacenar datos de un determinado tipo. Esto hizo que empezaran a plantearse opciones más flexibles.

La primera demanda de una mayor flexibilidad a la hora de guardar los datos, vino con el auge de la programación orientada a objetos. En este tipo de programación, los programadores emplean Clases, una estructura de datos que representaban objetos reales y su comportamiento. Sin embargo, cuando queríamos guardar los datos al acabar de trabajar con el programa, había que traducir la estructura de datos de los objetos, a la de la base de datos relacional en la que fuéramos a guardarlos. Esta complicación es conocida con el nombre de problema de impedancia.

El problema de la impedancia

El problema de impedancia se produce cuando es complicado o laborioso hacer trabajar juntas a dos tecnologías condenadas a entenderse. Y este es el caso de la programación orientada a objetos y las bases de datos relacionales. Cuando ejecutamos un programa que tenga que recuperar datos guardados en una base de datos relacional, tenemos que acceder a ellos y transformar su estructura a la de los objetos del programa. Posteriormente, cuando hemos acabado de trabajar con el programa, tenemos que realizar la operación inversa para guardar los datos. Este proceso es laborioso y una fuente potencial de errores.

Surgieron entonces las bases de datos orientadas a objetos, el primer tipo de bases de datos no relacionales que trataremos. Sin embargo, en ese primer momento, la acogida de este tipo de bases de datos fue más bien escasa.

Posteriormente, la aparición de las páginas webs volvió a poner de moda este tema. Ahora se querían guardar las páginas de un sitio web y la estructura de las bases de datos relacionales resultaba tremendamente rígida. Una página web tiene una estructura de datos complicada con gran variedad de tipos y mucha libertad en el diseño. De nuevo, las bases de datos relacionales aguantaron el envite y siguieron empleándose ampliamente, tocaba transformar la estructura de los datos para almacenarlos. Las tecnologías de persistencias de datos seguían ganando la batalla.

No fue hasta la aparición del Big Data que las bases de datos NO relacionales empezaron a ganar terreno. El Big Data se identifica con tres características representadas por las famosas 3-V (Volumen, Variedad y Velocidad), me refiero a las tres primeras, luego se han ido añadiendo más “V”.

Las bases de datos relacionales pueden lidiar relativamente bien con el tema del volumen, pero su estructura tan rígida lo tiene complicado con la Variedad de los datos y la Velocidad. Con todo, y aunque las bases de datos relacionales han perdido algo de terreno en los últimos años, siguen siendo profusamente usadas, manteniendo el liderato, al menos de momento.

Tipos de bases de datos NO relacionales

Es muy probable que a menudo oigas hablar de las bases de datos NoSQL para referirse en realidad a las bases de datos NO relacionales. Se emplea ese término porque se asocia muy estrechamente SQL a las bases de datos relacionales, sin embargo, esto no es correcto, podemos encontrar bases de datos relacionales que utilizan otros lenguajes diferentes a SQL y que por tanto son NoSQL pero relacionales.

Por ello, utilizaré el término NO relacionales en lugar de NoSQL, para referirme a las bases de datos que no siguen la estructura relacional propuesta por Codd. Sencillamente me parece más correcto.

Entre este tipo de bases de datos encontramos:

• Clave-valor
• Orientadas a documentos
• Orientadas a columna
• Orientadas a grafo

Clave-valor

Estas BBDDs No relacionales son las más sencillas de todas. Una BBDD clave-valor puede verse como una lista de parejas, en la que tenemos claves emparejadas a valores de manera unívoca, es decir, a cada clave le corresponde un único valor y sólo uno.

Quizás otra representación de este tipo de BBDDs que puede resultar útil para entenderlas, es la de una tabla de dos columnas, en la primera tengo la clave y en la segunda el valor:

La sencillez de la estructura, propicia al mismo tiempo su principal ventaja e inconveniente. Estas BBDDs son tremendamente rápidas en las búsquedas, si la comparáramos con las relacionales es como si tuviéramos todos los datos indexados con un índice denso. Sin embargo, al mismo tiempo, los datos que podemos guardar, responden a una estructura muy simple, que en algunas ocasiones puede no ser suficiente para cubrir nuestros requerimientos.

Los valores que almacenamos, pueden ser cualesquiera: fotografías, documentos, audios…. Esto hace la BBDD muy potente cuando queramos manejar gran cantidad de datos, que al mismo tiempo sean pesados, con una estructura muy simple y con necesidades de acceso rápido y simultaneo de varios usuarios. Podríamos estar hablando de una galería de videos, por ejemplo.

Algunos de los ejemplos más populares de estas BBDDs serían:

• Cassandra: Escalable linealmente y con soporte multi data center. Originaría de Facebook aunque luego se convirtió en un proyecto de open source que tomo la fundación Apache.
• Big Table: Creada por Google, es una BBDD distribuida, de alta eficiencia. Tiene una baja latencia y alta escalabilidad, por lo que Google la recomienda para aplicaciones IoT. Pero, es propietaria y utiliza tecnologías propietarias de Google como GFS (Google File System).
• Dynamo DB: La solución de Amazon, que ofrece a las empresas a través de los servicios en la nube AWS. Rendimiento altísimo, escalabilidad a tope y manejo de cantidades ingentes de datos.
• Redis: Otra solución open source que está teniendo bastante aceptación.

Orientadas a documentos

Al contrario que las BBDDs clave – valor que buscan la sencillez y rapidez en la recuperación de datos, en una BBDD orientada a documentos podemos manejar estructuras de datos muy complicadas. Manejaremos documentos que agrupamos en colecciones, si intentáramos establecer alguna analogía con las bases de datos relacionales, un documento sería equivalente a un registro y una colección a una tabla.

Mientras en una base de datos relacional, la estructura de los registros es exactamente la misma para todos, y se compone de una serie de campos, en una base de datos orientada a documentos esta estructura puede variar notablemente de unos documentos a otros. En realidad son agregados, un documento puede incluir a otros, y al final estamos manejando una serie de datos que son presentados o agrupados de distintas formas en distintos documentos.

Utilizando el ejemplo de la tienda de nuestro amigo Antonio, en el que habíamos visto una posible implementación en una BBDD relacional. La implementación en una BBDD orientada a documentos podría tener el aspecto representado en la figura siguiente:

Tendríamos una colección de documentos en los que manejaríamos distintos datos, agrupados de distintas maneras.

De entre las BBDDs orientadas a documentos, destaca MongoDB, especialmente pensada para Big Data. En mi opinión, también merecen mención BaseX y CouchDB:

• MongoDB: BBDD orientada a documentos que está distribuida en la nube. Una de las más populares, sino la más popular. Te permite empezar a trabajar con una versión gratuita que tendrás que extender a una de pago, cuando empieces a requerir un uso más intensivo de los recursos y quieras un cluster dedicado.
• BaseX: BBDD Open Source basada en XML, por lo que se adapta muy bien al diseño de aplicaciones web.
• CouchDB: BBDD de código abierto de la fundación Apache especialmente orientada al desarrollo web. Emplea el formato JSON para el almacenamiento de datos.

Orientadas a columna

Las BBDDs orientadas a columna, conocidas también como de columnas anchas, tienen una estructura similar a la Tabla de una BBDD relacional. La diferencia sobre aquellas estriba en que  agrupan las columnas por familias que permiten acceder a ellas de una manera más rápida y eficiente.

La idea de este tipo de BBDDs surge al observar las consultas en BBDD relacionales, donde es muy habitual que ciertos datos se recuperen de forma conjunta. Se trata de datos relacionados que normalmente querremos recuperan en bloque.

Aplicando esto a la BBDD de proveedores de Antonio y de su comercio Gades, una posible comparativa entre ambas estructura, la relacional y la orientada a columna, sería la siguiente:

Según la figura anterior, los datos de proveedor: nombre, contacto y teléfono, serían datos relacionados que cuando queremos recuperarlos normalmente lo haremos en bloque, es decir, recuperándolos todos. Por ello, los agrupamos en una super columna que llamamos “Datos de proveedor”. No estamos limitados a dos niveles de columnas, podemos tener varios.

Entre las bases de datos orientadas a columna, destaca HBase: Proyecto gestionado por la fundación de software Apache, dentro del proyecto Hadoop. De este último proyecto, hablaremos más adelante, pero de momento baste con saber que se trata de una solución para trabajar con aplicaciones y datos distribuidos en un entorno de Big Data.

Orientadas a Grafo

Una forma muy habitual de presentar datos es mediante un grafo. En los nodos del mismo estaría la información, y las flechas que conectan unos con otros representarían las relaciones. Las BBDDs orientadas a Grafo están especialmente diseñadas para manejar este tipo de estructuras de datos.

Un ejemplo muy habitual para explicar este tipo de BBDDs es el de un mapa de carreteras. Imaginemos que las ciudades del mapa son los nodos del grafo y las carreteras, las relaciones entre los nodos, que en este caso guardan el dato de distancia entre ambas ciudades. Podemos tener varias relaciones entre varios nodos, podemos disponer distintas carreteras para movernos de una ciudad a otra.

Esta representación se podría llevar a cabo con una BBDD relacional, podríamos emplear tres campos por registro: ciudad origen, ciudad destino, distancia. Y podríamos tener varios registros para cada combinación de ciudad origen y ciudad destino, ya que tendríamos distintas distancias dependiendo de las carreteras que empleáramos.

Sin embargo, el problema lo tenemos cuando queremos trabajar con los datos. Si por ejemplo quisiéramos calcular la distancia entre Gijon y Cadiz, tendríamos que recorrer el grafo, de una ciudad a otra, calculando la distancia total. Realizar estos cálculos con una BBDD relacional es una pesadilla, probablemente uno de los principales puntos débiles de las BBDD relacionales sea el recorrido de grafos. También resulta inmanejable registrar todas las combinaciones posibles para todas las ciudades.

Y os preguntareis, para que tipo de aplicaciones sirven este tipo de BBDDs. Para todas aquellas que manejen datos en estructuras de Grafo, un ejemplo son las empresas que trabajen con Navegadores, como el caso de Tom-Tom. También los recomendadores basados en relaciones de redes sociales o de cualquier otro tipo de red de contactos, sacan claro provecho del uso de este tipo de BBDDs.

Por ejemplo, Si fuéramos una agencia de viajes y quisiéramos recomendar un viaje, probablemente pediríamos al usuario que se diera de alta usando su cuenta de Facebook, y que nos diera acceso a sus contactos. Entonces, recorriendo el grafo que forman sus contactos y los contactos de sus contactos, veríamos que tipo de viajes consume su red y podríamos hacerle una recomendación al usuario.

Probablemente, la BBDD más conocida de este tipo es Neo4j

NOTA:

Este post es parte de la colección “Sistemas de acceso y almacenamiento de datos”. Puedes ver el índice de esta colección aquí.