Váš kód mi mnoho neříká; Myslím, že by bylo užitečné, kdybyste mohli rozložit svou datovou strukturu v prostém JSON / SQL.
Každopádně bych serializoval stream každého uživatele do MongoDB. HTML bych do databáze z různých důvodů neukládal (alespoň ne na této úrovni softwaru); místo toho byste měli uložit příslušná data do (možná polymorfní) kolekce. Načítání newsfeedu je pak velmi snadné, indexace je přímočará atd. Struktura zobrazení by se v podstatě nezměnila. Pokud později budete chtít změnit HTML, je to také snadné.
Nevýhodou je, že to bude duplikovat spoustu dat. Pokud lidé mohou mít hodně následovníků, může to být problém. Použití polí ID uživatele místo jednoho ID uživatele může pomoci (pokud jsou informace stejné pro všechny sledující), ale je to také omezené.
Pro velmi velké problémy s asociací existuje pouze ukládání do mezipaměti. Jak tomu rozumím, kouzlo jak na facebooku, tak na twitteru je v tom, že se moc často netrefí do db a drží spoustu dat v RAM. Pokud přidružujete miliardy položek, je to problém i v RAM.
Aktualizace by měly být psány průběžně, spíše než na hodinové bázi. Předpokládejme, že máte velký provoz a hodinová aktualizace trvá 30 minut. Nyní je nejhorší případ 90 minut. zpoždění. Pokud provedete změny just-in-time, můžete to zkrátit na pravděpodobně 5 minut.
V určitém okamžiku budete muset vložit předpoklady, použít ukládání do mezipaměti a nějakou heuristiku. Několik příkladů:
- Čím novější je tweet, tím větší provoz uvidí. Má vyšší šanci na retweetování a je vidět mnohem častěji. Uchovávejte jej v paměti RAM.
- Vaše stránka s přehledem časové osy na Facebooku z roku 1991 se pravděpodobně nebude měnit každý den, takže je to kandidát na dlouhodobé ukládání do mezipaměti výstupu.
- Současná aktivita na Facebooku bude pravděpodobně podléhat mnoha zápisům. Výstupní cachování zde moc nepomůže. Opět platí, že objekt by měl být uložen v paměti RAM.