если бы вы заново реализовали твиттер, что бы вы сделали по-другому?

Question

Я только что увидел смешное «Взлет и падение Твиттера» что заставило меня задуматься:

если бы вы заново реализовали твиттер, что бы вы сделали по-другому?

Какие технологии вы бы использовали?Какие языки?

Как обеспечить масштабируемость сервиса?

Что бы еще вы изменили?

Answer 1

Я бы реализовал это на GAE, вот так:

У каждого пользователя будет таблица, содержащая твиты людей, на которых он подписан.Эта таблица будет иметь ключ (пользователь, временная метка по убыванию).

У каждого пользователя также есть таблица Follower_ranges, которая сопоставляет пользователя с набором смежных диапазонов идентификаторов подписчиков.Для большинства пользователей, у которых всего несколько тысяч подписчиков, в этой таблице будет одна запись (-inf..+inf);это будет подразумеваемое значение по умолчанию.Для пользователей с большим количеством подписчиков в каждом диапазоне таблицы будет несколько тысяч пользователей.Диапазоны будут сбалансированы с течением времени, чтобы количество пользователей в каждом из них оставалось в пределах некоторого интервала, напримербольше 1000, меньше 10000.Объединение всех диапазонов будет включать все идентификаторы пользователей.

Всякий раз, когда создается операция «пользователь -> подписчик», она кодируется как действие и добавляется в очередь.Каждый элемент в очереди представляет собой кортеж (отправитель, действие, полезные данные, поддиапазон последователей).Работники очереди берут элемент, находят всех последователей в заданном поддиапазоне и применяют действие к каждому из них.(Обратите внимание, что действием может быть «добавить твит», «удалить твит», «отредактировать твит» и т. д.По сути, все, что нужно будет применить ко всем последователям.)

Применение действия очереди к каждому подписчику будет включать в себя выполнение соответствующих операций записи и удаления в таблице твитов каждого пользователя.Барьер очереди будет означать, что записи не будут происходить мгновенно, но можно будет сохранить задержку ниже нескольких секунд.

Показать пользователю его твиты будет дешевой операцией:«ВЫБРАТЬ * ИЗ твитов ГДЕ user_id = :user_id ORDER BY (created_at DESC) LIMIT :max_per_page».Это позволит сканировать одну таблицу и выполнить очень быструю операцию.(Уменьшить задержку блокировки пользователей — это хорошо!)

Я думаю, что этот дизайн изначально будет хорошо масштабироваться.Каждый компонент системы теперь можно легко масштабировать:

• Хранилище очередей может поддерживаться GAE и масштабироваться в соответствии с любой таблицей хранилища данных.
• Интерфейсы можно масштабировать естественным образом, и нет необходимости в липкости.
• Дополнительные процессоры очередей можно добавить в любое время.
• Фактические таблицы хранения будут расти естественным образом и должны хорошо масштабироваться в Datastore.

Тем не менее, я могу придумать пару будущих улучшений, которые я бы немедленно рассмотрел:

• Уменьшите хранение редко отображаемых данных.Такая конструкция денормализует каждый твит в копию для каждого подписчика.Однако обычно доступны только самые последние твиты.Удалив пользовательскую копию твитов после того, как им исполнилось N дней, мы можем восстановить большой объем памяти.Если пользователь пытается просмотреть что-то из древней истории, мы извлекаем данные из денормализованных таблиц.Это будет медленнее, но не будет происходить слишком часто, а экономия будет значительной.Экономия хранения:(#avg_followers - 1) / #avg_followers
• Шаблон записи неоптимален.В нескольких элементах очереди каждый работник очереди будет писать в таблицу твитов каждого пользователя, поэтому локальность записи будет не очень хорошей.(В худшем случае у нас будут #соединения процессора * #сервера хранения.) Это можно исправить, применив несколько обновлений для каждого диапазона пользователей.Например, если два действия A и B должны быть применены к диапазону [0, 10000), то один процессор очереди должен применить эти два действия одновременно.

Answer 2

Это уже делается: Лаконика

Answer 3

1. Это уже делается. Часть II — Месть: identi.ca (который находится над Лаконикой)
2. Это уже делается. Часть III — С тёмной стороны: болтовня

ВБГ!(-:

Answer 4

Я собираюсь начать с предпосылки вернуться, чтобы сделать это снова:что бы я сделал по-другому, если бы я тогда был в Твиттере?

Ничего.

Twitter сохранил фокус на том, что важно:предоставление услуги, которую люди на самом деле хотеть использовать.

Мне бы хотелось поработать над продуктом, который стал настолько популярным за такой короткий период времени, что его самой большой угрозой стала его собственная масштабируемость.Это означает, что вы выиграли.С успехом приходят ресурсы и внимание, чтобы извлечь из него выгоду.

Answer 5

Я бы с самого начала спроектировал его чертовски масштабируемым.

Мой выбор — платформа Microsoft, C#, IIS, SQL Server, Memcached (или Velocity, если она окончательная и работает хорошо при запуске ;-)