E 'una buona idea di utilizzare MySQL e Neo4j insieme?

Question

Io farò una domanda con un sacco di elementi simili (milioni), e vorrei per memorizzarli in un database MySQL, perché mi piacerebbe fare un sacco di statistiche e cercare valori specifici per colonne specifiche.

Ma, allo stesso tempo, mi memorizzerà le relazioni tra tutti gli elementi, che sono legati in molte strutture-albero-come binari collegati (chiusura transitiva) e database relazionali non sono bravo in questo tipo di strutture, quindi vorrei desidera memorizzare tutti i rapporti in Neo4j che hanno buone prestazioni per questo tipo di dati.

Il mio piano è quello di avere tutti i dati tranne le relazioni nel database MySQL e di tutti i rapporti con item_id memorizzati nel database Neo4j. Quando voglio di ricercare un albero, io cerco la prima Neo4j per tutta la item_id: s nell'albero, quindi cerco il MySQL database per tutti gli elementi specificati in una query che sarà simile:

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

E 'una buona idea, o sono io molto sbagliato? non ho usato grafico-database prima. Ci sono approcci migliori per il mio problema? Come sarebbe il MySQL-query esibirsi in questo caso?

Answer 1

Pochi pensieri su questo:

Vorrei provare modellare il vostro modello di dominio Neo4j per includere gli attributi di ciascun nodo del grafo. Separando i dati in due diversi archivi di dati si potrebbe limitare alcune operazioni che si potrebbe desiderare di fare.

Credo che si riduce a ciò che si farà con il grafico. Se, ad esempio, si desidera trovare tutti i nodi collegati ad un nodo specifico i cui attributi (ad esempio nome, età .. qualunque cosa) sono certi valori, avresti primi a trovare l'ID del nodo corretto nel vostro database MySQL e poi andare in Neo4j? Questo sembra solo lento e troppo complicato quando si poteva fare tutto questo in Neo4j. Quindi la domanda è: avrete bisogno gli attributi di un nodo quando si attraversa il grafico?

Sarà la modifica dei dati o è statica? Avendo due archivi di dati separati sarà complicare le cose.

Mentre statistiche utilizzando un database MySQL potrebbe essere più facile che fare tutto in Neo4j, il codice necessario per attraversare un grafico per trovare tutti i nodi che soddisfano un criteri definiti non è eccessivamente difficile. Quali sono queste statistiche dovrebbe guidare la vostra soluzione.

Non riesco a commentare la prestazione della query MySQL per selezionare gli ID dei nodi. Immagino che si riduce a quanti nodi è necessario selezionare e la vostra strategia di indicizzazione. Sono d'accordo circa il lato prestazioni delle cose quando si tratta di attraversare un grafico però.

Questo è un buon articolo proprio su questo: MySQL vs Neo4j su larga scala Graph Traversal e in questo caso, quando dicono di grandi dimensioni, significano solo un milione di vertici / nodi e quattro milioni di spigoli. Così non è stato nemmeno un grafico particolarmente denso.

Answer 2

I database relazionali in grado di gestire le strutture del grafico. Alcuni di essi possono anche gestirli moderatamente elegante (come elegantemente come un database relazionale ottiene!).

La chiave per la gestione generale in database relazionali grafico è il ricorsiva tavolo comune espressione (RCTE), che sostanzialmente consente iterativamente (non ricorsivo, nonostante il nome) espandere una query su un insieme di righe, combinando una query che seleziona un insieme di righe radice e una query che definisce i vicini riga selezionata finora. La sintassi è un po 'goffo, ma è generale e potente.

RCTEs sono supportati in PostgreSQL, Firebird, SQL Server, e apparentemente in DB2. Oracle ha un costrutto differente, ma equivalente; Ho letto che le versioni recenti supportano RCTEs adeguate. MySql non supporta RCTEs. Se non si è sposata a MySQL, vi invito a considerare l'utilizzo di PostgreSQL, che è fondamentalmente un database molto meglio a tutto tondo.

Tuttavia, sembra che tu non c'è bisogno di sostenere i grafici generali, solo alberi. In questo caso, ci sono opzioni più specifiche aperte a voi.

Uno è il classico ma piuttosto prigione mentale di set nidificati .

A una più semplice è quello di memorizzare un percorso con ogni riga: questa è una stringa che rappresenta la posizione della riga nella struttura, ed ha la proprietà che il percorso di un nodo è un prefisso di percorso per ogni nodo secondario, che permette si in modo molto efficiente di fare varie query su ascendenza ( "è il nodo a un figlio di nodo B?", "qual è il nodo a e il più basso antenato comune del nodo di B?", ecc). Ad esempio, si potrebbe costruire un percorso per una riga percorrendo l'albero dalla radice, e unendo gli ID delle righe riscontrate sul modo con barre. Questo è semplice da costruire, ma ci vuole cura per mantenere se si riorganizzare l'albero. Con una colonna percorso, è possibile limitare una query per un determinato albero semplicemente aggiungendo and path like '23/%', dove 23 è l'ID del root.

Quindi, anche se un database grafico è probabilmente il modo migliore per conservare e dati grafici di query, non è l'unica opzione, e vorrei suggerire a pesare i vantaggi di utilizzare uno contro i vantaggi di avere tutti i dati in un unico banca dati.

Answer 3

Sono per lo più con Nerd binario su questo, ma vorrei aggiungere una variante. È possibile memorizzare i dati in tempo reale in Neo4j e quindi estrarre i dati necessari per le statistiche / reporting e messo in MySQL. Per le ricerche mi piacerebbe andare con la Neo4j-Lucene integrazione se che si adatta alle vostre esigenze.

Answer 4

È possibile migliorare la query utilizzando in:

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

Inoltre non è del tutto vero che i database relazionali sono affatto male la memorizzazione di strutture ad albero. Certamente MySQL manca alcune funzionalità che renderebbe più facile, ma la maggior parte altri database supporta bene. Oracle ha CONNECT BY. La maggior parte dei RDBMS tradizionali hanno una qualche forma di query ricorsive - MySQL essendo una notevole eccezione. Forse si potrebbe dare un'occhiata a PostgreSQL e vedere se questo soddisfa le vostre esigenze?