Database di documenti ArangoDB e anche un database di grafici? Come è possibile?

Question

Qualcuno potrebbe spiegare come funziona anche un database di documenti come database di grafici?

Qual è la differenza tra ArangoDB e Neo4j?

Answer 1

Disclaimer: I am Max di ArangoDB, uno degli sviluppatori principali.

Prima di tutto, una discussione più lunga su questa e altre domande correlate si trova nel mio articolo Graphs in data modeling - is the emperor naked?, ma cercherò di rispondere a entrambe le domande in modo conciso qui.

(1) Memorizzare un grafico in un archivio di documenti è relativamente semplice (come in un database relazionale), per esempio è sufficiente memorizzare un documento per ogni vertice in una "raccolta di vertici" e un documento per ogni bordo in una "collezione di bordi". Basta fare in modo che ogni margine memorizzi da quale vertice provenga e a quale vertice vada. In ArangoDB utilizziamo gli attributi _from e _to nel documento edge per questo.

Tuttavia, la funzionalità cruciale per un database di grafici è che è necessario rispondere alle query sui grafici in modo efficiente. Le query tipiche per i grafici sono (a) "quali sono i vicini di un vertice nel grafico?" o (b) "qual è il percorso più breve dal vertice A al vertice B nel grafico?" oppure (c) "dammi tutti i vertici che posso raggiungere dal vertice A seguendo i bordi". Considerando che (a) semplicemente ha bisogno di un buon indice sulla raccolta degli spigoli, (b) e (c) coinvolgono un numero di passi a priori sconosciuto nel grafico. Pertanto, (b) e (c) non possono essere eseguiti in modo efficiente con i tradizionali linguaggi di query del database come SQL, semplicemente perché comportano una grande quantità di comunicazione tra client e server, o per lo meno un'espressione molto complicata con un numero variabile di join. Io chiamo query come (b) e (c) quindi "graphy", senza definirlo rigorosamente.

Pertanto, la mia breve risposta a "in che modo un archivio di documenti può essere un database di grafici?" è: archiviare il grafico come sopra e implementare query graphy nel server database, accessibile dal linguaggio di query dell'archivio dati. In linea di principio, lo stesso potrebbe essere fatto con un database relazionale e alcune notevoli estensioni di SQL.

Con ArangoDB siamo riusciti a combinare il documento, il grafico e le caratteristiche chiave/valore in un unico linguaggio di query coerente. Pertanto, chiamiamo ArangoDB un "database multi-modello", poiché combina perfettamente questi tre modelli di dati. Puoi persino mescolare i modelli di dati in una singola query!

Questo porta verso la mia risposta alla domanda (2), che è ovviamente un po 'prevenuto:

Rispetto al ArangoDB, che è un database multi-modello distribuito, nel senso di cui sopra, Neo4j è un grafico classica Banca dati. Memorizza i grafici, consente di interrogarli con "query graphy" e dispone di un motore di archiviazione e di query ottimizzato per questo. Neo4j è particolarmente adatto a tracciare percorsi utilizzando la sua crittografia del linguaggio di query incorporata. Permette di collegare le proprietà ai vertici e ai bordi, ma non è un archivio di documenti completo. Non è ottimizzato per gestire query di documenti che utilizzano più indici secondari né join. Inoltre, Neo4j non è distribuito.

Neo4j è scritto in Java, ArangoDB è scritto in C++ e incorpora il V8 di Google per eseguire estensioni JavaScript.

Per un confronto delle prestazioni, vedere this post.