“utóbbi 24 óra összes csiripjei nem fér bele _egy_ szerver memóriájába”
Egyrészt nem is kell egy szerver memóriájába beférjen, memcache alapból megoldja neked, hogy elosztja az adatokat több szerver között.
Másrészt vegyünk mondjuk 8GB memóriát (ami simán nem sok, ennek többszöröse lehet egy szerverben), ha 200 byte-ot veszünk egy üzenet memória foglalására (járulékos költségek), akkor is több mint 40 millió üzenet simán elfér benne, bőven ez alatt van a twitter napi termelése.

Plusz én nem azt vázoltam, hogy az üzeneteket össze kell szedni különböző szerverekről, hanem azt, hogy NÉHA. Alapban DB-ben tárolod az adott node usereit, plusz minden usernek az ő listájához tartozó üzenet azonosítókat. Ezen kívül tárolunk teljes listákat is memcacheben (ezt innen lekérdezni lénegesen gyorsabb, mint DB-ből). Ha itt nincs meg, akkor kérem le DB-ből az ID-kat, és ezek alapján kérem le memcacheből az adatokat, és leteszem a listát memcachebe, legközelebb onnan szolgálom ki. Cache invalidálást nagyon könnyen meg lehet oldani, akár DB trigger kiütheti, de egyéb okos megoldásokat ki lehet találni a részletek fényében. És a memcahe-nek ami még nagy előnye, hogy automatikusan megoldja neked, hogy a legfontosabb (leggyakrabban) használt elemek vannak a cache-ben.

Üdv,
Felhő

Üdv,
Felhő

“csak éppen a memóriába biztosan nem fér el az összes üzenet”
“Memóriában tárolt megoldásra építeni (mármint megpróbálni berakni a memóriába az összes friss hozzászólást) szerintem hosszútávon gyilkos megoldás, gyorsabban fejlődhet a Twitter, mint a memóriák.”
Facebooknál 800 DB csak memcache szerver van, elég sok minden el tud férni benne.

“Egyébként nagyon hasonló megoldásról beszélünk másképpen”
“szerintem valamilyen ügyes denormalizálás lehet a megoldás”
Csak azt nem értem, hogy ezzel a megoldással jóval több melót adsz a DB-nek. Az üzeneteket magukat is szét kell teríteni, plusz így kvázi a DB-be cache-elnél, viszont a DB-ből kiszedni egy adatot az jóval bonyolultabb “protokol”, mint memcache-ből kiszedni, tehát még a query cacheből is lassabban jön ki egy adat.

Üdv,
Felhő

Szerintem 140 byte letárolása sok helyen nem okoz gondot. Cache-elni, késleltetni egyszerűen nem lehet, az API felhasználók egyből észrevennék, sok az API-ra épülő alkalmazás használhatatlanná válna. Egyébként nagyon hasonló megoldásról beszélünk másképpen – csak éppen a memóriába biztosan nem fér el az összes üzenet, amit egy API lekérdezés jellemzően visszaadhat, és a jelenlegi API forgalom iszonyatosan nagy lehet. Memóriában tárolt megoldásra építeni (mármint megpróbálni berakni a memóriába az összes friss hozzászólást) szerintem hosszútávon gyilkos megoldás, gyorsabban fejlődhet a Twitter, mint a memóriák. Elosztani el lehet persze, a friss elemeket is, de szerintem valamilyen ügyes denormalizálás lehet a megoldás.

Jelenleg csak az utolsó 10(?) elem érhető el egy felhasználó csiripel

Szerintem esetükben inkább olyasmi lehet nyerő, hogy a kapcsoló táblák vannak csak szétterítve, maguk az üzenetek pedig durván cachelve vannak. Magukat a usereket listafrissülésük szerint lehet különböző osztályokba sorolni, adott esetben lehet a teljes lisátkat is cache-elni.

Plusz még lehet csalni azzal is, hogy nem egyből jelenik meg egy hozzászólás, így elérhető, hogy sok kérés full cache-ből legyen kiszolgálva, míg egy másik nagy részük esetén magukat az id-kat kell csak DB-ből leszedni (ami mondjuk InnoDB clustered index esetén piszok gyors tud lenni), és az üzenetek pedig külön memcacheből jönnek elő.

Plusz még ez is érdekes lehet: http://dev.twitter.com/2008/05/twittering-about-architecture.html

Üdv,
Felhő