Facebook like-ok tárolása
Valakinek van elképzelése, hogy a facebook hogyan tárolja a like-okat?
Ha van 1 milliárd felhasználód, azok az évek alatt több ezer milliárd like-ot hoztak létre. Ezeket hogyan lehet adatbázis táblákban tárolni?
Egy sql táblának van felső korlátja?
■ Ha van 1 milliárd felhasználód, azok az évek alatt több ezer milliárd like-ot hoztak létre. Ezeket hogyan lehet adatbázis táblákban tárolni?
Egy sql táblának van felső korlátja?
Bitek
A tábláknak vannak korlátaik, de az átlaghalandók nehezen érik el, a "nagyok" pedig különböző módokon kezelik a problémát.
De minden lájkoz tartozik egy
hát ez a különböző mód érdekelne.
Bontás
Azaz egy bejegyzés esetében a "magyar_bejegyzes_lajk" nevű táblából olvassák be, hogy az adott elemhez hány és milyen típusú kedvelés érkezett, a kommenteknél pedig a "magyar_komment_lajk" táblából.
Ja ez logikus. A
A magyar_bejegyzes_like tabla azt jelentene, hogy a magyar emberek altal letrehozott bejegyzesekre adott minden nemzetisegtol erkezo likeok. Akkor van gond, ha en 1 ember osszes like-jara vagyok kivancsi. Akkor minden nemzetiseg-bejegyzes-like tablajaba szet kell neznem, mivel magyar nem csak magyar posztot likolhat. Es pl a vine.co-n is osszesitve van az adott felhasznalo kapott like-jai. Ott is 100 milliokkal dobaloznak.
Példa
Biztos hogy nem relacios
Miért?
Léteznek NoSQL adatbázis
Egyébként ezt te sem gondoltad komolyan:
Miért?
Kicsit ellentmondásosnak
Majd állítod, hogy
Ha könnyebb indexelni, akkor miért szórod szét valamilyen csoportorsítás alapján, hogy aztán még véletlenül se tudj egyszerűen joinolni, mert 100 táblából vadászod össze a rekordokat, mondjuk azzal a célzattal, hogy megtudd, hogy XY miket lájkolt.
Lehet én vagyok elborult, de ha szerkezetét és szerepét is tekintve megegyező táblából több van egy relációs adatbázisban, akkor ott tervezési hiba van. E szerint a magyar felhasználókat, az amcsi felhasználókat és a görög felhasználókat is külön táblában kellene tárolni, mert amúgy sok rekord lenne a users táblában? Vagy éppen a nőket és a férfiakat vennéd külön?
Miért tervezési hiba a
Dimenziók
A hagyományos relációs adatbázisoknak is vannak korlátaik, az indexek mérete sem nőhet a végtelenségig, ezért érdemes darabolni.
Azt, hogy mire érdemes optimalizálni, a feladat dönti el. Úgy vélem, hogy mivel a legtöbb felhasználó mások által generált tartalmat olvas, ezért a legcélszerűbb típusonként (bejegyzés, hozzászólás stb.) tárolni a lájkokat. Jóval ritkább esetben van arra szükség, hogy egy felhasználó különböző típusú lájkjait gyűjtsék össze egy oldalon, ezért itt nem annyira számít, hogy hány lekérdezés kell hozzá. Ha mégis, akkor külön táblában lehet gyűjteni ilyen módon is.
Rakd össze :)
Gábor:
Smokey:
Más kérdés, hogy a master db-k nagy valószínűséggel NoSql db-k, de nem azokból kérdezget le, mert lassú lenne. Onnan csak szinkronizál a slave-ekre.
MongoDB: kifejezetten arra jó, hogy sokszor / sokat írsz bele, és nagyon ritkán kérdezel le, akkor is előre (tervezéskor) meghatározott struktúrában, szekvenciálisan. (Ilyesmit, mint MySql-ben ORDER BY vagy JOIN felejts el.) Arra semmiképp sem jó, hogy on the fly jeleníts meg belőle összetett adatokat, változó struktúrában.
BlaZe:
Gábor:
Ez egy-két dolgot máris hoz magával:
- egy posztnak az összes like-ja lehetőleg egy táblában legyen
- egy poszt összes kommentje is egy tábla legyen
- egy poszt összes kommentjének like-jai is egy tábla legyen.
- amennyiben egy poszt bekerül egy regionális db szerverre, akkor "viszi magával" a kommenteket és a like-okat is.
Nyilván regionálisan (nem feltétlen országonként, de ezen ne akadjunk fel most) vannak "statikusabb" tároló megoldások masterként (oda csak megfelelő jogosultságokkal és útvonalról lehet írni), és ezeknek számos slave replikája a dinamikus megjelenítés érdekében. Ezeket igyekszenek jó szinkronban tartani.
Arra nyilván szintén kidolgozott szabályrendszer van, hogy a regionális masterek közül "ki" az "egyetlen" főfő gazdája egy adatnak (igazából nem 1 darab, de megérteni így könnyebb), a gyorsaság kulcsa gyakorlatilag a helymeghatározás, hogy mit hol érdemes "honosítani", a másik fontos dolog pedig az, hogy csaknem 1 - 1 kapcsolat lehessen két, tetszőlegesen választott regionális szerver között, meg is tudják találni egymást és rövid időn belül ki tudják szolgálni a másik szerver kéréseit.
Erre azért van szükség, mert amikor az új kanadai barátnőd adatlapjára / bejegyzésére klikkelsz elsőként, akkor még ő nem szerepelt a magyar db-ben, mégis meg kell tudni jeleníteni pár másodperc alatt.
Szerintem tábla szinten úgy néz ki a like, hogy pl táblanév: entry_like, mezők:
- entry_id (bigint)
- like_type (enum)
- user_id (bigint)
- timestamp
Indexelve van minden oszlop külön, esetleg ha valóban van olyan statisztika, hogy Gipsz Jakab "Hűha" típusú reakcióinak a száma, akkor like_type és user_id közösen is indexelt.
Partícionálni timestamp és entry_id mentén érdemes, egy entry maradjon partíción belül lehetőleg.
comment_like tábla lehet ugyanez a szerkezet. (És ez nem tervezési hiba. :) )