Architettare un'applicazione basata su Neo4j: attenersi all'API di vanilla utilizzando nodi e relazioni semplici o utilizzare Spring/GORM?

Question

Spero di sentire qualcuno di voi che ha architettato e implementato un'app Neo4j di dimensioni decenti (10 milioni di nodi/rel) e quali sono le vostre raccomandazioni in particolare sulla modellazione e le varie API (vanilla java/groovy Neo4j vs Spring -Data-Neo4j vs Grails GORM/Neo4j).

Mi interessa se è effettivamente utile aggiungere il layer OGM (object-graph-mapping) e le astrazioni associate?

ha esperienza di nessuno stato che è meglio attenersi a 'normale' grafico-modellazione con nodi + proprietà, relazioni + proprietà, attraversamenti e (per esempio) Cypher per modellare e memorizzare i loro dati?

La mia preoccupazione è che "forzare" una particolare astrazione OGM su un database grafico influirà sulla flessibilità futura nell'adattare/modificare il modello di dominio e/o la flessibilità nell'inquisire i dati.

Siamo un negozio Grails, e ho sperimentato GORM/Neo4J e anche con spring-data-neo4j.

Lo scopo principale del set di dati sarà quello di modellare e interrogare le relazioni tra un numero enorme di persone, i loro alias, i loro associati e ogni tipo di attività criminale e cronologia. Ci saranno più di 50 classi di dominio principali. Ci deve essere flessibilità nel modello (che dovrà evolvere rapidamente nelle prime fasi del progetto) e nella velocità e flessibilità delle query.

devo confessare, sto lottando per trovare un motivo valido per utilizzare uno strato di OGM quando posso utilizzare (per esempio) o POJO Pogos, un po 'di magia Groovy e qualche semplice oggetto di dominio arrotolato a mano < -> nodo/codice di mappatura delle relazioni. Per quanto posso dire, penso che sarei felice solo a trattare con i nodi & traversamenti & Cypher (aka KISS). Ma sarei molto felice di ascoltare le esperienze e le raccomandazioni degli altri.

Grazie per il vostro tempo & pensieri,

TP

Answer 1

dato che io sono l'autore del plugin Grails Neo4j, potrei essere prevenuto. Il motivo principale per la creazione del plug-in è stato quello di applicare la facilità delle classi di domini Grails con il loro potente impalcatura out-of-the-box a Neo4j per circa l'80% dei casi d'uso. Per l'altro 20%, dove i requisiti specifici richiedono cose come gli attraversamenti ecc., Stiamo usando le API Neo4j direttamente (traversal/cypher) e non usiamo l'API GORM.

La versione corrente del plug-in Neo4j soffre di un problema di supernodo poiché ogni istanza di dominio è connessa a un nodo di sottoreferenza. Se più richieste simultanee (ovvero thread) aggiungono nuove istanze di dominio, è possibile che si verifichi un'eccezione di blocco. Sto per risolvere questo problema con un approccio sub-subriferenziale o usando l'indicizzazione.

Cypher può essere utilizzato anche nel plug-in Neo4j Grails.

Spring-Data-Neo4j d'altra parte è un approccio più avanzato con un controllo più preciso sui dettagli di mappatura, ma richiede l'uso di annotazioni specifiche. E non ho trovato un modo semplice per integrarlo in Grails, in un modo che funziona con impalcature.

Stiamo utilizzando la versione precedente del plug-in in un'applicazione produttiva con ~ 60k utenti e ~ 10^6 rel. A causa della NDA, non posso fornire ulteriori dettagli al riguardo.

Answer 2

Non usiamo graal, ma usiamo una soluzione ibrida di neo4j/spring-data-neo4j.Il motivo si basa sul fatto che alcuni dei nostri dati di dominio hanno uno schema fisso e altri no. SDN toglie gran parte del carico e può essere combinato con neo4j in caso di necessità.

Abbiamo classi che descrivono un modello di dati, gli oggetti per queste classi persistono utilizzando SDN, senza trucchi aggiuntivi, utilizziamo solo le basi di SDN. Quindi abbiamo classi che contengono i dati per il modello che non è noto in anticipo. Questi sono memorizzati nei nodi contengono proprietà speciali per descrivere il tipo di modello a cui si riferiscono i dati. Quando neo4j 2 viene rilasciato, probabilmente trasferiremo tali informazioni in etichette. Tra questi nodi possono esserci relazioni, descritte anche dal suddetto modello di dati gestito da sdn. Abbiamo anche relazioni dai nodi generici ai nodi SDN, che funziona bene, poiché tutto finisce per essere le stesse cose: i nodi.

Non abbiamo ancora riscontrato problemi con questo approccio. La cosa che amiamo di più è che i dati di cui non sappiamo in anticipo come verrà modellato, sono memorizzati nel modo in cui avresti voluto memorizzare i dati quando avresti saputo in anticipo, facendo in modo che i dati corrispondessero effettivamente il modello scelto, che è molto difficile da fare quando si utilizza qualsiasi altro tipo di database (non grafico).