Il sito di social network probabilmente conserva tabelle per utenti, amici ed eventi ...In che modo i siti di social networking calcolano gli aggiornamenti degli amici?
Come usano queste tabelle per calcolare gli eventi di amici in modo efficiente e scalabile?
Molti dei siti di social networking come Twitter non utilizzare un RDBMS affatto, ma un'applicazione Message Queue. Molti di loro iniziano con un'applicazione già presente come RabbitMQ. Alcuni di loro diventano abbastanza grandi da dover personalizzarli o costruirli da soli. Twitter è in procinto di farlo per la seconda volta.
Un'applicazione di coda di messaggi funziona trattenendo i messaggi da un servizio per uno o più altri servizi. Ad esempio, diciamo che il servizio Frank sta pubblicando messaggi su una coda. Joe e Jill sono abbonati alla coda di Franks Foo. l'applicazione terrà traccia del fatto che Joe o Jill abbiano ricevuto o meno i messaggi e una volta che ogni sottoscrittore della coda ha ricevuto il messaggio che lo elimina. Frank spara messaggi e se ne dimentica. Joe e Jill chiedono messaggi da foo e ottengono tutti i messaggi che non hanno ancora ricevuto. Joe e Jill fanno tutto ciò che devono fare con il messaggio. Forse tenerlo in giro forse no.
L'applicazione di coda dei messaggi garantisce che tutti coloro che dovrebbero ricevere il messaggio possano ricevere il messaggio quando lo richiedono. L'editore può inviare messaggi sicuri che l'abbonato possa ottenerli alla fine. Questo ha il vantaggio di essere completamente asincrono e non richiede costosi join.
EDIT: Vorrei anche ricordare che di solito l'archiviazione per questo tipo di cose su larga scala è fortemente denormalizzata. Quindi Joe e Jill potrebbero conservare una copia dello stesso identico messaggio. Questo è considerato ok perché aiuta la scala dell'applicazione a miliardi di utenti.
altra lettura:
Per la piccola scala che fa un join su users.friends e users.events e query caching è probabilmente soddisfacente, ma rallenta abbastanza rapidamente man mano che gli amici e gli eventi crescono. Puoi anche provare un modello basato su eventi in cui ogni volta che un utente crea un evento viene creata una voce in una tabella di join (forse chiamata "friends_events"). Così ogni volta che un utente vuole vedere quali eventi hanno creato i propri amici, può semplicemente fare un join tra il proprio id e la tabella friends_events e scoprirlo. In questo modo eviti di afferrare tutti gli utenti con gli amici e poi unirti ai loro amici con la tabella degli eventi.
La struttura dei dati principali dei siti di social networking è lo graph. Su Facebook il grafico è diretto (quando sei amico di qualcuno, sei un amico). Su Twitter il grafico è diretto (segui qualcuno, ma non necessariamente ti seguono).
I due modi più comuni per rappresentare i grafici sono adjacency lists e adjacency matrices.
Un elenco di adiacenze è semplicemente un elenco di spigoli sul grafico. Considera un utente con un ID utente intero.
User1, User2
1 2
1 3
2 3
L'interpretazione non orientato di questi record è che l'utente 1 è diventato amico di utenti 2 e 3 e utente 2 è anche amica di utente 3.
Rappresentare questo in una tabella del database è banale. È la tabella di join delle relazioni da molti a molti che abbiamo familiarità con. Le query SQL per trovare gli amici di un determinato utente sono abbastanza facili da scrivere.
Ora che conosci gli amici di un determinato utente, è sufficiente unire questi risultati alla tabella degli aggiornamenti. Questa tabella contiene tutti gli aggiornamenti dell'utente indicizzati dall'ID utente.
Finché tutte queste tabelle sono correttamente indicizzate, si avrebbe un tempo abbastanza facile progettare query efficienti per rispondere alle domande che ti interessa.
Travis ha scritto un grande post su questo,
+1 per menzionare la denormalizzazione, questo non è ovvio al vecchio SQL wor ld dove 3NF è stata la stella guida per molto tempo. (Http://en.wikipedia.org/wiki/Third_normal_form) – Crypth