Confronto tra database relazionali e database a grafo

Qualcuno può spiegarmi i vantaggi e gli svantaggi di un database di relazioni come MySQL rispetto a un database a grafo come Neo4j?

In SQL hai più tabelle con vari ID che le collegano. Quindi devi unirti per collegare i tavoli. Dal punto di vista di un principiante, perché dovresti progettare il database per richiedere un join piuttosto che avere le connessioni esplicite come bordi dall'inizio come con un database a grafo. Concettualmente non avrebbe senso per un principiante. Presumibilmente c'è una ragione molto tecnica ma non concettuale per questo?

In realtà c'è un ragionamento concettuale dietro entrambi gli stili. Wikipedia sul modello relazionale e sui database a grafo fornisce una buona panoramica di questo.

La differenza principale è che in un database a grafo le relazioni vengono memorizzate a livello di record individuale, mentre in un database relazionale la struttura è definita a un livello superiore (le definizioni di tabella).

Ciò ha importanti ramificazioni:

• Un database relazionale è molto più veloce quando si opera su un numero enorme di record. In un database a grafo, ogni record deve essere esaminato individualmente durante una query per determinare la struttura dei dati, mentre questo è noto in anticipo in un database relazionale.
• I database relazionali utilizzano meno spazio di archiviazione, perché non devono archiviare tutte queste relazioni.

Memorizzare tutte le relazioni a livello di record individuale ha senso solo se ci saranno molte variazioni nelle relazioni; altrimenti stai semplicemente duplicando le stesse cose più e più volte. Ciò significa che i database a grafo sono adatti a strutture irregolari e complesse. Ma nel mondo reale, la maggior parte dei database richiede strutture regolari e relativamente semplici. Questo è il motivo per cui predominano i database relazionali.

La differenza fondamentale tra un grafico e un database relazionale è che i database relazionali funzionano con gli insiemi mentre i database grafici funzionano con i percorsi.

Questo si manifesta in modi inaspettati e inutili per un utente RDBMS. Ad esempio, quando si tenta di emulare operazioni sui percorsi (ad esempio amici di amici) unendosi in modo ricorsivo a un database relazionale, la latenza delle query cresce in modo imprevedibile e massiccio così come l'utilizzo della memoria, per non parlare del fatto che tortura SQL per esprimere quel tipo di operazioni. Più dati significa più lento in un database basato su set, anche se puoi ritardare il problema attraverso un'indicizzazione giudiziosa.

Come ha accennato Dan1111, la maggior parte dei database a grafo non soffre di questo tipo di join pain perché esprimono relazioni a un livello fondamentale. Cioè, le relazioni esistono fisicamente sul disco e sono denominate, dirette e possono essere esse stesse decorate con proprietà (questo è chiamato il modello del grafico delle proprietà, vedere: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Modello ). Ciò significa che, se lo si sceglie, è possibile esaminare le relazioni sul disco e vedere come "uniscono" le entità. Le relazioni sono quindi entità di prima classe in un database a grafo e sono semanticamente molto più forti di quelle relazioni implicite reificate in fase di esecuzione in un archivio relazionale.

Allora perché dovrebbe interessarti? Per due ragioni:

1. I database a grafo sono molto più veloci dei database relazionali per i dati connessi, un punto di forza del modello sottostante. Una conseguenza di ciò è che la latenza della query in un database di grafici è proporzionale alla quantità di grafico che si sceglie di esplorare in una query e non è proporzionale alla quantità di dati memorizzati, disinnescando così la bomba di join .
2. I database di grafici rendono la modellazione e l'interrogazione molto più piacevoli, il che significa uno sviluppo più veloce e meno momenti WTF. Ad esempio, esprimere l'amico di un amico per un tipico social network nel linguaggio di query Cypher di Neo4j è giusto MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 ha già fornito una risposta contrassegnata come corretta. Vale la pena notare di sfuggita un paio di punti aggiuntivi.

Innanzitutto, in quasi tutte le implementazioni di database a grafo, i record vengono "bloccati" perché esiste un numero sconosciuto di puntatori che puntano al record nella sua posizione corrente. Ciò significa che un record non può essere spostato in una nuova posizione senza lasciare un indirizzo di inoltro nella vecchia posizione o interrompere un numero sconosciuto di puntatori.

Teoricamente, si potrebbero mescolare tutti i record contemporaneamente e trovare un modo per individuare e riparare tutti i puntatori. In pratica si tratta di un'operazione che potrebbe richiedere settimane su un database di grandi dimensioni, durante le quali il database dovrebbe essere spento. Semplicemente non è fattibile.

Al contrario, in un database relazionale, i record possono essere rimescolati su una scala abbastanza ampia e l'unica cosa che deve essere fatta è ricostruire tutti gli indici che sono stati interessati. Questa è un'operazione abbastanza grande, ma neanche lontanamente grande come l'equivalente di un database a grafo.

Il secondo punto degno di nota è che il world wide web può essere visto come un gigantesco database a grafo. Le pagine Web contengono collegamenti ipertestuali e riferimenti a collegamenti ipertestuali, tra le altre cose, altre pagine Web. Il riferimento avviene tramite URL, che funzionano come puntatori.

Quando una pagina Web viene spostata su un URL diverso senza lasciare un indirizzo di inoltro al vecchio URL, un numero sconosciuto di collegamenti ipertestuali verrà interrotto. Questi collegamenti interrotti danno quindi origine al temuto messaggio "Errore 404: pagina non trovata" che interrompe il piacere di tanti navigatori.

Con un database relazionale possiamo modellare e interrogare un grafico utilizzando chiavi esterne e auto-join. Solo perché RDBMS contiene la parola relazionale non significa che siano bravi a gestire le relazioni. La parola relazionale in RDBMS deriva dall'algebra relazionale e non dalla relazione. In un RDBMS, la relazione stessa non esiste come oggetto a sé stante. Deve essere rappresentato esplicitamente come chiave esterna o implicitamente come valore in una tabella di collegamento (quando si utilizza un approccio di modellazione generico / universale). I collegamenti tra i set di dati vengono memorizzati nei dati stessi.

Più aumentiamo la profondità di ricerca in un database relazionale, più auto-join dobbiamo eseguire e più ne risentono le prestazioni delle query. Più in profondità andiamo nella nostra gerarchia, più tabelle dobbiamo unire e più lenta diventa la nostra query. Matematicamente il costo cresce in modo esponenziale in un database relazionale. In altre parole, più complesse sono le nostre query e relazioni, più beneficiamo di un grafico rispetto a un database relazionale. Non abbiamo problemi di prestazioni in un database di grafici durante la navigazione nel grafico. Questo perché un database a grafo memorizza le relazioni come oggetti separati. Tuttavia, le prestazioni di lettura superiori vengono a scapito di scritture più lente.

In alcune situazioni è più facile cambiare il modello di dati in un database a grafo che in un RDBMS, ad esempio in un RDBMS se cambio una relazione di tabella da 1: ne m: n devo applicare DDL con potenziali tempi di inattività.

RDBMS ha invece vantaggi in altre aree, ad esempio aggregando i dati o effettuando il controllo della versione timestamp sui dati.

Discuto alcuni degli altri pro e contro nel mio post sul blog database a grafo per il data warehousing

Mentre il modello relazionale può facilmente rappresentare i dati contenuti in un modello grafico, nella pratica dobbiamo affrontare due problemi significativi:

1. SQL non ha la sintassi per eseguire facilmente l'attraversamento del grafico, specialmente gli attraversamenti in cui la profondità è sconosciuta o illimitata. Ad esempio, usare SQL per determinare gli amici dei tuoi amici è abbastanza facile, ma è difficile risolvere il problema dei "gradi di separazione".
2. Le prestazioni peggiorano rapidamente mentre attraversiamo il grafico. Ogni livello di attraversamento aumenta notevolmente il tempo di risposta alle query.

Riferimento: database di nuova generazione

Vale la pena indagare sui database a grafo per i casi d'uso in cui eccellono, ma ho avuto qualche motivo per mettere in discussione alcune affermazioni nelle risposte sopra. In particolare:

Un database relazionale è molto più veloce quando si opera su un numero enorme di record (primo punto elenco di dan1111)

I database a grafo sono molto più veloci dei database relazionali per i dati connessi, un punto di forza del modello sottostante. Una conseguenza di ciò è che la latenza della query in un database a grafo è proporzionale a quanto del grafico si sceglie di esplorare in una query e non è proporzionale alla quantità di dati memorizzati, disinnescando così la bomba di join. (Primo punto elenco di Jim Webber)

In altre parole, più complesse sono le nostre query e relazioni, più beneficiamo di un grafico rispetto a un database relazionale. (2 ° paragrafo di Uli Bethke)

Sebbene queste affermazioni possano avere valore, devo ancora trovare un modo per far sì che il mio caso d'uso specifico si allinei con esse. Riferimento: Database grafico o Database relazionale Estensioni di tabelle comuni: confronto delle prestazioni delle query di grafi aciclici