¿Es una buena idea usar MySQL y Neo4j juntos?

Question

Me hará una aplicación con una gran cantidad de artículos similares (millones), y me gustaría para almacenarlos en una base de datos MySQL, porque me gustaría hacer una gran cantidad de estadísticas y la búsqueda de valores específicos para las columnas específicas.

Pero, al mismo tiempo, pueda almacenar las relaciones entre todos los elementos, que están relacionados en muchas bases de datos de árboles como binarios estructuras (cierre transitivo), y la relación conectados no son buenos en este tipo de estructuras, por lo que lo haría como para 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 almacenados en la base de datos Neo4j. Cuando quiero para buscar un árbol, lo primero que busco el Neo4j para toda la item_id: s en el árbol, entonces busco la base de datos MySQL para todos los elementos especificados en una consulta que se vería así:

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 esta una buena idea, o soy muy mal? gráfico-bases de datos que no he usado antes. ¿Hay algo mejor se aproxima a mi problema? ¿Cómo sería el mysql-query realizar en este caso?

Answer 1

Algunas reflexiones sobre esto:

me gustaría probar el modelado de su modelo de dominio Neo4j para incluir los atributos de cada nodo en el gráfico. Al separar los datos en dos almacenes de datos diferentes que podrían limitar algunas operaciones que es posible que desee hacer.

supongo que se reduce a lo que va a hacer con su gráfico. Si, por ejemplo, usted quiere encontrar todos los nodos conectados a un nodo específico cuyos atributos (es decir, nombre, edad .. lo que sea) son ciertos valores, usted primero tiene que encontrar el ID de nodo correcto en su base de datos MySQL y luego ir a Neo4j? Esto sólo parece lento y excesivamente complicado cuando se podría hacer todo esto en Neo4j. Entonces la pregunta es: se necesita los atributos de un nodo cuando se atraviesa la gráfica?

¿Su cambio de datos o es estática? Al tener dos almacenes de datos separados se va a complicar las cosas.

Mientras que la generación de estadísticas utilizando una base de datos MySQL que podría ser más fácil que hacerlo todo en Neo4j, el código necesario para atravesar una gráfica para encontrar todos los nodos que cumplen con un criterio definido no es demasiado difícil. Lo que estas estadísticas son debe conducir su solución.

No puedo comentar sobre el rendimiento de la consulta MySQL para seleccionar los identificadores de nodo. Supongo que se reduce a la cantidad de nodos que tendrá que seleccionar y su estrategia de indexación. Estoy de acuerdo con cuanto al rendimiento de las cosas cuando se trata de atravesar un gráfico sin embargo.

Este es un artículo bueno en apenas esto: MySQL vs Neo4j en un gran escala Gráfico Transversal y en este caso, cuando dicen grande, que sólo significan un millón de vértices / nodos y cuatro millones de bordes. Por lo tanto, no era ni siquiera un gráfico particularmente densa.

Answer 2

bases de datos relacionales pueden manejar estructuras de gráficos. Algunos de ellos incluso pueden manejarlos moderadamente elegante (tan elegante como una base de datos relacional pone!).

La clave para gráfica general de la manipulación en bases de datos relacionales es la href="http://www.postgresql.org/docs/9.1/static/queries-with.html" rel="noreferrer"> tabla común recursiva expresión (RCTE), que básicamente le permite de forma iterativa (no recursiva, a pesar del nombre) ampliar una consulta sobre un conjunto de filas, mediante la combinación de una consulta que selecciona un conjunto de filas de la raíz y una consulta que define los vecinos de filas seleccionadas hasta el momento. La sintaxis es un poco torpe, pero es general y de gran alcance.

RCTEs están soportados en PostgreSQL, Firebird, SQL Server, y al parecer en DB2. Oracle tiene una construcción diferente, pero equivalente; He leído que las versiones recientes apoyan RCTEs adecuados. MySQL no soporta RCTEs. Si no está casado con MySQL, yo le pido 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 para soportar gráficos generales, sólo árboles. En ese caso, hay opciones más específicas abiertas para usted.

Uno es el lugar mindbending conjuntos anidados clásico pero .

A uno más simple es la de almacenar un camino con cada fila: esto es una cadena que representa la posición de la fila en el árbol, y tiene la propiedad de que el camino para un nodo es un prefijo de la ruta de acceso para cualquier nodo secundario, lo que permite lo hace de manera muy eficiente varias preguntas sobre la ascendencia ( "es el nodo a un hijo del nodo B?", "¿cuál es el nodo a y el nodo más bajo ancestro común de B?", etc.). Por ejemplo, se puede construir un camino para una fila por recorrer el árbol desde la raíz, y uniéndose a los ID de las filas encontradas en el camino con barras. Esto es sencillo de construir, pero sí tienen cuidado de mantener si reorganiza el árbol. Con una columna de ruta, puede restringir una consulta a un árbol dado simplemente añadiendo and path like '23/%', donde 23 es el ID de la raíz.

Así que, a pesar de una base de datos gráfica es probablemente la mejor manera de almacenar datos y el gráfico de consultas, no es la única opción, y sugeriría a sopesar las ventajas de utilizar una contra las ventajas de tener todos sus datos en una sola base de datos.

Answer 3

Estoy en su mayoría con Binario del empollón en esto, pero me gustaría añadir una variación. Se podría almacenar los datos en tiempo real en Neo4j y luego extraer los datos que necesita para las estadísticas / informar y poner en MySQL. Para búsquedas me gustaría ir con la Neo4j-Lucene integración si que se adapte a sus necesidades.

Answer 4

Se puede mejorar la consulta utilizando IN:

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

También, no es del todo cierto que las bases de datos relacionales son malos en el almacenamiento de las estructuras de árbol. Ciertamente MySQL falta algunas funciones que haría más fácil, pero la mayoría de las otras bases de datos soporta bien. Oracle tiene CONNECT BY. La mayoría de los RDBMS convencionales tienen alguna forma de consultas recursivas - MySQL siendo una notable excepción. Tal vez usted podría echar un vistazo a PostgreSQL y ver si cumple con sus necesidades?