Вашият код не ми казва много; Мисля, че би било полезно, ако можете да изложите структурата на вашите данни в обикновен JSON / SQL.
Както и да е, бих сериализирал потока на всеки потребител в MongoDB. Не бих съхранявал HTML в базата данни по различни причини (поне не на това ниво на софтуера); вместо това трябва да запишете съответните данни в (евентуално полиморфна) колекция. Тогава извличането на новинарския канал е много лесно, индексирането е лесно и т.н. Структурата на изгледа по същество няма да се промени. Ако по-късно искате да промените HTML, това също е лесно.
Недостатъкът е, че това ще дублира много данни. Ако хората могат да имат много последователи, това може да се превърне в проблем. Използването на масиви от потребителски идентификатори вместо един потребителски идентификатор може да помогне (ако информацията е еднаква за всички последователи), но също така е ограничено.
За много големи проблеми с асоциирането има само кеширане. Начинът, по който го разбирам, магията както във facebook, така и в twitter е, че те не удрят db много често и съхраняват много данни в RAM. Ако свързвате милиарди елементи, това е предизвикателство дори в RAM.
Актуализациите трябва да се пишат непрекъснато, а не на всеки час. Да предположим, че имате много трафик и актуализацията на час отнема 30 минути. Най-лошият случай е 90 минути. забавяне. Ако обработвате промените точно навреме, можете да намалите това до вероятно 5 минути.
В даден момент ще трябва да хвърлите предположения, да използвате кеширане и някои евристики. Някои примери:
- Колкото по-скорошен е един туит, толкова повече трафик ще има. Има по-голям шанс да бъде ретуитнато и се вижда много по-често. Съхранявайте го в RAM.
- Вашата страница с преглед на хронологията във Facebook от 1991 г. вероятно няма да се променя ежедневно, така че това е кандидат за дългосрочно кеширане на изхода.
- Текущата активност във Facebook вероятно ще бъде подложена на много писания. Кеширането на изхода няма да помогне много тук. Отново, обектът трябва да се съхранява в RAM.
