2012-04-20 3 views
10

Sto giocando con neo4j, e mi stavo chiedendo, è comune avere una proprietà type su nodi che specificano che tipo di nodo è? Ho provato a cercare questa pratica e ho visto alcune persone usare name per uno scopo come questo, ma mi chiedevo se fosse considerato una buona pratica o se gli indici sarebbero il metodo più pratico?Tipo di nodo Neo4j

Un esempio potrebbe essere un nodo "Utente", che avrebbe tipo: user, in questo modo se l'indice fosse negativo, sarei in grado di eseguire una scansione di tutti i nodi e cercare i tipi di user.

risposta

7

È vero, dipende dal caso d'uso. Se si aggiunge una proprietà type e si desidera trovare tutti gli utenti, si hanno dei potenziali problemi poiché è necessario esaminare la proprietà su ogni nodo per raggiungere gli utenti. In tal caso, l'indice probabilmente andrebbe meglio, ma non nei casi in cui è necessario eseguire una query per tutti gli utenti con condizioni e relazioni non disponibili nell'indice (a meno che, naturalmente, l'indice non sia la fonte di "avvio"). Se si dispone di grafici come il mio, in cui un tipo di relazione implica due diversi tipi di nodo come A- (know) - (B) e A o B può essere un utente o un cliente, allora non funziona.

Quindi il tuo caso d'uso è davvero importante: è facile modellare graficamente i grafici, ma è importante "accordarlo" secondo il tuo schema di utilizzo.

4

IMHO non si dovrebbe dovere inserire una proprietà di tipo sul nodo. Invece, un modo comune per fare riferimento a tutti i nodi di un "tipo" specifico è quello di connettere tutti i nodi utente a un nodo chiamato "Utenti". In questo modo, partendo dal nodo Utenti, puoi facilmente trovare tutti i nodi utente. Il nodo "Utenti" stesso può essere indicizzato in modo da poterlo trovare facilmente, oppure può essere collegato al nodo di riferimento.

+5

L'unico problema di questo è che se si dispone di un numero enorme di utenti, potrai iniziare a colpire la pena di supernodo. Lo faccio ora in neo4django (https://github.com/scholrly/neo4django) e sto pensando di passare a un approccio index/relazione hyrbid. –

+1

Ho visto questo modello, suppongo che la mia preoccupazione fosse se l'indice/relazione fosse rotto per qualche motivo, il tipo di nodo è stato quindi perso, ma come sottolineato da @MattLuongo, possiamo dedurre l'uso di determinati attributi. – Nicholas

2

Penso che dipenda da te. Ad alcune persone piacciono gli attributi di tipo indicizzati, ma trovo che siano per lo più utili quando si hanno altri attributi indicizzati per restringere il numero di hit di indice (per cercare tutti gli utenti oltre i 21 anni, per esempio).

Detto questo, come sottolinea @Luanne, molti di noi cercano prima di risolvere il problema con il grafico. Un altro modo per farlo (e il modo più naturale, secondo me) è usare il tipo di relazione per dedurre un tipo di nodo pratico, cioè "A - (know) -> B", quindi A deve essere un utente o un altro cosa che può "sapere" e B deve essere un altro utente, un argomento o qualche altro oggetto che può "essere conosciuto".

2

Per le API client, la modellazione del tipo di elemento come una proprietà semplifica l'istanziazione dell'oggetto dominio giusto nel codice lato client in modo da includere sempre una proprietà type su ogni nodo/vertice.

Il nome "tipo" var è comunemente usato per questo, ma in alcune lingue come Python, "type" è una parola riservata, quindi uso "element_type" in Bulbs (http://bulbflow.com/quickstart/#models).

Questo non è necessario per gli spigoli/relazioni perché contengono già un tipo (l'etichetta) - si noti che Neo4j utilizza anche la parola chiave "tipo" anziché l'etichetta per le relazioni.

2

Direi che è una pratica comune. Ad esempio, questo è esattamente il modo in cui Spring Data Neo4j sa quale tipo di entità è un determinato nodo. Ogni nodo ha la proprietà "tipo" che contiene il nome classe qualificato dell'entità. Queste proprietà vengono automaticamente indicizzate nell'indice "tipi", quindi i nodi possono essere consultati molto velocemente. Potresti implementare il tuo caso d'uso esattamente come questo.

9

Labels sono stati aggiunti a neo4j 2.0. Risolvono questo problema.

È possibile creare i nodi con le etichette:

CREATE (me:American {name: "Emil"}) RETURN me; 

È possibile abbinare sulle etichette:

MATCH (n:American) 
WHERE n.name = 'Emil' 
RETURN n 

È possibile impostare qualsiasi numero di etichette su un nodo:

MATCH (n) 
WHERE n.name='Emil' 
SET n :Swedish:Bossman 
RETURN n 

È possibile eliminare qualsiasi numero di etichette su un nodo:

MATCH (n { name: 'Emil' }) 
REMOVE n:Swedish 

Etc ...