Din kode fortæller mig ikke meget; Jeg tror, det ville være nyttigt, hvis du kunne lægge din datastruktur ud i almindelig JSON/SQL.
I hvert fald ville jeg serialisere hver brugers stream til MongoDB. Jeg ville ikke gemme HTML i databasen af forskellige årsager (i hvert fald ikke på det niveau af softwaren); i stedet bør du gemme de relevante data i en (muligvis polymorf) samling. Så er det meget nemt at hente nyhedsfeedet, indeksering er ligetil osv. Visningsstrukturen ville stort set ikke ændre sig. Hvis du senere vil ændre HTML, er det også nemt.
Ulempen er, at dette vil duplikere en masse data. Hvis folk kan have mange følgere, kan dette blive et problem. Det kan hjælpe at bruge rækker af bruger-id'er i stedet for et enkelt bruger-id (hvis oplysningerne er de samme for alle følgere), men det er også begrænset.
Ved meget store associationsproblemer er der kun caching. Sådan som jeg forstår det, er magien i både facebook og twitter, at de ikke rammer db'en ret ofte og opbevarer en masse data i RAM. Hvis du forbinder milliarder af genstande, er det en udfordring at gøre det selv i RAM.
Opdateringerne bør skrives løbende i stedet for på timebasis. Antag, at du har meget trafik, og timeopdateringen tager 30 min. Nu er det værste tilfælde en 90 min. forsinke. Hvis du behandler ændringer just-in-time, kan du skære dette ned til sandsynligvis 5 min.
Du bliver nødt til at kaste antagelser ind på et tidspunkt, bruge caching og nogle heuristika. Nogle eksempler:
- Jo nyere et tweet er, jo mere trafik vil det se. Den har større chance for at blive retweetet, og den ses meget oftere. Opbevar det i RAM.
- Din Facebook-tidslinjeoversigtsside fra 1991 vil sandsynligvis ikke ændre sig på daglig basis, så dette er en kandidat til langsigtet output-cache.
- Den aktuelle Facebook-aktivitet vil sandsynligvis undergå en masse skrivninger. Output caching hjælper ikke meget her. Igen skal objektet opbevares i RAM.