Aquel que tiene un martillo en la mano cree que todo son clavos … o de cómo llevamos años usando las bases de datos relacionales masivamente sin evaluar alternativas

Si, es cierto, el ser humano trata de ponerse las cosas fáciles a él mismo, así que en cuanto se le presenta un problema y lo analiza, si alguna de las herramientas que tiene alrededor le sirve mínimamente ya está, solucionado! Golpe de martillo y a otra cosa!

En este sentido, durante más de 20 años las Bases de Datos relacionales han sido la base sobre la que se han edificado los sistemas de información de las empresas.

Ya fueran bases datos corporativas tipo Oracle, DB2 o SQLServer, o más departamentales como MySQL o Postgress, durante todos estos años, siempre que aparecía la necesidad de crear un aplicativo nuevo, la única discusión era saber exactamente qué Base de Datos relacional íbamos a poner, pero no había ninguna discusión sobre si esta era la mejor solución.

Así, cuando aumentaban los requerimientos de velocidad, o la cantidad de datos almacenados, los problemas se solventaban a base de más hardware o poniendo una BD más corporativa.

Y Entonces llegó Big Data …

La explosión en el volumen de datos gestionados ha revolucionado el mundo, y los departamentos de información acaban de darse cuenta que aparte de un martillo tienen un destornillador plano uno de estrella, una llave fija, una hallen, una llave inglesa, tuercas, tornillos y todo un sinfín de herramientas a su disposición, así que por fin pueden dejar de martillear todo como si fueran clavos.

Y digo que esto lo ha provocado la irrupción del Big Data porque gran parte de estas tecnologías emergentes ya existían, pero nadie les hacía caso, ya sea por desconocimiento o por la típica aversión al cambio que tiene el ser humano.

NoSQL: BD de grafos

En este sentido, las bases de datos NoSQL y en particular las BD de grafos están cambiando la manera en que definimos las aplicaciones. Cuando aparece un nuevo requerimiento del negocio, el arquitecto de la solución se pregunta:

• ¿Cuál es la mejor manera de almacenar estos datos?
• ¿Qué necesidades de integración tenemos?
• ¿Qué requisitos de tiempo de respuesta requiere el servicio?

Está claro que no es lo mismo tener 1000 registros que 100.000.000 registros. Y tampoco es lo mismo un sistema bancario que una red social. Lo que quiero decir con eso es que la naturaleza de los datos es importante, no solamente la cantidad de ellos. En una red social, las relaciones entre los datos lo son todo, y es en casos como ese cuando las Bases de Datos de Grafos obtienen el mayor rendimiento.

¿Cuándo tiene sentido usa Base de Datos de Grafos?

Aún sin ser una ciencia exacta, existen varias pistas que nos indicarán que es posible que estemos necesitando una BD de Grafos para resolver un problema. Las siguientes líneas contienen frases que posiblemente nos sean familiares, así que adelante con ellas:

• Mi BD relacional no es capaz de responder a tiempo, no paramos de crecer en datos y las consultas no responden en menos de 1 segundo. Ya hemos aumentado el HW dos veces, y esto no parece tener remedio ni así.
• Tengo un set de datos grande y muy interrelacionado. Es para crear un sistema tipo red social que ser capaz de responder preguntas complejas sobre las relaciones entre los usuarios.
• Necesito Tiempo Real!!! los clientes se conectan a la tienda online pero marchan porque el tiempo de respuesta no es satisfactorio.
• Por casualidad he detectado que hay algunos usuarios de mi sistema de e-commerce que hacen un uso fraudulento del mismo, ya que tienen cuentas creadas como usuario particular pero por su comportamiento son una empresa. ¿Puede ser que haya más casos como este?
• Necesito realizar consultas del estilo: ¿Cuál es la distancia mínima entre …
  • estos dos puntos?
  • estas dos personas de la red social?
  • estos dos puntos de red? si bajo este Switch, ¿qué sistemas se ven desconectados?¿Existe camino anternativo?