TL; DR:
Usano un'architettura di stack con grafici memorizzati nella cache per tutto ciò che si trova sopra il fondo MySQL del loro stack.
Risposta lunga:
Ho fatto delle ricerche su questo me stesso perché ero curioso di sapere come gestiscono la loro enorme quantità di dati e li cercano in modo rapido. Ho visto persone lamentarsi degli script dei social network su misura diventare lenti quando la base di utenti cresce. Dopo aver fatto un po 'di benchmarking con soli 10k utenti e 2,5 milioni di connessioni di amici - senza nemmeno provare a preoccuparmi delle autorizzazioni di gruppo, dei Mi piace e dei post sul muro - ho rapidamente scoperto che questo approccio è difettoso. Quindi ho trascorso un po 'di tempo a cercare sul web come farlo meglio e ho trovato questo articolo ufficiale di Facebook:
Ho davvero vi consiglio di guardare la presentazione del primo link qui sopra prima di continuare a leggere. È probabilmente la migliore spiegazione di come funziona FB dietro le quinte che puoi trovare.
Il video e l'articolo ti dicono alcune cose:
- Stanno usando MySQL in fondo al loro stack
- Sopra il DB SQL è presente il livello TAO che contiene almeno due livelli di memorizzazione nella cache e utilizza grafici per descrivere le connessioni.
- Non sono riuscito a trovare nulla su quale software / DB utilizzino effettivamente per i loro grafici memorizzati nella cache
Diamo un'occhiata a questo, le connessioni degli amici sono in alto a sinistra:
Bene, questo è un grafico. :) Non ti dice come costruirlo in SQL, ci sono diversi modi per farlo, ma questo sito ha una buona quantità di approcci diversi. Attenzione: considera che un DB relazionale è quello che è: si pensa che memorizzi dati normalizzati, non una struttura grafica. Quindi non funzionerà come un database grafico specializzato.
Considera anche che devi fare query più complesse rispetto ai soli amici di amici, ad esempio quando vuoi filtrare tutte le posizioni intorno a una data coordinata che piacciono a te e ai tuoi amici di amici. Un grafico è la soluzione perfetta qui.
Non posso dirti come costruirlo in modo che funzioni bene, ma richiede chiaramente alcune prove, errori e benchmark.
Ecco il mio test deludente per i risultati solo amici di amici:
Schema DB:
CREATE TABLE IF NOT EXISTS `friends` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`friend_id` int(11) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
Query di Friends of Friends:
(
select friend_id
from friends
where user_id = 1
) union (
select distinct ff.friend_id
from
friends f
join friends ff on ff.user_id = f.friend_id
where f.user_id = 1
)
Ti consiglio vivamente di crearti alcuni dati di esempio con almeno 10k record utente e ciascuno di essi con almeno 250 connessioni amico e quindi eseguire questa query. Sul mio computer (i7 4770k, SSD, 16 GB di RAM) il risultato è stato di ~ 0,18 secondi per quella query. Forse può essere ottimizzato, non sono un genio del DB (i suggerimenti sono ben accetti). Tuttavia, se questo scala lineare sei già a 1,8 secondi per soli 100k utenti, 18 secondi per 1 milione di utenti.
Questo potrebbe ancora sembrare OKish per ~ 100.000 utenti, ma considera che hai appena recuperato amici di amici e non hai fatto alcuna query più complessa come " mostrami solo post di amici di amici + fai il permesso di controllare se sono autorizzato o NON permesso per vederne alcuni + fai una sottointerrogazione per verificare se mi è piaciuto qualcuno di loro ". Vuoi lasciare che il DB faccia il check-in se ti è già piaciuto o meno un post o dovrai farlo nel codice. Considera anche che questa non è l'unica query che esegui e che hai più di un utente attivo contemporaneamente su un sito più o meno popolare.
Penso che la mia risposta risponda alla domanda su come Facebook abbia progettato molto bene la relazione dei loro amici, ma mi dispiace di non poterti dire come implementarlo in modo che funzioni velocemente. L'implementazione di un social network è facile ma assicurarsi che funzioni bene non lo è chiaramente - IMHO.
Ho iniziato a sperimentare OrientDB per eseguire le query sui grafici e mappare i miei bordi sul database SQL sottostante. Se mai lo avessi fatto, scriverò un articolo a riguardo.
