I database grafici possono distribuire i dati in modo efficiente attraverso i nodi?

Question

Se qualcuno crea un database su un altro database, come ad esempio Twitter, il database eredita le limitazioni e le inefficienze del database sottostante?

Sono specificamente interessato a titan db (http://thinkaurelius.com) a causa della loro pretesa di supportare la divisione del set di dati in modo efficiente attraverso i nodi.

Sostengono di supportare la distribuzione di dati tra i nodi, a causa dell'efficienza di cassandra. Tuttavia, neo4j afferma che la ragione per cui non distribuiscono i dati tra i nodi, ma piuttosto duplica l'intero set di dati su ogni nodo, è perché qualsiasi attraversamento del grafo che lascia un nodo e quindi deve spostarsi attraverso una rete ethernet, è troppo lento per essere pratico.

Poiché cassandra non è a conoscenza del grafico, non può ottimizzare per mantenere gli attraversamenti grafici su un nodo. Pertanto, la maggior parte degli attraversamenti di grafici sarà oltre i confini dei nodi.

I titani sostengono di scalare in modo efficiente attraverso i nodi vero?

Answer 1

Titan determina l'ordine di ordinamento chiave del back-end di archiviazione sottostante (BOP per Cassandra, predefinito per HBase) e quindi assegna gli ID ai vertici in modo che i vertici assegnati allo stesso blocco di partizione abbiano identificativi assegnati allo stesso macchina. In altre parole, Titan "comprende" come il backend dello storage sottostante distribuisce i dati e utilizza tecniche di partizionamento grafico che sfruttano questa consapevolezza. Titan utilizza il partizionamento semi-automatico che incorpora la conoscenza del dominio.

Nel benchmark Pearson (http://arli.us/edu-planet-scale) il grafico è stato suddiviso in partizioni secondo le università, che è un criterio di partizionamento quasi ottimale per questo particolare set di dati. Senza partizionamento, il ridimensionamento a 120 miliardi di bordi sarebbe quasi impossibile.

Titan si basa su tecnologie collaudate (per scalabilità, persistenza, hot-backup, disponibilità, disaster recovery, ecc.) E innovazioni a livello grafico. Questa è la stessa strada che hanno preso sia il Flock di Twitter che il Tao di Facebook. Mentre questo significa che Titan è più lento a traversamenti molto profondi, consente a Titan di adattarsi a grafici molto grandi o a molte transazioni simultanee (lettura e scrittura).

Answer 2

Buona domanda. Penso che questo sia tutto merito della calibrazione. Twitter (che usa Cassandra) utilizza un database grafico in un modo molto specifico (hanno solo due livelli di "profondità"), quindi le query non devono attraversare grafici lunghi (e non sono obbligati a replicare l'intero set di dati). Penso che sia Titan sia Neo4j abbiano ragione, Neo4j prova a fornire un database grafico per scopi generali, quindi hai più soluzioni a seconda di come lo usi e non possono sapere come le persone lo utilizzeranno in modo che applichino la soluzione più comune : replica dell'intero set di dati.

Infatti, se non si replica l'intero set di dati e si desidera viaggiare lungo un percorso lungo nel grafico, sarà lento.

Quindi, quale sarà il vostro utilizzo? Non ho mai usato Titan ma un buon test sarebbe stato quello di confrontare le sue prestazioni con Neo4j a seconda della "profondità" delle query.