M-am întrebat întotdeauna cum Facebook a proiectat prietenul <-> relație de utilizator.
Eu dau masa de utilizator este ceva de genul:
user_email PK
user_id PK
password
Am figura tabelul cu datele utilizatorului (sex, vârstă etc conectate prin e-mail de utilizator mi-ar asuma).
Cum se conectează toți prietenii acestui utilizator?
Ceva de genul?
user_id
friend_id_1
friend_id_2
friend_id_3
friend_id_N
Probabil ca nu. Deoarece numărul de utilizatori este necunoscut și se va extinde.
Este cel mai probabil un multe pentru mai multe relații:
FriendList (tabel)
user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel
EDITAȚI | ×
Tabelul de utilizator , probabil , nu are USER_EMAIL ca PK, eventual , ca o cheie unică , deși.
utilizatori (tabel)
user_id PK
user_email
password
Păstrați un tabel prieten care deține IDutilizator și apoi IDutilizator prietenului (vom numi FriendID). Ambele coloane ar fi cheile străine înapoi la masa de utilizatori.
exemplu oarecum folositoare:
Table Name: User
Columns:
UserID PK
EmailAddress
Password
Gender
DOB
Location
TableName: Friends
Columns:
UserID PK FK
FriendID PK FK
(This table features a composite primary key made up of the two foreign
keys, both pointing back to the user table. One ID will point to the
logged in user, the other ID will point to the individual friend
of that user)
Exemplu de utilizare:
Table User
--------------
UserID EmailAddress Password Gender DOB Location
------------------------------------------------------
1 bob@bob.com bobbie M 1/1/2009 New York City
2 jon@jon.com jonathan M 2/2/2008 Los Angeles
3 joe@joe.com joseph M 1/2/2007 Pittsburgh
Table Friends
---------------
UserID FriendID
----------------
1 2
1 3
2 3
Acest lucru va arăta că Bob este prieten cu atât Jon și Joe și că Jon este, de asemenea, prieteni cu Joe. În acest exemplu, vom presupune că prietenia este întotdeauna două moduri, astfel încât să nu ar avea nevoie de un rând în tabel, cum ar fi (2,1) sau (3,2), deoarece acestea sunt deja reprezentate în cealaltă direcție. Pentru exemple în cazul în care prietenia sau alte relații nu sunt în mod explicit cu două căi, ar trebui să aibă, de asemenea, aceste rânduri pentru a indica două sensuri relația.
Cel mai bun pariu mea este că au creat o structură de grafic . Nodurile sunt utilizatori și „prietenii“ sunt margini.
Păstrați o masă de utilizatori, păstrează un alt tabel de margini. Apoi, puteți păstra datele despre margini, cum ar fi „zi au devenit prieteni“ și „statutul aprobat“ etc.
Cauți chei străine. Practic nu se poate avea o matrice într-o bază de date, cu excepția cazului nu are masa de ea proprii.
utilizatorii Tabelul
PK UserID
alte date
prieteni Tabelul
UserID - FK la masa ale utilizatorilor care reprezintă utilizatorul care are un prieten.
friendID - FK la masa utilizatorilor care reprezintă utilizator id-ul prietenului Rețineți că tabelele de baze de date sunt proiectate să crească pe verticală (mai multe rânduri), nu pe orizontală (mai multe coloane)
Aruncati o privire la aceste articole care descriu modul în care sunt construite pe LinkedIn și Digg:
Există, de asemenea, „Big Data: Puncte de vedere de date Echipa de Facebook“, care ar putea fi de ajutor:
De asemenea, există acest articol care vorbește despre bazele de date non-relaționale și modul în care acestea sunt utilizate de unele companii:
http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
Vei vedea că aceste companii se ocupă cu depozite de date, baze de date partiționate, cache de date și alte concepte de nivel mai înalt decât majoritatea dintre noi nu face pe o bază de zi cu zi. Sau, cel puțin, poate că noi nu știm că noi facem.
Există o mulțime de link-uri de pe primele două articole care ar trebui să vă dau câteva mai multe detalii.
UPDATE 10/20/2014
Murat Demirbaș a scris un rezumat privind
http://muratbuffalo.blogspot.com/2014/10/facebooks-software-architecture.html
HTH
În ceea ce privește performanța unui tabel de mulți la mai mulți, dacă aveți 2 Ints pe 32 de biți care leagă ID-urile de utilizator, spațiul de stocare a datelor de bază pentru 200,000,000 utilizatorii 200 de prieteni în medie de căciulă este doar sub 300GB.
Evident, ai nevoie de partiționare și indexare și nu o să păstrați în memorie pentru toți utilizatorii.
Au o privire la următoarea schemă de baze de date, inginerie inversă de Anatoli Lubarsky :
Nu este posibil pentru a prelua date de la RDBMS pentru datele de utilizator pentru prietenii date care traversează mai mult de o jumătate de miliard de la un timp constant, astfel Facebook a implementat acest lucru, folosind o bază de date hash (fără SQL) și opensourced baza de date numita Cassandra.
Deci, fiecare utilizator are propria sa cheie și detaliază prietenii într-o coadă; să știe cum arată lucrări Cassandra la aceasta:
Este un tip de bază de date grafic: http://components.neo4j.org/neo4j-examples/1.2-SNAPSHOT/social-network.html
Ei nu sunt legate de bazele de date relationale.
Google pentru baze de date grafic.
Probabil că există un tabel, care stochează prietenul <-> relație de utilizator, spune „frnd_list“, având în câmpuri „user_id“, „frnd_id“.
De fiecare dată când un utilizator adaugă un alt utilizator ca prieten, sunt create două rânduri noi.
De exemplu, să presupunem că id meu este „deep9c“ și am adăuga un identificator de utilizator cu „akash3b“ ca prietenul meu, apoi două rânduri noi sunt create în tabelul „frnd_list“ cu valori ( „deep9c“, „akash3b“) și ( "akash3b “, 'deep9c').
Acum, când prietenii arată-lista de la un anumit utilizator, un simplu sql ar face acest lucru: „selectați frnd_id din frnd_list în cazul în care user_id =“ în cazul în care este ID-ul de utilizator conectat (stocate ca o sesiune-atribut).
Acest recent post-iunie 2013 intră în câteva detalii în a explica tranziția de la bazele de date relaționale la obiecte cu asociații pentru anumite tipuri de date.
https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-graph/10151525983993920
Există o hârtie mai fie disponibil la https://www.usenix.org/conference/atc13/tao-facebook's-distributed-data-store-social-graph
TL; DR:
Ei folosesc o arhitectura stivă cu grafice stocate în memoria cache pentru tot mai sus în partea de jos a MySQL stiva lor.
Raspuns lung:
Am făcut niște cercetări pe această mine pentru că am fost curios modul în care acestea se ocupe de valoarea lor foarte mare de date și de căutare într - un mod rapid. Am văzut oameni plângându personalizate script - uri de rețele sociale devine lent atunci când baza de utilizatori crește. După ce am făcut unele eu evaluarea comparativă cu doar 10k utilizatori și 2,5 milioane de prietenul conexiuni - nici măcar nu încearcă să deranjeze despre permisiunile și gusturilor de grup și posturi de perete - sa dovedit repede că această abordare este eronată. Așa că am petrecut ceva timp în căutarea pe web cu privire la modul de a face mai bine și a venit peste acest articol oficial Facebook:
Eu într - adevăr vă recomandăm să urmăriți prezentarea primului link - ul de mai sus înainte de a continua lectura. Este , probabil , cea mai bună explicație a modului în care funcționează FB în spatele scenei puteți găsi.
Video și articol vă spune câteva lucruri:
Să aruncăm o privire la acest lucru, legături de prietenie sunt stânga sus:
Ei bine, acest lucru este un grafic. :) Nu vă spune cum să - l construiască în SQL, există mai multe moduri de a face acest lucru , dar acest site are o cantitate bună de abordări diferite. Atenție: Luați în considerare faptul că o DB relațională este ceea ce este: Se crede ca pentru a stoca date normalizate, nu o structură grafic. Deci, nu se va efectua la fel de bun ca și o bază de date grafic specializat.
De asemenea, considerăm că trebuie să faci interogări mai complexe decât doar prieteni de prieteni, de exemplu, atunci când doriți să filtrați toate locațiile în jurul unei coordonate pe care tu și prietenii tăi de prieteni, cum ar fi. Un grafic este soluția perfectă aici.
Nu pot să vă spun cum să-l construiască astfel încât acesta va funcționa bine, dar necesită în mod clar o anumită încercare și eroare și analiza comparativă.
Aici este meu dezamăgitor test pentru doar constatări prietenii prietenilor:
DB schemă:
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;
Prietenii prietenilor interogare:
(
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
)
Chiar recomandăm să creați unele date eșantion cu cel puțin 10k înregistrări ale utilizatorilor și fiecare dintre ele având cel puțin 250 de legături de prietenie și apoi executați această interogare. Pe masina mea (4770k i7, SSD, RAM de 16 GB) , rezultatul a fost de ~ 0.18 secunde pentru acea interogare. Poate că poate fi optimizat, eu nu sunt un geniu DB (sugestii sunt binevenite). Cu toate acestea, în cazul în care această cântare liniar esti deja la 1,8 secunde pentru doar 100k utilizatori, 18 secunde pentru 1 milion de utilizatori.
Acest lucru ar putea suna în continuare OKish pentru utilizatorii ~ 100k dar consideră că sunteți doar prieteni preluate de prieteni și nu a făcut nici o interogare mai complexe cum ar fi " afișează - mi doar mesajele de la prietenii prietenilor + face verificarea permisiunea dacă am voie sau nu este permisa pentru a vedea unele dintre ele + face o interogare de sub pentru a verifica dacă mi -a plăcut nici una dintre ele “. Vrei să lase PB face verificarea dacă ți -a plăcut pe un post deja sau nu , sau va trebui să facă în cod. De asemenea , consideră că acest lucru nu este singura interogare executată și că dvs. au mai mult de utilizator activ, în același timp , pe un site mai mult sau mai puțin popular.
Cred că răspunsul meu răspunde la întrebarea cum Facebook proiectat relația lor prieteni foarte bine, dar îmi pare rău că nu vă pot spune cum să-l pună în aplicare într-un mod va funcționa rapid. Implementarea unei rețele sociale este ușor, dar asigurându-vă că funcționează bine, nu este în mod clar - IMHO.
Am început să experimenteze OrientDB să facă graficul-interogări și cartografiere marginile mele PB SQL care stau la baza. Dacă am vreodată făcut-o să scrie un articol despre asta.