Quali sono i casi d'uso dei database basati su grafici (http://neo4j.org/)? [chiuso]

Ho usato molto DB relazionali e ho deciso di avventurarmi su altri tipi disponibili.

Questo particolare prodotto sembra buono e promettente: http://neo4j.org/

Qualcuno ha usato database basati su grafici? Quali sono i pro e i contro da una prospettiva di usabilità?

Li hai usati in un ambiente di produzione? Qual è stato il requisito che ti ha spinto a usarli?

Ho usato un database grafico in un precedente lavoro. Non stavamo usando Neo4j, era una cosa interna costruita sopra Berkeley DB, ma era simile. Era usato in produzione (lo è ancora).

Il motivo per cui abbiamo usato un database di grafi era che i dati archiviati dal sistema e le operazioni che il sistema stava facendo con i dati erano esattamente il punto debole dei database relazionali ed erano esattamente il punto forte dei database di grafi. Il sistema doveva archiviare raccolte di oggetti privi di uno schema fisso e collegati tra loro da relazioni. Per ragionare sui dati, il sistema doveva fare molte operazioni che sarebbero state un paio di traversate in un database di grafi, ma sarebbero query piuttosto complesse in SQL.

I principali vantaggi del modello grafico sono stati il ​​rapido tempo di sviluppo e la flessibilità. Potremmo aggiungere rapidamente nuove funzionalità senza influire sulle distribuzioni esistenti. Se un potenziale cliente volesse importare alcuni dei propri dati e innestarli sul nostro modello, di solito potrebbe essere fatto sul posto dal rappresentante di vendita. La flessibilità ha anche aiutato durante la progettazione di una nuova funzionalità, salvandoci dal tentativo di comprimere nuovi dati in un modello di dati rigido.

Avere uno strano database ci permette di costruire molte altre nostre strane tecnologie, dandoci un sacco di segreti per distinguere il nostro prodotto da quelli dei nostri concorrenti.

Lo svantaggio principale era che non stavamo usando la tecnologia standard di database relazionale, il che può essere un problema quando i tuoi clienti sono enterprise. I nostri clienti si chiederebbero perché non potremmo semplicemente ospitare i nostri dati sui loro giganteschi cluster Oracle (i nostri clienti di solito disponevano di grandi data center). Uno dei team ha riscritto il livello del database per utilizzare Oracle (o PostgreSQL o MySQL), ma era leggermente più lento dell'originale. Almeno una grande impresa aveva persino una politica solo Oracle, ma fortunatamente Oracle acquistò Berkeley DB. Dovevamo anche scrivere molti strumenti extra, ad esempio non potevamo semplicemente usare Crystal Reports.

L'altro svantaggio del nostro database di grafi era che lo abbiamo creato noi stessi, il che significa che quando abbiamo riscontrato un problema (di solito con scalabilità) abbiamo dovuto risolverlo da soli. Se avessimo utilizzato un database relazionale, il fornitore avrebbe già risolto il problema dieci anni fa.

Se stai costruendo un prodotto per clienti aziendali e i tuoi dati si adattano al modello relazionale, se puoi puoi utilizzare un database relazionale. Se l'applicazione non si adatta al modello relazionale ma si adatta al modello grafico, utilizzare un database grafico. Se si adatta solo a qualcos'altro, usalo.

Se la tua applicazione non ha bisogno di adattarsi all'attuale architettura blub, usa un database grafico, o CouchDB, o BigTable, o qualunque cosa si adatti alla tua app e pensi che sia bello. Potrebbe darti un vantaggio ed è divertente provare cose nuove.

Qualunque cosa tu scelga, cerca di non creare tu stesso il motore di database a meno che non ti piaccia davvero costruire motori di database.

Lavoriamo con il team Neo da oltre un anno e siamo stati molto felici. Modelliamo artefatti accademici e le loro relazioni, che sono perfetti per un grafico db, ed eseguiamo algoritmi di raccomandazione sulla rete.

Se stai già lavorando in Java, penso che la modellazione usando Neo4j sia molto semplice e abbia le prestazioni più piatte / veloci per R / W di qualsiasi altra soluzione che abbiamo provato.

Ad essere sincero, faccio fatica a non pensare in termini di grafico / rete perché è molto più facile che progettare strutture di tabella contorte per contenere proprietà e relazioni degli oggetti.

Detto questo, archiviamo alcune informazioni in MySQL semplicemente perché è più facile per il lato Business eseguire query SQL rapide. Per eseguire le stesse funzioni con Neo avremmo bisogno di scrivere codice per il quale non abbiamo semplicemente la larghezza di banda per ora. Non appena lo facciamo, sto trasferendo tutti quei dati su Neo!

In bocca al lupo.

Due punti:

In primo luogo, sui dati con cui ho lavorato negli ultimi 5 anni in SQL Server, di recente ho raggiunto il muro della scalabilità con SQL per il tipo di query che dobbiamo eseguire (rapporti annidati ... sai ... grafici ). Ho giocato con neo4j e i miei tempi di ricerca sono più veloci di molti ordini di grandezza quando ho bisogno di questo tipo di ricerca.

In secondo luogo, al punto che i database dei grafici sono obsoleti. Um ... no. All'inizio, mentre le persone cercavano di capire come archiviare e cercare i dati in modo efficiente, hanno creato e giocato con modelli di database in stile grafico e di rete. Questi sono stati progettati in modo che il modello fisico riflettesse il modello logico, quindi la loro efficienza non era eccezionale. Questo tipo di struttura di dati era buono per i dati semi-strutturati, ma non altrettanto buono per i dati densi strutturati. Quindi, questo tizio IBM di nome Codd stava cercando modi efficienti per organizzare e archiviare dati strutturati e ha avuto l'idea per il modello di database relazionale. Ed è stato bello, e la gente era felice.

Cosa abbiamo qui? Due strumenti per due scopi diversi. I modelli di database grafici sono ottimi per rappresentare dati semi-strutturati e le relazioni tra entità (che possono o meno esistere). I database relazionali sono utili per i dati strutturati che hanno uno schema molto statico e dove le profondità di join non vanno molto in profondità. Uno è buono per un tipo di dati, l'altro è buono per altri tipi di dati.

Per coniare la frase, non esiste un proiettile d'argento. È lungimirante affermare che i modelli di database dei grafi non sono aggiornati e utilizzarne uno lascia perdere 40 anni di progressi. È come dire che usare C significa rinunciare a tutti i progressi tecnologici che abbiamo fatto per ottenere cose come Java e C #. Questo non è vero però. C è uno strumento necessario per alcune attività. E Java è uno strumento per altre attività.

Ho usato MySQL per anni per gestire i dati di ingegneria e ha funzionato bene, ma uno dei problemi che abbiamo avuto (ma non ci siamo resi conto che era) era che dovevamo sempre pianificare lo schema in anticipo. Un altro problema che sapevamo di avere era mappare i dati su oggetti di dominio e viceversa.

Ora abbiamo appena iniziato a provare neo4j e sembra che stia risolvendo entrambi i problemi per noi. La capacità di aggiungere proprietà diverse a ciascun nodo (e relazione) ci ha permesso di ripensare il nostro intero approccio ai dati. È come i linguaggi dinamici contro quelli statici (Ruby contro Java), ma per i database. La creazione del modello di dati nel database può essere eseguita in un modo molto più agile e dinamico e ciò semplifica notevolmente il nostro codice.

E poiché il modello a oggetti nel codice è generalmente una struttura grafica, anche la mappatura dal database è più semplice, con meno codice e di conseguenza meno bug.

E come bonus aggiuntivo, il nostro codice prototipo iniziale per il caricamento dei nostri dati in neo4j sta effettivamente funzionando più velocemente della precedente versione di MySQL. Non ho numeri solidi su questo (ancora), ma quella era una bella caratteristica aggiuntiva.

Ma alla fine, la scelta dovrebbe probabilmente basarsi principalmente sulla natura del tuo modello di dominio. Si associa meglio a tabelle o grafici? Decidi facendo alcuni prototipi, carica i dati e gioca con esso. Usa neoclipse per guardare diverse viste dei dati. Dopo averlo fatto, spero che tu sappia se sei bravo o no.

Sto costruendo una intranet presso la mia azienda.

Sono interessato a capire come caricare i dati memorizzati nelle tabelle (Oracle, MySQL, SQL Server, Excel, Access, vari elenchi casuali) e caricarli in Neo4J o in qualche altro database grafico. In particolare, cosa succede quando i dati comuni si sovrappongono ai dati esistenti già nel sistema.

Sì, so che alcuni dati sono meglio modellati in RDBMS, ma ho questa idea che mi prude, che quando è necessario sovrapporre più tabelle distinte, il modello di grafico è migliore della struttura della tabella.

Ad esempio, lavoro in un ambiente di produzione. C'è un grande progetto su cui stiamo lavorando e, data la complessità, ogni dipartimento ha creato un foglio di calcolo Excel separato che ha una gerarchia DBA (Bill Of Materials) in una colonna a sinistra e poi diverse colonne di note e controlli fatte da singoli chi ha realizzato questi fogli.

Quindi uno dei problemi è quello di unire tutte queste note in un'unica "vista" in modo che qualcuno possa vedere tutti i problemi che devono essere affrontati in una particolare parte.

Il secondo problema è che un foglio di calcolo Excel fa schifo nel rappresentare una distinta base gerarchica quando un componente comune viene utilizzato in più di un sottoassieme. Ciò significa che, se qualcuno scrive una nota sul relè P34 nel sottoassieme di accensione, lo stesso commento dovrebbe essere associato ai relè P34 utilizzati nel sottoassieme del driver del motore. Ciò non si verificherà nel foglio di calcolo Excel.

Per la intranet aziendale, voglio essere in grado di cercare qualsiasi cosa facilmente. Come i dati relativi a un numero di parte, una struttura DBA, un numero di telefono, un indirizzo e-mail, una politica aziendale o una procedura. Voglio persino estenderlo per gestire le risorse hardware del computer e il software installato.

Immagino che una volta che la rete di informazione inizia a essere popolata, puoi iniziare a fare interessanti spostamenti come "Voglio scrivere un'e-mail a tutti coloro che lavorano al progetto XYZ". Le persone saranno state associate al progetto perché saranno taggate come creazione e modifica dei dati all'interno del progetto XYZ. Quindi, usando il progetto XYZ come chiave di ricerca, verrà creato un set enorme con tutto ciò che riguarda il progetto XYZ. Compresi collegamenti a persone che hanno realizzato il progetto XYZ. I collegamenti persone si collegheranno ai loro indirizzi e-mail. Quindi, grazie al loro coinvolgimento nel progetto XYZ, saranno inclusi nella mia e-mail. Ciò è in netto contrasto con alcuni segretari che cercano di mantenere un elenco di persone che lavorano al progetto. Generiamo molte liste. Dedichiamo molto tempo alla manutenzione degli elenchi e alla verifica che siano aggiornati.

Un altro attraversamento interessante potrebbe segnalare tutti i computer su cui è installato un determinato software, in base alla versione. Tale report potrebbe essere utilizzato per generare attività per rimuovere copie extra di vecchi software e per aggiornare le persone che devono disporre della copia più recente. Sarebbe utile anche per il tracciamento della licenza.

Ecco un buon articolo che parla delle esigenze che i database non relazionali soddisfano: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Fa un buon lavoro nel sottolineare (a parte il nome) che i database relazionali non sono imperfetti o sbagliati, è solo che in questi giorni le persone stanno iniziando a elaborare sempre più dati nel software e nei siti Web tradizionali e che i database relazionali non si ridimensionano per queste esigenze.

potrebbe essere un po 'in ritardo, ma c'è un numero crescente di progetti che utilizzano Neo4j, i più noti elencati in Neo4j . Anche NeoTechnology, la società dietro Neo4j, ha alcuni riferimenti nella pagina dei suoi clienti

_{Nota: faccio parte del team Neo4j}