Database relazionale vs Graph per reti (inizialmente) di dimensioni moderate

Question

Database relazionale vs Graph per reti (inizialmente) di dimensioni moderate

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

3

Stiamo sviluppando un'applicazione il cui dominio dei dati (o almeno il 90% di esso) può essere modellato efficacemente utilizzando un database relazionale. Abbiamo usato PostgreSQL sin dall'inizio e non ho avuto alcun problema. Tuttavia, ora sorge la necessità di memorizzare le relazioni (amicizie) tra gli utenti, proprio come Facebook o Snapchat, e iniziamo a chiederci quale dei seguenti due percorsi sia preferibile:

Inizia memorizzando le amicizie in una tradizionale tabella delle relazioni in PostgreSQL e finiscila con i problemi di scalabilità (ovvero la crescita del numero di amicizie e delle infami "amichevoli").
Avvia in anticipo con un database grafico ( TitanDB + Cassandra ) solo per essere pronto quando sorge la necessità di scalare, ma affrontare una startup più lenta nello sviluppo (che include informazioni su TitanDB e Cassandra ).

Il nostro obiettivo è ~ 75 milioni di utenti. Non abbiamo davvero un'idea su quali query avremo bisogno di eseguire su questo "grafico" - per ora, la nostra unica necessità è quella di memorizzare queste informazioni. PostgreSQL potrebbe scalare efficacemente tali numeri? È preferibile seguire l'approccio del grafico in anticipo?

postgres graph-databases big-data

posta Tony E. Stark 03.02.2016 - 18:53

fonte

3 risposte

Leggi altre domande sui tag postgres graph-databases big-data

Come perfezionare l'architettura, cercare soluzioni migliori e non rovinare il rapporto con il team? Risoluzione dell'immagine in un'interfaccia RESTful

score 3 · Answer 1

Il successo del tuo progetto dipenderà molto di più dalle funzionalità che metti di fronte agli utenti che riesci ad attirare. Per ora, ti suggerirei di dare la priorità a ciò. Dopotutto, se non raggiungi 75 milioni di utenti, non avrai comunque un problema di scalabilità, quindi lo sforzo sarebbe sprecato.

Per esprimere questo concetto in modo diverso, i problemi di scalabilità seguono da grandi livelli di adozione. Il tuo primo problema è l'adozione. Lavoraci prima. Se non lavori su cose che recluteranno utenti, il tuo progetto fallirà e il problema della scalabilità sarà discutibile.

score 2 · Answer 2

La maggior parte delle applicazioni web utilizza una combinazione di tecnologie per scalare. Puoi avere sia un database relazionale per archiviare i dati degli utenti e sfruttare l'aggregazione e le funzioni di intersecazione veloce + un grafico db per i gadget dei grafici.

Nel database dei grafici non si memorizzano solo amicizie, ma si possono anche memorizzare Mi piace, flussi, condivisioni in modo da poter vedere non solo le domande degli amici, ma anche quelle che gli amici hanno apprezzato.

Assicurati di controllare OrientDB e Neo4j .

score 1 · Answer 3

PostgreSQL si adatta meravigliosamente nelle giuste condizioni:

Digital Globe gestisce realmente 1 miliardo di transazioni almeno ogni ora nel proprio database con PGGIS per l'avvio
Verizon utilizza PostgreSQL come archivio dati
È stato dimostrato che il formato jsonb di PostgreSQL è più veloce di MonogDB, più si ottiene un formato relazionale

Il problema riguarda le relazioni dinamiche. Hai davvero bisogno di considerare le relazioni che immagazzini dato che è ciò che è un grafico, nodi con bordi. Se hai una tabella di ricerca per tutto e ti stai avvicinando a 6NF invece di archiviare grandi blocchi di record, usa Neo4J. Usiamo PostgreSQL e Neo4j e i backup in realtà non sono un problema. Stiamo cercando un modo per esportare Neo4J in PostgreSQL, il che renderebbe i backup super facili, dal momento che puoi facilmente migrare da PostgreSQL a Neo4j. Dati utente, meta dati delle applicazioni e degli utenti, blocchi di record di grandi dimensioni con solo poche ricerche e altri dati simili con relazioni di facile utilizzo predefinite sono archiviati in PostgreSQL. Neo4J è usato per dati grafici, dati con una tonnellata di relazioni, spesso definite dinamicamente.