Как Вы реализовали бы Твиттер с помощью вида NOSQL DB?
Это походит на реализацию веб-приложения как потребности twitter/facebook-wall 1 огромная "подача" реляционная таблица (+ пользовательская таблица) и потрясающий механизм кэширования.. (можно ли рекомендовать тот?)
мой основной вопрос, как Вы реализовали бы такую "опцию" с помощью нереляционного DB, например, вида ключа/значения DB?
Очевидно, я имел, любят поддерживать количество пользователей, использующих Твиттер одновременно и в целом.
Спасибо
5 ответов
Вы можете прочитать, как twitter сделал это здесь: http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html
Также читайте здесь: http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
Никаких моделей данных, но довольно много информации о том, как это делается ;)
Взгляните на Kestrel, систему очередей сообщений, которую использует Twitter
Очевидно, я хотел поддержать количество пользователей, использующих твиттер по совместительству и в целом.
Извините, но это требование далеко от реальности. Twitter имеет огромную ферму серверов для сегментирования данных для поддержки их массового параллелизма. У вас столько серверов, сколько у twitter?
Существует архитектурная идея реализации клона twitter с помощью redis: TwitterAlikeExample
Я бы использовал Redis. Очередь ключей на пользователя + набор BLOB-объектов, полученных с помощью этих ключей.
Я добавлю MongoDB в список.
Схема будет довольно простой.
ТВИТЫ
UserName (или UserID, если нужно немного нормализовать)
TweetID (уникальный номер)
Отметка времени
Твит (текст твита)
ПОЛЬЗОВАТЕЛЬ
UserID (необязательно)
Имя пользователя
Имя, адрес электронной почты, личная информация (веб-адрес и т. Д.)
Пароль (хэш)
Подписчики (ссылка повторяющегося пользователя)
Читая (повторяющийся пользовательский исх.)