Cuándo utilizar una base de datos de grafos como Neo4j

Una base de datos de grafos representa los datos como nodos (entidades) y aristas (relaciones entre entidades). Cada arista es un objeto de primer nivel con un tipo y sus propias propiedades. A diferencia de las bases de datos relacionales o de documentos, en las que las relaciones se sobreentienden mediante claves externas o referencias incrustadas, las bases de datos de grafos almacenan las relaciones como conexiones explícitas, con un recorrido O(1) por salto: seguir una relación requiere un tiempo constante independientemente del tamaño de la base de datos.

Las bases de datos de documentos y relacionales están optimizadas para encontrar entidades: obtener un usuario por su ID o consultar pedidos por estado. Tienen dificultades para recorrer relaciones: «encontrar todos los amigos de los amigos de Alice que compraron el mismo producto que Alice durante el último mes». Cada salto requiere un $lookup o un JOIN. Tres saltos de profundidad implican tres uniones anidadas. Con 10 saltos a través de millones de nodos, el rendimiento de MongoDB se degrada exponencialmente, mientras que el de Neo4j se mantiene estable.

Neo4j es la base de datos de grafos más popular y utiliza el lenguaje de consultas Cypher, un lenguaje declarativo basado en patrones para recorrer grafos. Una consulta de Cypher describe el patrón del grafo que busca mediante una notación de arte ASCII: nodos en () y relaciones en -[]->. El motor de consultas encuentra de forma eficiente todos los subgrafos que coinciden con el patrón mediante adyacencia nativa sin índices.

Los sistemas de recomendación dependen del recorrido de redes de relaciones: «los usuarios que compraron lo mismo que usted también compraron X». En un grafo, cada compra es una arista entre un nodo de usuario y un nodo de producto. Encontrar recomendaciones mediante filtrado colaborativo requiere un recorrido de 2 saltos: Usuario → Producto → (otros usuarios que compraron ese producto) → (otros productos que compraron esos usuarios). Neo4j gestiona millones de estos recorridos por segundo. $graphLookup de MongoDB puede hacerlo, pero su rendimiento se degrada a gran escala.

Las redes de fraude suelen implicar información de identidad compartida: varias cuentas que comparten el mismo ID de dispositivo, número de teléfono, dirección IP o dirección de facturación. Las bases de datos de grafos son excelentes para detectar estas redes recorriendo sus relaciones: «encontrar todas las cuentas conectadas a esta cuenta sospechosa mediante atributos compartidos en un máximo de 3 saltos». La puntuación de fraude en tiempo real durante una transacción —consultar un grafo con millones de entidades conectadas en milisegundos— es una fortaleza nativa de Neo4j que MongoDB no puede igualar.

Un grafo de conocimiento modela entidades y sus relaciones semánticas, como la información de Wikipedia estructurada en forma de grafo. Los grafos de conocimiento impulsan el reconocimiento de entidades en los motores de búsqueda, las respuestas basadas en hechos de los asistentes de IA y las ontologías empresariales. El modelo de grafo encaja de forma natural: Persona conoce a Persona, Persona trabajaEn Empresa, Empresa estáUbicadaEn Ciudad, Ciudad esCapitalDe País. Recorrer estas cadenas semánticas es precisamente para lo que están diseñadas las bases de datos de grafos.

No todos los problemas de grafos requieren Neo4j. $graphLookup de MongoDB gestiona razonablemente bien los recorridos de árboles y grafos en los siguientes casos: jerarquías poco profundas (menos de 5 o 6 saltos); grafos de tamaño moderado (desde miles hasta unos pocos millones de nodos); y consultas de recorrido poco frecuentes que pueden tolerar una latencia mayor. Si las consultas de grafos son una funcionalidad secundaria de una aplicación basada principalmente en datos de documentos, mantenerlo todo en MongoDB simplifica considerablemente la pila.

Elija Neo4j (u otra base de datos de grafos) cuando los recorridos profundos de varios saltos sean una funcionalidad esencial (redes sociales, grafos de conocimiento, detección de fraude); la propia relación contenga propiedades complejas (por ejemplo, una arista FOLLOWS que almacene cuándo se produjo el seguimiento y si es mutuo); las consultas de grafos deban devolver resultados en tiempo real con alta concurrencia; o todo el dominio se centre en las relaciones y no en las entidades. Para redes sociales, grafos de identidad, topologías de red y grafos de dependencias, recurra a Neo4j.

Muchos sistemas grandes utilizan persistencia políglota: distintas bases de datos para distintas necesidades. Una plataforma social podría almacenar los perfiles de usuario y las publicaciones en MongoDB (consultas enriquecidas sobre documentos), los grafos de amistades e intereses en Neo4j (recorridos rápidos), los datos de sesión en Redis (búsquedas en menos de un milisegundo) y los análisis en un almacén columnar. Cada base de datos hace aquello para lo que está mejor preparada. La complejidad reside en gestionar la consistencia entre sistemas, pero las mejoras de rendimiento y escalabilidad suelen justificarla.

En MongoDB, una relación social se modela como un documento en una colección follows con los campos followerId y followeeId. En Neo4j, es una arista FOLLOWS que conecta directamente dos nodos User. El modelo de grafo elimina la colección intermedia y permite recorrer el grafo directamente mediante punteros. El modelo de documentos es mejor para obtener los datos del perfil del usuario; el modelo de grafo es mejor para recorrer sus conexiones sociales.

Las aristas de los grafos en Neo4j tienen un tipo (similar a una etiqueta) y pueden tener propiedades. Un grafo social podría tener tipos de arista FOLLOWS, LIKES, PURCHASED y REVIEWED, cada uno con sus propias propiedades. Las consultas de Cypher pueden coincidir por tipo de arista y filtrar por sus propiedades, lo que permite realizar consultas de relaciones enriquecidas. Esto resulta mucho más natural que almacenar un campo type en una colección relationships de MongoDB y hacer una unión sobre él.

En esta lección ha aprendido que las bases de datos de grafos como Neo4j destacan en los recorridos profundos de relaciones de varios saltos —motores de recomendación, detección de fraude y grafos de conocimiento—, donde las cadenas de $lookup de MongoDB se degradan exponencialmente; que el lenguaje Cypher de Neo4j expresa patrones de grafos de forma declarativa, de un modo que ningún lenguaje de consultas de documentos puede igualar; y que la persistencia políglota, usando MongoDB para los datos de documentos y Neo4j para recorrer relaciones, es un patrón habitual en producción. A continuación, abordaremos el proyecto final: diseñar la arquitectura de una aplicación MongoDB lista para producción.