Progettare un social network con CQRS, database grafici e database relazionali in mente

Question

Progettare un social network con CQRS, database grafici e database relazionali in mente

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

2

Ho svolto un bel po 'di ricerche sull'argomento fino ad ora, ma non sono riuscito a trovare una conclusione da prendere in considerazione.

Sto progettando un social network e durante la mia ricerca mi sono imbattuto in database di grafici, ho trovato neo4j piuttosto interessante per le relazioni con gli utenti e il passaggio attraverso i nodi. Ho anche pensato di utilizzare un database relazionale come MS-SQL o MySQL per archiviare solo i dati delle entità e in base a neo4j per le connessioni tra entità. Ovviamente questo significa più lavoro nella mia applicazione per archiviare e tirare dati dentro e fuori da 2 fonti diverse.

La mia prima domanda: utilizzo questo approccio (grafico + relazionale) un buon approccio per progettare il mio social network tenendo presente che gli utenti sui social network non devono necessariamente sincronizzarsi con i dati reali di secondo in secondo piano? Quali sono i lati positivi e negativi di questo approccio?

La mia seconda domanda: ho letto alcune letture su CQRS e, come ho capito, è utile soprattutto per ambienti collaborativi e ambienti in cui gli utenti vedono molti dati "obsoleti". i social network hanno condiviso commenti, eventi, ecc. e molti utenti interrogano o aggiornano gli stessi dati. Potrebbe CQRS essere un approccio utile? Fornirebbe vantaggi in termini di prestazioni / scalabilità o complessità non utile? E 'abbastanza applicabile con la mia possibile scelta di approccio di database (grafico + relazionale) menzionato nella domanda sopra?

Il mio scopo è sapere se gli approcci che ho menzionato sopra sembrano abbastanza buoni per il contesto aziendale.

architecture architectural-patterns cqrs graph-databases social-networks

posta Siraj Mansour 27.05.2014 - 15:01

fonte

2 risposte

Leggi altre domande sui tag architecture architectural-patterns cqrs graph-databases social-networks

Esiste un modello di progettazione per evitare riferimenti ciondolanti? Come essere Agile quando un nuovo lavoro continua a influire sul lavoro completato?

score 3 · Answer 1

Ti peserò con alcune brevi riflessioni.

Argomento 1 : i database dei grafici sono validi per la modellazione / query delle gerarchie. Dì che nella tua app social vuoi far sapere agli utenti se qualcuno dei loro amici - o qualcuno dei loro amici di amici - ha un compleanno oggi. Questa può essere una domanda enorme se stai ricoprendo tutti i livelli di Amici. Un database grafico dovrebbe farlo meglio di un database relazionale.

Tuttavia, un database relazionale è molto utile in molte altre cose, quindi potresti prendere in considerazione l'utilizzo di entrambi: relazionale per scopi generali e grafico per scopi speciali.

Argomento 2 : CQRS è un'architettura che aiuta con sistemi altamente concorrenti. In breve, scrive è considerato un problema diverso rispetto a letture . Le scritture tipicamente vengono inserite in una coda (fire &; forget) e rilevate quando il sistema è in grado / in modo bilanciato dal carico. Se si verifica un errore come un deadlock, la richiesta di scrittura rimane in coda e viene ritentata fino a quando non si spera (si spera) (questa è "coerenza finale").

score 3 · Answer 2

Secondo me, stai sovrastimando il progetto. Penso che tu lo faccia perché ritieni di dover fare affidamento su tecniche all'avanguardia per gestire la scala aziendale, ma in molti casi starai meglio affidandoti a tecniche collaudate e innovando solo in un ambito molto focalizzato.

Una parola di cautela sui database dei grafici: nella mia esperienza, promettono più di quanto possano offrire. La mia esperienza è ora di alcuni anni fa, quindi non posso dirti se sono maturati come prodotti; ma vuoi scoprire se qualcosa si ridimensiona usando il tuo cavallo di battaglia principale?

Lasciatemi notare che ci sono alcune alternative per tali algoritmi di grafi, alcuni dei quali con scalabilità dimostrabile perché si basano su HDFS di Hadoop: guarda questo thread SO o questa libreria Spark .

Sull'argomento di CQRS, sembra trattare il tipo di problemi che i grandi siti Web gestiscono tradizionalmente con un livello di cache in cima ai loro set di repliche di database. Scrivi un wrapper attorno alle tue query che prima guardano nel livello della cache, e se questo manca il suo segno, quindi estrae i dati dal database e scrive anche il set di risultati nella cache. Ecco un semplice esempio in Python .

Inoltre, suddividere le query in Comandi e Query su due motori di database significa che devi decidere, per ogni richiesta utente, se si tratta di grafi o meno, e se scrive o legge qualcosa; di solito avrai un mix di tutte e quattro le possibilità. Se prendi le tue decisioni giuste, otterrai un social network più veloce e più reattivo; ma tieni presente che otterrai lo stesso incremento delle prestazioni prendendo le giuste decisioni in quasi tutte le lingue e i runtime. E anche così, i tempi di risposta saranno quasi certamente dominati dalla latenza della rete.

Al posto tuo, mi concentrerei su uno di questi due argomenti e mi concentrerei anche di più sulla domanda: cosa consente questa tecnica di migliorare rispetto ai siti di social networking esistenti?