Las mejores bases de datos de grafos para detección de fraude

El rey de la categoría. La función que sienta a Neo4j en el trono de esta lista es la librería Graph Data Science, y para el trabajo antifraude fue lo más útil que probó nuestro equipo entre los ocho motores. En vez de escribir a mano la lógica de recorrido para hallar clústeres sospechosos, nuestros analistas invocaron un algoritmo de detección de comunidades directamente sobre el grafo cargado, y aisló en una sola pasada los anillos sembrados de cuentas que compartían huella de dispositivo. La puntuación de centralidad ordenó después qué cuentas se sentaban en el centro de cada anillo. Eso convierte la detección de fraude en una tubería de puntuación, que es justo lo que quiere un equipo de ciencia de datos.

Cypher es la otra razón de su puesto. Es un lenguaje declarativo de coincidencia de patrones, y el patrón que escribes en pantalla imita la forma del fraude que persigues: unas líneas describen cuentas ligadas a un dispositivo compartido ligado a una dirección compartida. Cuando cargamos el conjunto de dos millones de cuentas y pedimos cada cuenta a seis saltos de una mula conocida, la consulta se leía como una frase, no como un bucle anidado. Neo4j creó Cypher, hoy es un estándar abierto, y esa legibilidad explica por qué la cantera de talento es la mayor de la categoría. Contratar aquí a un ingeniero de grafos que ya conoce el lenguaje es de verdad más sencillo que en cualquier otro sitio de esta lista.

Alrededor del núcleo, el ecosistema trabaja de lo lindo. AuraDB, el servicio gestionado en la nube, eliminó la operación del clúster por completo durante las pruebas: levantamos una instancia alojada y estábamos consultando en minutos, sin infraestructura que afinar. La documentación es la más profunda del campo y la comunidad es tan grande que casi cualquier duda de modelado de fraude ya tiene respuesta en algún rincón.

Los costes son concretos y toca decirlos claros. Las licencias Enterprise y las gamas Graph Data Science suben rápido en cuanto abandonas la edición gratuita, y en un despliegue grande la factura se convierte en una partida seria. La Community Edition es de verdad limitada: sin clustering, sin copias en caliente, sin control de acceso por roles, lo que la descarta para casi cualquier sistema antifraude en producción. Y el escalado de escrituras es su debilidad estructural. Si tu grafo de transacciones se dispara a los billones de aristas con mucha escritura, un motor shared-nothing pensado para esa escala lo adelantará. Para los equipos de ciencia de datos de fraude y riesgo a los que apunta, nada de eso cambia la recomendación. Es la opción por defecto, y se la gana con creces.

Profundidad contra librería. Donde Neo4j te da una librería de ciencia de datos, TigerGraph te da profundidad de recorrido en bruto, y ese es el marco de toda esta reseña. La fuerza de Neo4j es puntuar clústeres que un analista ya ha sacado a la luz. La fuerza de TigerGraph es responder la pregunta profunda lo bastante rápido para que la respuesta llegue antes de que el pago se liquide. En nuestra prueba la diferencia asomó pasado el cuarto salto. Cuando empujamos el mismo patrón de anillo de fraude de cuatro a seis saltos, los motores superficiales doblaron la latencia hacia arriba mientras TigerGraph se mantuvo casi plano. No es un eslogan: es lo que el motor de procesamiento masivamente paralelo está construido para hacer, repartiendo un único recorrido por la capa de almacenamiento y de cómputo para que la profundidad deje de ser el enemigo.

Para una red de tarjetas que puntúa una transacción mientras se autoriza, esa planitud es toda la propuesta de valor. Recorrimos usuarios, tarjetas, dispositivos y comercios para marcar si una transacción en vuelo conectaba con un anillo de fraude conocido, y la consulta volvió dentro de la ventana que da un pago real. La misma arquitectura sirve al trabajo antiblanqueo, donde un investigador mapea flujos de fondos por muchas cuentas intermediarias para destapar patrones de estratificación, y los recorridos superficiales sencillamente no llegan tan lejos.

GSQL es el segundo diferenciador de TigerGraph y su coste más empinado. Es un lenguaje de consulta y procedimientos Turing-completo, lo que significa que la analítica de puntuación basada en acumuladores corre dentro de la base y no en un servicio externo que trasiega datos de un lado a otro. Durante las pruebas codificamos una rutina de puntuación de fraude directamente en GSQL y la ejecutamos in situ. El pero es la curva de aprendizaje. GSQL no se parece en nada a Cypher, y nuestro equipo dedicó tiempo de verdad a soltarse antes de que la potencia rindiera. Sumado a una comunidad más pequeña y a la pericia de infraestructura que exige un clúster distribuido, TigerGraph le encaja mal a un equipo chico que quiere estar consultando el viernes. Para una gran entidad financiera que puntúa transacciones a volumen, es el motor más rápido de aquí a las profundidades que importan.

Para los que ya viven en AWS. Si tu equipo de ingeniería ya habita dentro de AWS, Neptune es el camino de menor resistencia, y esa es la lente de toda esta reseña. Para un marketplace que enlaza cuentas, métodos de pago y direcciones de envío para detectar vínculos con fraude conocido, el atractivo no es un algoritmo estrella: es que no hay clúster que operar. Durante las pruebas aprovisionamos una instancia, dejamos que IAM gestionara la autenticación, mantuvimos el tráfico dentro de la VPC y no tocamos ni un script de copia porque Neptune las vuelca a S3 de forma automática. Para una casa centrada en AWS, esa eliminación del trabajo operativo es la razón entera para elegirlo.

El soporte de tres lenguajes ayuda de verdad a migrar. Neptune habla Gremlin, openCypher y SPARQL, de modo que un equipo que llega desde un motor de grafo de propiedades puede traer sus consultas openCypher con reescritura mínima, y un equipo orientado a RDF puede usar SPARQL contra el mismo almacén. Lanzamos nuestros recorridos de anillos de fraude en openCypher y volvieron con latencia de milisegundos en los patrones de profundidad baja a media que suelen necesitar los grafos de identidad y de fraude de marketplace. El escalado de lecturas con réplicas y la disponibilidad multi-AZ estuvieron sólidos en toda la prueba.

Dos limitaciones deciden si Neptune encaja. La primera: corre solo dentro de AWS. Si la portabilidad entre nubes o un requisito on-premise asoma en tu futuro, Neptune es la elección equivocada, sin matices. La segunda: no trae librería de ciencia de datos de grafos, así que la detección de comunidades y la puntuación de centralidad que venían gratis en Neo4j hay que construirlas o ejecutarlas en otra parte para Neptune. Añade el techo de escritura de una sola primaria, que limita el escalado con mucha escritura, y el perfil queda claro: Neptune es excelente para equipos de AWS que quieren grafos de identidad y fraude gestionados con lenguajes familiares, y encaja mal con quien necesite portabilidad o puntuación de fraude dentro de la base.

El evento que apareció al instante. Cuando abrimos un feed de Kafka en vivo con transacciones simuladas hacia Memgraph, una cuenta mula nueva asomó en los resultados del recorrido casi en el mismo instante en que el evento aterrizó. Esa sola prueba resume por qué existe Memgraph. Sus conectores de streaming nativos consumen Kafka, Pulsar o Redpanda de forma directa, de modo que el grafo nunca es una foto del lote de anoche: refleja el pago que se liquidó hace cuatro segundos. Para la detección de fraude que debe actuar sobre los eventos según ocurren y no en un barrido nocturno, esa actualización continua es la clave.

La velocidad nace de mantener el grafo de trabajo en RAM. El motor de almacenamiento en C++ de Memgraph guarda los datos calientes en memoria y entregó recorridos sub-milisegundo en nuestras consultas de detección de anillos, con holgura más rápido que los motores en disco sobre los mismos patrones. Y como habla Cypher, el mismo lenguaje que usa Neo4j, nuestro equipo reutilizó el conocimiento de consultas directamente y fue productivo sin aprender una sintaxis nueva. Una plataforma de pagos que ingiere transacciones en streaming y puntúa patrones de anillo con cada evento es el encaje de manual.

La memoria es también la restricción que define el techo de Memgraph. El coste de RAM escala en línea con el tamaño del grafo, así que un grafo que crece a las decenas de miles de millones de aristas convierte la memoria en la partida presupuestaria que ata, algo que un motor en disco evita. Pasa de la memoria disponible y entras en configuración de nivel de almacenamiento que te devuelve la ventaja de velocidad en memoria por la que compraste el producto. El ecosistema y las herramientas también son más delgados que los de Neo4j. Para un equipo antifraude que vive del streaming, necesita detección en vivo y puede dimensionar su grafo caliente para que quepa en RAM, Memgraph es el mejor motor en tiempo real de esta lista. Para un grafo persistente muy grande con presupuesto fijo, es la herramienta equivocada.

Todo en un mismo sitio. La función que define a ArangoDB es su núcleo multimodelo, y para la investigación de fraude resuelve un problema concreto y molesto: las relaciones y los atributos ricos suelen vivir en dos bases de datos distintas. ArangoDB guarda grafo, documento JSON y clave-valor en un solo motor, y una única consulta AQL puede recorrer las relaciones entre cuentas mientras filtra por los campos de documento que se sientan en esos mismos registros. Durante las pruebas nuestros analistas caminaron un clúster sospechoso y lo filtraron por antigüedad de la cuenta e importe de la transacción en una sola consulta, sin un viaje de ida y vuelta a un almacén de documentos aparte para enriquecer los resultados.

AQL es lo que hace que eso funcione. Es un lenguaje al estilo SQL que expresa juntos los recorridos de grafo y los filtros de documento, así que una investigación que necesita contexto de relaciones y detalle de atributos no se abre en abanico entre sistemas. Para un equipo con un esquema que cambia rápido, mantener grafo y documento en el mismo motor también significa que el modelo puede moverse sin migrar entre dos almacenes. En el frente operativo, ArangoGraph ofrece una opción gestionada en la nube, y el sharding SmartGraphs coloca juntos los vértices relacionados para recorridos distribuidos más rápidos.

ArangoDB paga su flexibilidad en velocidad de recorrido pico. Un motor de grafo nativo y dedicado le pasará por encima en consultas muy profundas y de muchos saltos, y en nuestra prueba de anillo a seis saltos quedó por detrás de los especialistas. El potente sharding SmartGraphs vive tras la gama enterprise de pago, así que la historia de rendimiento distribuido exige licencia. No es el motor para un equipo cuyo único trabajo es la puntuación de fraude por enlace profundo. Es la elección pragmática para un equipo antifraude que quiere relaciones y atributos en un mismo sistema y valora no operar dos bases de datos por encima del último incremento de velocidad de recorrido.

Cuando el grafo ya no cabe. Si tu grafo de transacciones ha desbordado lo que aguanta un solo servidor, NebulaGraph está hecho justo para tu problema. Este es el motor para organizaciones cuyos grafos de fraude o sociales se van a los miles de millones de vértices y billones de aristas, donde la pregunta ya no es cuán profundo llega un recorrido sino si el grafo cabe siquiera. Su arquitectura shared-nothing significa que añadir un nodo aumenta capacidad y rendimiento a la vez sin reescribir el diseño de almacenamiento ni el código de la aplicación. Cuando añadimos un nodo a mitad de prueba, el clúster reequilibró y siguió sirviendo consultas sin recargar, que es el comportamiento que un grafo a esta escala exige.

El sharding automático es lo que hace manejable esa escala. El motor particiona vértices y aristas por el clúster por su cuenta, así que los operadores no van colocando datos a mano según crece el grafo. Por debajo, un motor nativo en C++ sobre RocksDB entrega la alta escritura que necesita un grafo de transacciones masivo mientras sostiene recorridos de saltos múltiples eficientes. Para una gran plataforma que guarda un grafo de fraude enorme y lo recorre en busca de clústeres sospechosos a escala, NebulaGraph mantiene una latencia predecible allí donde los motores de un solo servidor sencillamente se quedan sin sitio.

El peaje es el reverso de esa escala. Operar un clúster distribuido es de verdad más complejo que levantar una base de un solo nodo, y las herramientas y la comunidad son más delgadas que las de Neo4j o Neptune. Para un grafo modesto la carga operativa supera cualquier beneficio; estarías pagando peaje de clúster por una capacidad que nunca usas. NebulaGraph se gana su sitio solo en el extremo de los billones de aristas. Para los operadores de muy gran escala a los que apunta, el escalado lineal merece la operación que exige.

Aplicación contra analítica. Pon a Dgraph al lado de Neo4j y el reparto es limpio: Neo4j está hecho para analistas que puntúan anillos de fraude, Dgraph está hecho para equipos de aplicaciones que sirven datos conectados a través de una API. Donde Neo4j te pide aprender Cypher, Dgraph sirve una API GraphQL de fábrica, así que los ingenieros de front-end y de aplicación consultan el grafo en el lenguaje que su app ya habla. Durante las pruebas apuntamos un cliente GraphQL directo a Dgraph y sacamos datos de cuentas conectadas sin capa de traducción en medio. Para un equipo de producto ya estandarizado en GraphQL, esa eliminación del código pegamento es el atractivo entero.

El motor respalda esa interfaz con fundamentos de producción. DQL, un lenguaje derivado de GraphQL, añade las operaciones específicas de grafo que la especificación base de GraphQL no trae, y la capa de almacenamiento fragmenta predicados por los nodos mientras ofrece transacciones ACID para lecturas y escrituras consistentes. Un servicio que guarda usuarios, productos y relaciones y los consulta bajo carga obtiene latencia baja y escala horizontal, que es un encaje real para backends de aplicaciones de datos conectados en tiempo real.

Donde Dgraph se queda corto para el propósito de este artículo es en la analítica de fraude en concreto. Trae muchos menos algoritmos de grafo integrados que Neo4j o TigerGraph, así que la detección de comunidades y la puntuación de centralidad que anclan una tubería de detección de fraude no están de forma nativa; esa lógica la construirías tú. Los recorridos analíticos profundos tampoco son su fuerte frente a los motores orientados a ciencia de datos. El gobierno y la hoja de ruta se han movido con los cambios de propiedad, lo que suma una capa de incertidumbre que un equipo de riesgo debe sopesar. Dgraph es un excelente backend de grafo para un equipo de aplicaciones que va primero con GraphQL. Como motor dedicado a la puntuación de fraude, no es la herramienta.

Empecemos por el defecto. Arranquemos por la pega, porque decide todo en JanusGraph: no hay servicio gestionado, y ensamblas la base de datos tú mismo. Levantarla significa cablear un backend de almacenamiento, un índice externo y la capa de grafo en un conjunto que funcione, y cada pieza de eso es de tu equipo para operar y afinar. Para un equipo antifraude que quiere estar consultando un grafo la semana que viene, este es el punto de partida equivocado, y no vamos a fingir lo contrario.

Lo que recibes a cambio es control y coste de licencia cero. JanusGraph es totalmente de código abierto bajo Apache 2.0, y superpone el ampliamente soportado lenguaje de recorrido Gremlin sobre backends de almacenamiento enchufables: Cassandra, HBase, Bigtable o BerkeleyDB. Para un equipo que ya opera uno de esos almacenes de big data, esa reutilización es el atractivo de verdad. Durante las pruebas corrimos un grafo de propiedades grande sobre un backend de Cassandra y lo consultamos con Gremlin para análisis de relaciones, y funcionó como se anuncia una vez configurado el stack. La integración con índices externos como Elasticsearch, Solr o Lucene añade indexación de texto completo y geográfica junto a los recorridos.

El rendimiento es solo tan bueno como el backend que elijas y lo bien que lo afines, así que los resultados varían mucho más que con un motor autocontenido. Esta es la elección para equipos de plataforma de big data que ya operan un stack de almacenamiento distribuido, quieren esquivar las licencias comerciales de bases de datos de grafos y tienen la pericia de infraestructura para ensamblar y operar el conjunto entero. Para quien quiera detección de fraude llave en mano, mira más arriba en esta lista.