¿Es una buena idea usar MySQL y Neo4j juntos?

Question

¿Es una buena idea usar MySQL y Neo4j juntos?

Haré una aplicación con muchos elementos similares (millones), y me gustaría almacenarlos en una base de datos MySQL, porque me gustaría hacer muchas estadísticas y buscar valores específicos para columnas específicas.

Pero al mismo tiempo, voy a almacenar las relaciones entre todos los elementos, que están relacionados en muchas estructuras de árbol binario conectado-como (cierre transitivo), y las bases de datos de relaciones no son buenos en ese tipo de estructuras, así que me gustaría almacenar todas las relaciones en Neo4j que tienen un buen rendimiento para este tipo de datos.

Mi plan es tener todos los datos excepto las relaciones en la base de datos MySQL y todas las relaciones con item_id almacenadas en la base de datos Neo4j. Cuando quiero buscar un árbol, primero busco en el Neo4j todos los item_id:s en el árbol, luego busco en la base de datos MySQL todos los elementos especificados en una consulta que se vería como:

SELECT * FROM items WHERE item_id = 45 OR item_id = 345435 OR item_id = 343 OR item_id = 78 OR item_id = 4522 OR item_id = 676 OR item_id = 443 OR item_id = 4255 OR item_id = 4345

Es una buena idea, o estoy muy equivocado? No he usado graph-databases antes. ¿Hay algún enfoque mejor para mi problema? ¿Cómo funcionaría la consulta MySQL en este caso?

47

mysql architecture neo4j graph-databases hierarchical-data

Author: Jonas, 2010-03-30

Source

4 answers

Las bases de datos relacionales pueden manejar estructuras de grafos. Algunos de ellos pueden incluso manejarlos moderadamente elegantemente (¡tan elegantemente como lo hace una base de datos relacional!).

La clave para el manejo general de gráficos en bases de datos relacionales es la expresión de tabla común recursiva (RCTE), que básicamente le permite iterativamente (no recursivamente, a pesar del nombre) expandir una consulta sobre un conjunto de filas, combinando una consulta que selecciona un conjunto raíz de filas y una consulta que define seleccionado hasta ahora. La sintaxis es un poco torpe, pero es general y poderosa.

Los RCTE son soportados en PostgreSQL, Firebird, SQL Server, y aparentemente en DB2. Oracle tiene una construcción diferente pero equivalente; he leído que las versiones recientes admiten RCTEs adecuados. MySQL no soporta RCTEs. Si usted no está casado con MySQL, le insto a considerar el uso de PostgreSQL, que es básicamente una base de datos mucho mejor en todo.

Sin embargo, parece que no es necesario apoyar gráficos generales, sólo árboles. En ese caso, hay opciones más específicas abiertas para usted.

Uno es el clásico pero más bien mindbending conjuntos anidados.

Una más simple es almacenar una ruta con cada fila: esta es una cadena que representa la posición de la fila en el árbol, y tiene la propiedad de que la ruta de un nodo es un prefijo de la ruta de cualquier subnodo, lo que le permite hacer muy eficientemente varias consultas sobre ancestry ("is node A a child of node B?", "¿qué es el nodo A y ¿el ancestro común más bajo del nodo B?", sucesivamente). Por ejemplo, puede construir una ruta para una fila recorriendo el árbol desde la raíz y uniendo los ID de las filas encontradas en el camino con barras. Esto es fácil de construir, pero tiene cuidado de mantener si reorganiza el árbol. Con una columna path, puede restringir una consulta a un árbol dado simplemente agregando and path like '23/%', donde 23 es el ID de la raíz.

Entonces, aunque una base de datos de gráficos es probablemente la mejor manera de almacenar y consultar datos de gráficos, no es la única opción, y le sugiero que sopese las ventajas de usar uno contra las ventajas de tener todos sus datos en una sola base de datos.

9

Author: Tom Anderson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-08 17:47:02

Estoy mayormente con Binario Nerd en esto, pero me gustaría añadir una variación. Puede almacenar los datos en vivo en Neo4j y luego extraer los datos que necesita para estadísticas / informes y ponerlos en MySQL. Para las búsquedas iría con la integración Neo4j-Lucene si eso se ajusta a sus necesidades.

5

Author: nawroth,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-30 08:30:06

Puede mejorar la consulta usando EN:

SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)

Tampoco es del todo cierto que las bases de datos relacionales sean malas para almacenar estructuras de árbol. Ciertamente a MySQL le falta alguna funcionalidad que lo haría más fácil, pero la mayoría de las otras bases de datos lo soportan bien. Oracle tiene CONNECT BY. La mayoría de los RDBM convencionales tienen alguna forma de consultas recursivas - MySQL es una excepción notable. ¿Tal vez podría echar un vistazo a PostgreSQL y ver si eso satisface sus necesidades?

4

Author: Mark Byers,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-29 23:29:29

score 26 · Accepted Answer

Algunas reflexiones sobre esto:

Intentaría modelar su modelo de dominio Neo4j para incluir los atributos de cada nodo en el gráfico. Al separar sus datos en dos almacenes de datos diferentes, puede limitar algunas operaciones que desee realizar.

Supongo que todo se reduce a lo que harás con tu gráfico. Si, por ejemplo, desea encontrar todos los nodos conectados a un nodo específico cuyos atributos (es decir, nombre, edad.. lo que sea) son ciertos valores, primero tendría que encontrar el ID de nodo correcto en su base de datos MySQL y luego entrar en Neo4j? Esto parece lento y demasiado complicado cuando se puede hacer todo esto en Neo4j. Así que la pregunta es: ¿necesitará los atributos de un nodo al atravesar el gráfico?

¿Cambiarán sus datos o son estáticos? Al tener dos almacenes de datos separados, complicará las cosas.

Mientras que generar estadísticas usando una base de datos MySQL puede ser más fácil que hacer todo en Neo4j, el código requerido para recorrer un gráfico encontrar todos los nodos que cumplen con un criterio definido no es demasiado difícil. Cuáles son estas estadísticas deberían impulsar tu solución.

No puedo comentar sobre el rendimiento de la consulta MySQL para seleccionar los id de nodo. Supongo que eso se reduce a cuántos nodos tendrá que seleccionar y su estrategia de indexación. Estoy de acuerdo sobre el lado del rendimiento de las cosas cuando se trata de atravesar un gráfico, aunque.

Este es un buen artículo sobre esto: MySQL vs Neo4j en una Gran Escala Gráfica Traversal y en este caso, cuando dicen grande, solo significan un millón de vértices/nodos y cuatro millones de aristas. Así que ni siquiera era un gráfico particularmente denso.