Mindig csodálkoztam, hogy Facebook tervezett barátja <-> user kapcsolatban.
Gondolom a felhasználó tábla így néz ki:
user_email PK
user_id PK
password
Gondolom az asztalra felhasználó adatait (nem, életkor stb. Keresztül csatlakoztatott felhasználói e-mail azt feltételezzük).
Hogyan csatlakoztassa az összes barátot, hogy ezt a felhasználót?
Valami ilyesmi?
user_id
friend_id_1
friend_id_2
friend_id_3
friend_id_N
Valószínűleg nem. Mivel a felhasználók száma nem ismert, és bővül.
Ez valószínűleg egy sok sok kapcsolat:
Friendlist (asztal)
user_id -> users.user_id
friend_id -> users.user_id
friendVisibilityLevel
EDIT
A felhasználói tábla valószínűleg nem user_email a PK, esetleg egy egyedi kulcs mégis.
felhasználók (táblázat)
user_id PK
user_email
password
Tartson egy barátja táblázatot, amely tartalmazza a felhasználói azonosítót, majd a felhasználói azonosító a barát (fogjuk nevezni FriendID). Mindkét oszlopot lenne idegen kulcsok vissza a felhasználók asztalra.
Némileg hasznos példa:
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)
Példa felhasználás:
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
Ez megmutatja, hogy Bob barátai mind Jon és Joe és Jon is barátok Joe-val. Ebben a példában feltételezzük, hogy a barátság mindig két módon, így nem kell egy sort a táblázatban, mint a (2,1) vagy (3,2), mert azok már képviselteti magát a másik irányba. Mert példát, ahol a barátság, vagy más kapcsolatok nem kifejezetten a kétirányú, akkor azt kell, hogy is van azokat a sorokat, hogy jelezze a kétirányú kapcsolat.
A legjobb megoldás az, hogy létrehozott egy gráf struktúrát . A csomópontok a felhasználók és a „baráti” a széleit.
Tartsa egyik asztalnál a felhasználók, ne egy másik asztalhoz élek. Akkor tartani az adatokat a széleken, mint a „nap összebarátkoztak” és „elismert státuszt”, stb
Keres idegen kulcsokat. Alapvetően nem lehet egy tömb egy adatbázisban, hacsak nem rendelkezik saját asztalra.
felhasználók táblázat
userID PK
más adatokat
barátok táblázat
userID - FK felhasználók asztalára képviselő a felhasználót, hogy van egy barátja.
friendID - FK a felhasználók képviselő táblázatot a felhasználói azonosító a barátja Tartsuk szem előtt, hogy az adatbázisban táblázatok célja, hogy növekszik függőlegesen (több sor), nem vízszintesen (oszlopok)
Megnézzük ezeket a cikkeket írja le, hogyan LinkedIn és a Digg épülnek:
Van még „Big adatok: Nézőpontok a Facebook adatok Team”, ami hasznos lehet:
Továbbá, van ez a cikk, amely arról szól, nem relációs adatbázisok, illetve hogyan használják egyes cégek:
http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
Látni fogod, hogy ezek a vállalatok foglalkoznak adattárházak, megosztjuk adatbázisok, adat cache és más magasabb szintű fogalmak, mint a legtöbben soha nem foglalkozik napi szinten. Vagy legalábbis, talán nem tudjuk, hogy mi.
Van egy csomó linket az első két cikk hogy meg kell adni néhány betekintést.
UPDATE 2014/10/20
Murat Demirbas írt összefoglaló
http://muratbuffalo.blogspot.com/2014/10/facebooks-software-architecture.html
HTH
Ami a teljesítményt a sok-sok asztal, ha van 2 32 bites ints összekötő felhasználói azonosítók, az alapvető adattárolás 200000000 felhasználók átlagosan 200 barátai fejenként mindössze alatt 300GB.
Nyilvánvaló, hogy szüksége lenne egy kis particionálás és indexelés és nem fogod tartani, hogy a memóriában minden felhasználó számára.
Vessünk egy pillantást az alábbi adatbázis sémáját, visszafejteni Anatolij Lubarsky :
Nem lehet adatokat letölteni RDBMS felhasználó barát adatok az adatokat, amelyeket át több mint fél milliárd állandó időben, így Facebook végre ezt a hash-adatbázisát (nincs SQL) és az adatbázis opensourced Cassandra.
Így minden felhasználó saját kulcsot, és a barátok részletei a sorba; tudni, hogy Cassandra munkák nézd meg ezt:
Ez egy diagram típusát adatbázis: http://components.neo4j.org/neo4j-examples/1.2-SNAPSHOT/social-network.html
A nem kapcsolódó relációs adatbázisok.
Google gráf adatbázisok.
Valószínűleg van egy tábla, amely tárolja a barátja <-> user kapcsolatban, azt mondják: "frnd_list", amelyek mezők user_id ', 'frnd_id'.
Amikor egy felhasználó egy újabb felhasználó barátként, két új sorok jönnek létre.
Például tegyük fel, én azonosítója „deep9c”, és én hozzá egy felhasználó az id „akash3b”, mint a barátom, akkor két új sorok jönnek létre tábla „frnd_list” értékekkel ( „deep9c”, 'akash3b) és (akash3b ”, 'deep9c').
Most, amikor bemutatja a barátok-lista egy adott felhasználó egy egyszerű sql tenne ilyet: „select frnd_id származó frnd_list ahol user_id =” hol van az id a bejelentkezett felhasználó (tárolt session-attribútum).
Ez utóbbi június 2013 utáni bemegy részletesen be magyarázza az átmenetet a kapcsolatot adatbázisok tárgyak szövetségek egyes adattípusok.
https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-graph/10151525983993920
Van egy hosszabb papír kapható https://www.usenix.org/conference/atc13/tao-facebook's-distributed-data-store-social-graph
TL; DR:
Ők egy verem architektúra cache grafikonok mindent feletti MySQL alján a verem.
Hosszú válasz:
Utánanéztem ezen magam, mert kíváncsi voltam, hogy hogyan kezelik a hatalmas mennyiségű adat és keressen meg egy gyors módja. Láttam az emberek panaszkodnak egyedi social network scriptek válik lassan, ha a felhasználói bázis növekszik. Miután tettem néhány összehasonlító magam csak 10k felhasználó és 2,5 millió barátja kapcsolatok - nem is próbál törődni csoport engedélyek és kedvel és falra hozzászólás - ez hamar kiderült, hogy ez a megközelítés hibás. Szóval egy ideig keresnek az interneten, hogyan lehet jobban csinálni, és rábukkantam erre a hivatalos Facebook cikket:
Azt nagyon ajánlom, hogy nézze meg a bemutatót az első fenti link előtt olvasson tovább. Valószínűleg ez a legjobb magyarázat, hogyan működik FB a színfalak mögött megtalálja.
A videó és a cikk beszámol arról, néhány dolgot:
Vessünk egy pillantást a, ismerősöd van a bal felső sarokban:
Nos, ez egy gráf. :) Azt nem mondja meg, hogyan kell építeni az SQL, számos módja van, de ezen az oldalon van egy jó adag különböző megközelítéseket. Figyelem: Vegye figyelembe, hogy a relációs DB mi ez: Úgy tartják, hogy tárolja a normalizált adatok nem gráfstruktúra. Tehát nem végez olyan jó, mint egy speciális gráf tárol.
Továbbá úgy vélik, hogy meg kell csinálni bonyolultabb lekérdezéseket, mint a barátok barátai, például ha azt szeretné, hogy kiszűrje az összes helyszínen mintegy egy adott koordináta, hogy Ön és a barátok barátai, mint a. A grafikon a tökéletes megoldást.
Nem tudom megmondani, hogyan kell elkészíteni úgy, hogy jól fognak teljesíteni, de ez egyértelműen megköveteli néhány próbálgatással és teljesítményértékelés.
Itt van a kiábrándító teszt csak megállapítások barátok barátai:
DB séma:
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;
Ismerősök ismerősei Keresés:
(
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
)
Nagyon ajánlom, hogy hozzon létre egy kis mintát adatok legalább 10k felhasználói bejegyzések és mindegyikük legalább 250 ismerősöd, majd futtatni ezt a lekérdezést. Az én gépemen (i7 4770k, SSD, 16GB RAM) volt az eredmény ~ 0,18 másodperc az adott lekérdezés. Lehet, hogy optimalizálni lehet, én nem a DB zseni (javaslatot szívesen). Azonban , ha ez a mérleg lineáris te már 1,8 másodperc alatt mindössze 100k felhasználók, 18 másodperc, 1 millió felhasználó.
Ez talán még mélyen OKish a ~ 100k felhasználók számára, de úgy, hogy csak erőltetett barátok barátai, és nem csinál semmi bonyolultabb lekérdezést, mint a " megjelenítéséhez csak nekem bejegyzéseit barátok barátai + do engedélye csekket, ha én engedélyezett vagy nem engedélyezett hogy néhány közülük + csinálni egy sub lekérdezést, ha szeretné ellenőrizni tetszett ezek közül bármelyik .” Azt akarja, hogy a DB tenni az ellenőrzést, ha tetszett a poszt már vagy sem, akkor meg kell tennie a kódot. Továbbá úgy vélik, hogy nem ez az egyetlen lekérdezés fut, és hogy a több, mint aktív felhasználó egyidejűleg egy többé-kevésbé népszerű site.
Azt hiszem, a válasz a kérdésre ad választ, hogyan Facebook tervezték a barátok kapcsolata nagyon jól, de sajnálom, hogy nem tudok mondani, hogyan valósítható meg oly módon, hogy működni fog gyorsan. Megvalósítása a szociális háló könnyű, de ügyelve arra, hogy jól teljesít nyilvánvalóan nem - IMHO.
Már kezdett kísérletezni OrientDB csinálni a gráf-lekérdezések és feltérképezése én élek a mögöttes SQL DB. Ha valaha is ez történik írok egy cikket róla.