Este post está enfocado desde la tecnología. ¿Formas parte en un departamento de tecnología de una compañía?, eres CIO, Jefe de proyectos, o administrador de bases de datos, o desarrollador Java … no importa, las razones que ponemos aquí las entenderás y seguramente te ssentirás identificado con alguna de ellas.

Los grafos están empezando a formar parte del ecosistema de bases de datos NoSQL. De hecho son uno de los que más suben en el ranking (http://db-engines.com/en/ranking) y encontramos a Neo4j en las posiciones delanteras (pos 21 a esta fecha) de una lista que incluye auténticos gigantes super establecidos como Oracle, DB2 o MySQL.

Pero ¿qué está haciendo que el uso de los grafos esté creciendo tanto? ¿Cuales son las palancas que llevan a los departamentos de IT a implantar estas soluciones? ¿qué esperan las áreas de negocio de aplicar una tecnología como esta? Nuestra experiencia nos dice que no hay una única respuesta a esta pregunta, pero sí podemos identificar algunos de los indicios que llevan a las organizaciones a implantar una base de datos de grafos.

1 – En la casa sólo tenemos bases de datos relacionales

Pues si, si sabes que en tu organización sólo se usan BD relacionales, ya sean comerciales como Oracle o SQLServer o de código abierto como MySQL o Postgress, seguro que estáis perdiendo oportunidades de mejora del negocio.

Como dijimos en nuestro post, estas BBDD no sirven para todo, así que del mismo modo que el ERP y la Web están sobre servidores de aplicación diferentes porque tienen requisitos diferentes, con las BBDD de soporte ocurre lo mismo. Lo dicho, es un síntoma claro que se hay que mirar más allá.

Modelo Relacional

Modelo en Grafo

2 – BD Denormalizada para mejorar el rendimiento

Esto empezó básicamente para entornos informacionales. Los arquitectos de Data Warehouses y Data Marts se dieron cuenta que es mejor generar una tabla agregada con los totales de venta mensual que no hacer que la BD se recorra la tabla con el detalle de la venta para acumular el resultado cada vez que alguien ejecuta un informe de ventas mensuales. Esto ha generado BD relacionales muy denormalizadas.

Ahora, en sistemas como las redes sociales o los sistemas de recomendación, el problema vuelve a reproducirse, pero esta vez además en un entorno mucho más crítico para el negocio. Crear tablas agregadas/calculadas con datos como los productos recomendados calculados en batch, o el número de amigos de una personas son solo un “parche” que hacemos por no implementar una solución basada en grafos.

3 – Te piden Tiempo Real … si o si

Un día llegas a una reunión con el área de Marketing. Tienen un nuevo proyecto encima de la mesa, conseguir que los usuarios que se conectan mediante el canal Web tengan una experiencia personalizada. Tú miras internamente y te das cuenta que el Oracle sobre el que está soportado todo el sistema es incapaz de contestar las preguntas que exige esta nueva iniciativa con los tiempos requeridos por un sistema transaccional. ¿Qué haces?

• a) Dices que es imposible. Tu cliente, el área de marketing sigue pensando que IT no le ayuda
• b) Exploras nuevas posibilidades. ¿Por qué no usar una BD NoSQL para esta iniciativa? y obviamente incluyes a Neo4j como opción preferente para las BD de grafos

Obviamente la respuesta correcta es la b), era fácil no?

4 – No te planteas otra cosa que no sea una BD relacional

Esta es seguramente la razón principal, lo hemos hecho toda la vida. “Tenemos que construir un sistema de tienda onLine … bla bla bla” dice el director de Ventas. Y tú, mentalmente ya estás dibujando un precioso cilindro que representa una BD Oracle o MySQL o Microsoft … la que sea corporativa en tu organización. Normalmente ni siquiera se te ocurre que puedan haber otras alternativas mejores a esta que ha funcionado “toda la vida”.