Jeg har alltid lurt på hvordan Facebook utformet venn <-> user forhold.
Jeg finne brukertabellen er noe sånt som dette:
user_email PK
user_id PK
password
I figuren bordet med brukerens data (kjønn, alder osv koblet via brukerens e-I vil anta).
Hvordan føles det å koble alle venner til denne brukeren?
Noe sånt som dette?
user_id
friend_id_1
friend_id_2
friend_id_3
friend_id_N
Sannsynligvis ikke. Fordi antall brukere er ukjent og vil utvide.
Det er mest sannsynlig en mange til mange relasjon:
Friend (tabell)
user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel
REDIGERE
Brukertabellen sannsynligvis ikke har user_email som PK, muligens som en unik nøkkel skjønt.
Brukerne (tabell)
user_id PK
user_email
password
Hold en venn tabell som holder BrukerID og deretter BrukerID til vennen (vi vil kalle det FriendID). Begge kolonner ville være fremmednøkler i brukergruppen tabellen.
Noe nyttig eksempel:
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)
Eksempel på bruk:
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
Dette vil vise at Bob er venner med både Jon og Joe og at Jon er også venner med Joe. I dette eksempelet vil vi anta at vennskap er alltid to måter, slik at du ikke ville ha en rad i tabellen som (2,1) eller (3,2) fordi de allerede er representert i den andre retningen. For eksempler der vennskap eller andre relasjoner ikke er eksplisitt toveis, ville du trenger å også ha de radene for å indikere toveis forhold.
Mitt beste tips er at de opprettet en graf struktur . Nodene er brukere og "venn" er kantene.
Hold en tabell med brukere, holde et annet bord kanter. Deretter kan du holde data om kantene, som "dagen de ble venner" og "godkjent status," etc.
Du leter etter fremmednøkler. I utgangspunktet kan du ikke ha en rekke i en database med mindre det har sin egen tabell.
brukere Table
brukerID PK
andre data
venner Table
brukerID - FK til brukerne menn tabellen representerer brukeren som har en venn.
friendID - FK til brukernes tabellen representerer brukerens id av venn Husk at databasetabeller er designet for å vokse vertikalt (flere rader), ikke horisontalt (flere kolonner)
Ta en titt på disse artiklene beskriver hvordan Linkedin og Digg er bygget:
Det finnes også "Big Data: Utsiktspunkt fra Facebook data Team" som kan være nyttig:
Det er også denne artikkelen som snakker om ikke-relasjonsdatabaser og hvordan de brukes av enkelte selskaper:
http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
Du vil se at disse selskapene arbeider med datavarehus, partisjonert databaser, data caching og andre høyere nivå konsepter enn de fleste av oss aldri forholde seg til på en daglig basis. Eller i det minste, kanskje vi ikke vet at vi gjør.
Det er mange linker på de to første artiklene som burde gi deg litt mer innsikt.
UPDATE 10/20/2014
Murat Demirbaş skrev et sammendrag på
http://muratbuffalo.blogspot.com/2014/10/facebooks-software-architecture.html
HTH
Når det gjelder ytelsen til en mange-til-mange bord, hvis du har 2 32-bits ints linke bruker-ID, den grunnleggende datalagring for 200.000.000 brukere i snitt 200 venner stykket er like under 300 GB.
Selvfølgelig ville du trenger noen partisjonering og indeksering, og du kommer ikke til å holde det i minne for alle brukere.
Har en titt på følgende databaseskjema, omvendt utvikling av Anatoly Lubarsky :
Det er ikke mulig å hente data fra RDBMS for bruker venner data for data som krysser mer enn en halv milliard på en konstant tid, slik Facebook implementert dette ved hjelp av en hash database (ingen SQL) og de opensourced databasen heter Cassandra.
Så hver bruker har sin egen nøkkel og venner detaljer i kø; å vite hvordan Cassandra fungerer se på dette:
Dens en type grafdatabase: http://components.neo4j.org/neo4j-examples/1.2-SNAPSHOT/social-network.html
Det er ikke relatert til relasjonsdatabaser.
Google for grafdatabaser.
Sannsynligvis er det en tabell som lagrer venn <-> user forhold, sier "frnd_list", har felt 'user_id', 'frnd_id'.
Når en bruker legger en annen bruker som venn, er to nye rader opprettet.
For eksempel anta at min id er 'deep9c' og jeg til en bruker med id 'akash3b' som min venn, da to nye rader opprettes i bordet "frnd_list" med verdier ( 'deep9c', 'akash3b') og ( 'akash3b ', 'deep9c').
Nå når viser venner-listen til en bestemt bruker, vil en enkel sql gjøre det: "velg frnd_id fra frnd_list hvor user_id =" hvor er id til den påloggede brukeren (lagret som en session-attributt).
Denne siste juni 2013 innlegg går inn i noen detaljer i å forklare overgangen fra forholdet databaser til objekter med assosiasjoner til enkelte datatyper.
https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-graph/10151525983993920
Det er en lengre papir tilgjengelig på https://www.usenix.org/conference/atc13/tao-facebook's-distributed-data-store-social-graph
TL; DR:
De bruker en stabel arkitektur med bufrede grafer for alt over MySQL bunnen av deres stabelen.
Long Svar:
Jeg gjorde noen undersøkelser på dette selv fordi jeg var nysgjerrig på hvordan de håndtere sin enorme mengder data, og søke det på en rask måte. Jeg har sett folk klage på skreddersydde sosiale nettverk skript blir treg når brukerbasen vokser. Etter at jeg gjorde noen benchmarking meg selv med bare 10k brukere og 2,5 millioner venn tilkoblinger - ikke engang prøver å bry seg om grupperettigheter og liker og veggen innlegg - det raskt viste seg at denne tilnærmingen er feil. Så jeg har brukt litt tid på å søke på nettet om hvordan du gjør det bedre, og kom over denne offisielle Facebook-artikkel:
Jeg virkelig anbefale deg å se presentasjonen av den første linken over før fortsette å lese. Det er sannsynligvis den beste forklaringen på hvordan FB fungerer bak kulissene du kan finne.
Videoen og artikkelen forteller deg et par ting:
La oss ta en titt på denne, venn tilkoblinger er øverst til venstre:
Vel, dette er en graf. :) Det trenger ikke fortelle deg hvordan å bygge den i SQL, er det flere måter å gjøre det, men dette området har en god mengde ulike tilnærminger. OBS: Tenk at en relasjons DB er hva det er: Det er tenkt å lagre normalisert data, ikke en graf struktur. Så det vil ikke utføre like bra som en spesialisert grafdatabase.
Tenk også på at du trenger å gjøre mer komplekse spørringer enn bare venner av venner, for eksempel hvis du ønsker å filtrere alle steder rundt et gitt koordinat at du og dine venners venner som. En graf er den perfekte løsningen her.
Jeg kan ikke fortelle deg hvordan du kan bygge det slik at det vil gi gode resultater, men det klart krever litt prøving og feiling og benchmarking.
Her er min skuffende test for bare funn venner av venner:
DB Schema:
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;
Venner av venner Kriterier:
(
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
)
Jeg virkelig anbefale deg å lage deg noen eksempler på data med minst 10k brukerposter, og hver av dem har minst 250 venneforbindelser og deretter kjøre denne spørringen. På min maskin (i7 4770k, SSD, 16GB RAM) var resultatet ~ 0,18 sekunder for det aktuelle søket. Kanskje det kan optimaliseres, jeg er ikke en DB geni (forslag er velkomne). Men hvis dette skalerer lineært du allerede er på 1,8 sekunder for bare 100k brukere, 18 sekunder for 1 million brukere.
Dette kan fortsatt høres OKish for ~ 100k brukere, men mener at du bare hentet venner av venner og ikke gjøre noe mer kompleks spørring som " vise meg kun innlegg fra venners venner + gjøre tillatelse sjekke om jeg er tillatt eller ikke å se noen av dem + gjøre en sub spørring for å sjekke om jeg likte noen av dem ". Du ønsker å la DB gjøre sjekken på hvis du likte en post allerede eller ikke, eller du må gjøre i kode. Tenk også på at dette ikke er den eneste spørringen du kjører, og at din har mer enn aktiv bruker på samme tid på en mer eller mindre populære nettstedet.
Jeg tror mitt svar besvarer spørsmålet hvordan Facebook designet deres venner forholdet veldig bra, men jeg beklager at jeg ikke kan fortelle deg hvordan du kan implementere det på en måte det vil fungere raskt. Implementering av et sosialt nettverk er lett, men å sørge for at det fungerer godt er åpenbart ikke - IMHO.
Jeg har begynt å eksperimentere med OrientDB å gjøre diagram-spørringer og kartlegge mine kanter til den underliggende SQL DB. Hvis jeg noen gang får det gjort Jeg skal skrive en artikkel om det.