2010-07-13 16 views

risposta

11

Come approccio a una risposta, potresti voler controllare questa intervista con Emil Eifrem (neo fondatore): http://www.infoq.com/interviews/eifrem-graphdbs. In particolare, dai un'occhiata a "Da una prospettiva di complessità dei dati, in che modo Neo4j aiuta a rimuovere parte della complessità dell'implementazione nell'archiviazione dei dati?": "Centinaia di milioni sono probabilmente di grandi dimensioni e miliardi decisamente grandi".

Sono stato in conversazione con le tecnologie neo di recente, in cui hanno condiviso che le installazioni più grandi che conoscono a livello di macchina non hanno più di 3-5 macchine.

Inoltre, hanno affermato che la dimensione del grafico neo4j può gestire in modo efficiente dipende dal numero di nodi e spigoli nel grafico. Se possono essere tutti tenuti in memoria, la maggior parte delle query sarà veloce. Le dimensioni dei nodi e dei bordi sono memorizzate nella memoria http://wiki.neo4j.org/content/Configuration_Settings (sono 9 byte per nodo e 33 byte per relazione).

+1

3-5 macchine suona piuttosto piccolo ... –

+1

Jep. Questo è quello che pensavamo. La soluzione HighAvailability era stata testata con 20 macchine. Non hanno visto la necessità di più macchine nella pratica. Se il tuo ok con il limite attuale di 4 miliardi di primitivi, il problema potrebbe diventare velocità di scrittura (che in genere è limitata dalla velocità di IO). L'aggiunta di server ridimensiona le letture ma non le scritture. – Stephan

+0

Sono 32 miliardi di primitivi. –

12

Il numero di nodi e relazioni è stato recentemente (con il numero 1.3 release) espanso a 32 miliardi ciascuno e altri 64 miliardi per le proprietà. Se si guarda la mailing list, ci sono state richieste recenti per datastore quitelarge.

Problemi correlati