Por qué los desarrolladores deberían usar bases de datos de gráficos

Hace veinte años, mi equipo de desarrollo creó un motor de procesamiento de lenguaje natural que escaneaba anuncios de empleo, automóviles y bienes raíces en busca de categorías de búsqueda. Sabía que teníamos un difícil desafío de gestión de datos. Los datos en algunos tipos de anuncios eran relativamente sencillos, como identificar marcas y modelos de automóviles, pero otros requerían más inferencias, como identificar una categoría de trabajo basada en una lista de habilidades.

Desarrollamos un modelo de metadatos que capturaba todos los términos de búsqueda, pero el motor de procesamiento del lenguaje natural requería que el modelo mostrara relaciones significativas de metadatos. Sabíamos que diseñar un modelo de metadatos con conexiones arbitrarias entre puntos de datos en una base de datos relacional era complejo, por lo que exploramos el uso de bases de datos de objetos para administrar el modelo.

Lo que intentábamos lograr en ese entonces con bases de datos de objetos se puede hacer mejor hoy con bases de datos de gráficos. Las bases de datos de gráficos almacenan información como nodos y datos que especifican sus relaciones con otros nodos. Son arquitecturas probadas para almacenar datos con relaciones complejas.

El uso de bases de datos gráficas ciertamente ha crecido durante la última década a medida que las empresas consideraban otras tecnologías NoSQL y big data. El mercado global de bases de datos de gráficos se estimó en $ 651 millones en 2018 y se pronosticó que crecerá a $ 3.73 mil millones para 2026. Pero muchas otras tecnologías de administración de big data, incluidas Hadoop, Spark y otras, han experimentado un crecimiento mucho más significativo en popularidad, adopción de habilidades, y casos de uso de producción en comparación con bases de datos de gráficos. En comparación, el tamaño del mercado de tecnología de big data se estimó en $ 36.8 mil millones en 2018 y se pronosticó que crecerá a $ 104.3 mil millones para 2026.

Quería entender por qué más organizaciones no están considerando las bases de datos de gráficos. Los desarrolladores piensan en objetos y usan representaciones de datos jerárquicas en XML y JSON con regularidad. Los tecnólogos y las partes interesadas del negocio entienden intrínsecamente los gráficos ya que Internet es un gráfico interconectado a través de hipervínculos y conceptos como amigos y amigos de amigos de las redes sociales. Entonces, ¿por qué más equipos de desarrollo no han utilizado bases de datos de gráficos en sus aplicaciones?

Aprender los lenguajes de consulta de las bases de datos de gráficos

Aunque puede ser relativamente fácil comprender el modelado de nodos y relaciones que se utilizan en las bases de datos de gráficos, consultarlos requiere aprender nuevas prácticas y habilidades.

Veamos ese ejemplo de cómo calcular una lista de amigos y amigos de amigos. Hace quince años, cofundé una red social de viajes y decidí mantener el modelo de datos simple almacenando todo en MySQL. La tabla que almacena una lista de usuarios tenía una autounión para representar amigos, y era una consulta relativamente sencilla para extraer la lista de amigos. Pero llegar a la lista de un amigo de un amigo requería una consulta monstruosamente compleja que funcionaba pero no funcionaba bien cuando los usuarios tenían redes extendidas.

Hablé con Jim Webber, científico jefe de Neo4j, una de las bases de datos de gráficos establecidas disponibles, sobre cómo construir una consulta de amigos de amigos. Los desarrolladores pueden consultar las bases de datos de gráficos de Neo4j utilizando RDF (Resource Description Framework) y Gremlin, pero Webber me dijo que más del 90 por ciento de los clientes utilizan Cypher. Así es como se ve la consulta en Cypher para extraer amigos y amigos de amigos:

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me f

RETURN f

A continuación, se explica cómo comprender esta consulta:

  • Búscame el patrón donde hay un nodo con la etiqueta Persona y un nombre de propiedad: 'Rosa', y vincúlalo a la variable "yo". La consulta especifica que "yo" tiene una relación de AMIGO saliente en profundidad 1 o 2 con cualquier otro nodo con una etiqueta de Persona, y vincula esas coincidencias a la variable "f".
  • ¡Asegúrate de que "yo" no sea igual a "f", porque soy amigo de mis amigos!
  • Devuelve todos los amigos y amigos de amigos

La consulta es elegante y eficiente, pero tiene una curva de aprendizaje para quienes están acostumbrados a escribir consultas SQL. Ahí radica el primer desafío para las organizaciones que se mueven hacia bases de datos de gráficos: SQL es un conjunto de habilidades omnipresentes, y Cypher y otros lenguajes de consulta de gráficos son una nueva habilidad para aprender.

Diseñar jerarquías flexibles con bases de datos de gráficos

Los catálogos de productos, los sistemas de gestión de contenido, las aplicaciones de gestión de proyectos, los ERP y los CRM utilizan jerarquías para categorizar y etiquetar la información. El problema, por supuesto, es que cierta información no es verdaderamente jerárquica, y los temas deben crear un enfoque coherente para estructurar la arquitectura de la información. Ese puede ser un proceso doloroso, especialmente si existe un debate interno sobre la estructuración de la información, o cuando los usuarios finales de la aplicación no pueden encontrar la información que buscan porque está en una parte diferente de la jerarquía.

Las bases de datos de gráficos no solo permiten jerarquías arbitrarias, sino que también permiten a los desarrolladores crear diferentes vistas de la jerarquía para diferentes necesidades. Por ejemplo, este artículo sobre bases de datos de gráficos puede aparecer bajo jerarquías en un sistema de gestión de contenido para la gestión de datos, tecnologías emergentes, industrias que probablemente usen bases de datos de gráficos, casos de uso de bases de datos de gráficos comunes o por roles de tecnología. Un motor de recomendaciones tiene un conjunto de datos mucho más rico para hacer coincidir el contenido con el interés del usuario.

Hablé con Mark Klusza, cofundador de Construxiv, una empresa que vende tecnologías para la industria de la construcción, incluida Grit, una plataforma de programación de la construcción. Si observa el cronograma de un proyecto de construcción comercial, verá referencias a múltiples oficios, equipos, piezas y referencias de modelos. Un solo paquete de trabajo puede tener fácilmente cientos de tareas con dependencias en el plan del proyecto. Estos planes deben integrar datos de ERP, Modelado de información de construcción y otros planes de proyectos y presentar vistas a los programadores, gerentes de proyectos y subcontratistas. Klusza explicó: “Al utilizar una base de datos de gráficos en Grit, creamos relaciones mucho más ricas sobre quién está haciendo qué, cuándo, dónde, con qué equipo y con qué materiales. Eso nos permite personalizar las vistas y pronosticar mejor los conflictos de programación de trabajos ".

Para aprovechar las jerarquías flexibles, ayuda a diseñar aplicaciones desde cero con una base de datos de gráficos. Luego, toda la aplicación se diseña en función de consultar el gráfico y aprovechar los nodos, las relaciones, las etiquetas y las propiedades del gráfico.

Las opciones de implementación en la nube reducen las complejidades operativas

La implementación de soluciones de administración de datos en un centro de datos no es trivial. La infraestructura y las operaciones deben considerar los requisitos de seguridad; revisar las consideraciones de rendimiento para dimensionar servidores, almacenamiento y redes; y también poner en funcionamiento sistemas replicados para la recuperación de desastres.

Las organizaciones que experimentan con bases de datos gráficas ahora tienen varias opciones en la nube. Los ingenieros pueden implementar Neo4j en GCP, AWS, Azure o aprovechar Aura de Neo4j, una base de datos como servicio. TigerGraph tiene una oferta en la nube y kits de inicio para casos de uso como Customer 360, detección de fraude, motores de recomendación, análisis de redes sociales y análisis de la cadena de suministro. Además, los proveedores de nube pública tienen capacidades de base de datos de gráficos, que incluyen AWS Neptune, la API de Gremlin en CosmoDB de Azure, JanusGraph de código abierto en GCP o las funciones de gráficos en Cloud Database Services de Oracle.

Vuelvo a mi pregunta original. Con todos los casos de uso interesantes, plataformas de bases de datos de gráficos maduras disponibles, oportunidades para aprender sobre el desarrollo de bases de datos de gráficos y opciones de implementación en la nube, ¿por qué no hay más organizaciones de tecnología que utilicen bases de datos de gráficos?