Una visión holística del uso combinado de bases de datos relacionales y NoSQL

Durante muchos años el mundo de las bases de datos ha estado dominado por las bases de datos relacionales. Aunque han existido desde siempre otras alternativas, las bases de datos relacionales han sido las reinas del lugar. En el fondo, todavía son, seguramente, las más preponderantes.

Sin embargo, algunos fenómenos de los últimos años, la hiper-abudancia de datos con fuentes como social media o Internet de las cosas, la importancia de los datos no estructurados y la eclosión del Big Data, han hecho que ganen relevancia otras formas de gestionar los datos más aptos para ese tratamiento masivo de datos no estructurados.

Constituyen lo que, de forma resumida, se denominan bases de datos NoSQL, cuya implementación no sigue el esquema de tablas propio de las relacionales y que ofrecen otras formas de consulta en paralelo o alternativo al uso de SQL.

Hay una gran variedad de ellas: repositorios atributo-valor, bases de datos columnares, bases de datos de grafos, bases de datos documentales, etc Las bases de datos NoSQL no son, por tanto, una solución única sino una variedad de opciones más adecuadas o menos según el caso.

He estado leyendo recientemente el libro 'SQL and NoSQL databases: Models, Languages, Consistency Options and Architectures for Big Data Management' de Andreas Meier y Michael Kaufmann, un libro muy ordenado y riguroso.

En el libro desarrollan muy bien la parte más teórica sobre gestión de datos, modelado, lenguajes de consulta, etc.

Sin embargo, lo que quería traer a este post es algo más simple, pero quizá más ilustrativo. Se trata de un ejemplo que proponen bastante avanzado el libro sobre la combinación de varias de estas tecnologías de bases de datos para soportar distintos tipos de informaciones en el caso de una tienda en la web.

El ejemplo se recoge en la figura, tomada del libro:

En ella se puede observar el uso de cinco tecnologías diferentes:

• Bases de datos relacional: el modelo más tradicional para almacenar la información estructurada disponible sobre clientes, cuentas, transacciones, etc


• Almacenes atributo-valor: para el almacenamiento de datos más transitorios como el carrito de la compra o las sesiones y pensando, sobre todo, en la alta disponibilidad.


• Bases de datos documental: para almacenar pedidos, entendiendo que el cuerpo de éstos podrían estar contenido, por ejemplo, en documentos XML o JSON o quizá, incluso, en PDF.


• Bases de datos de grafo: para el tratamiento de información procedente de medios sociales como, por ejemplo, debates en blogs o hilos en twitter. 


• Bases de datos en memoria: para la parte analítica se propone un datawarehouse complementado con herramientas especializadas de data mining o análisis predictivo. Para mejorar las prestaciones en el análisis de esos datos, se propone mantener la información en memoria.

Finalmente, y aunque no se aprecia en la figura, los autores proponen, a modo de ejemplo, y de cara a la integración, el uso de una arquitectura REST. 

La verdad es que parece un esquema un poco de laboratorio o, mejor dicho, de libro o Powerpoint. Es difícil imaginar que en una solución real se mezclen cinco tecnologías de bases de datos por más que, individualmente, cada una pueda ser óptima para una de las labores descritas.

Sin embargo, me gusta por lo ilustrativo y panorámico que resulta, porque ayuda a entender y recordar... y por eso he querido dejarlo consignado en este post.