Если бы вы повторно реализовали твиттер, что бы вы сделали по-другому?
Я только что увидел веселый «Взлет и падение Twitter», который заставил меня задуматься:
если бы вы повторно реализовали твиттер, что бы вы сделали по-другому?
Какие технологии вы бы использовали? Какие языки?
Как обеспечить масштабируемость сервиса?
Что бы вы еще изменили?
Ответы 5
Это уже делается: Лаконика
Я бы с самого начала спроектировал его чертовски масштабируемым.
Я бы выбрал платформу Microsoft, C#, IIS, SQL Server, Memcached (или Velocity, если он окончательный и работает хорошо при запуске ;-)
Вы правы, проблема заключалась в том, что они использовали SQL, а не сам SQL, и что плохого в том, чтобы платить деньги за то, что помогает вам вести их бизнес? Считаете ли вы, что на платформе MS невозможно запустить такое приложение, как Twitter? Это определенно.
Я собираюсь начать с того, что вернусь, чтобы сделать это снова: что бы я сделал по-другому, будь я тогда в твиттере?
Ничего.
Твиттер по-прежнему сосредоточился на самом важном: предоставлении услуги, которой на самом деле могут пользоваться люди хотеть.
Я бы с удовольствием поработал над продуктом, который стал настолько популярным за такой короткий период времени, что самой большой угрозой стала его собственная масштабируемость. Значит, ты выиграл. С успехом приходят ресурсы и внимание, чтобы извлечь из него выгоду.
Масштабируемость может быть проблемой «высокого класса», но это все еще проблема. Его спорно, но многие утверждают, что Friendster уступило свое место в социальной сети № 1 в связи, по крайней мере, частично, в его неспособности масштаба.
Я бы реализовал это на GAE, вот так:
У каждого пользователя будет таблица, содержащая твиты людей, на которых они подписаны. Эта таблица будет иметь ключ (пользователь, временная метка по убыванию).
У каждого пользователя также есть таблица follower_ranges, которая сопоставляет пользователя с набором непрерывных диапазонов идентификаторов последователей. Для большинства пользователей, у которых всего несколько тысяч подписчиков, в этой таблице будет одна запись (-inf .. + inf); это будет подразумеваемым значением по умолчанию. Для пользователей с большим количеством подписчиков каждый диапазон в таблице будет иметь несколько тысяч пользователей. Диапазоны будут сбалансированы с течением времени, чтобы количество пользователей в каждом оставалось в пределах некоторого интервала, например больше 1000, меньше 10000. Объединение всех диапазонов будет включать все идентификаторы пользователей.
Всякий раз, когда создается операция пользователь -> подписчик, она кодируется как действие и добавляется в очередь. Каждый элемент в очереди представляет собой кортеж (отправитель, действие, полезная нагрузка, подчиненный поддиапазон). Работники очереди берут предмет, находят всех последователей в данном поддиапазоне и применяют действие к каждому из них. (Обратите внимание, что действие может быть «добавить твит», «удалить твит», «отредактировать твит» и т. д. В основном все, что нужно будет применить ко всем подписчикам.)
Применение действия очереди к каждому подписчику будет включать в себя выполнение соответствующих операций записи и удаления в таблицу твитов каждого пользователя. Барьер очереди будет означать, что записи не будут появляться мгновенно, но должна быть возможность удерживать задержку ниже нескольких секунд.
Показывать пользователю их твиты будет дешевой операцией: «ВЫБРАТЬ * ИЗ твитов WHERE user_id =: user_id ORDER BY (created_at DESC) LIMIT: max_per_page». Это просканирует одну таблицу и будет очень быстрой операцией. (Уменьшение задержки блокировки пользователей - это хорошо!)
Думаю, изначально этот дизайн неплохо масштабировался. Теперь каждый компонент системы можно легко масштабировать:
- Хранилище очереди может поддерживаться GAE и масштабироваться в соответствии с любой таблицей хранилища данных.
- Интерфейсы можно масштабировать естественным образом, и нет необходимости в липкости
- Дополнительные процессоры очереди могут быть добавлены в любое время
- Фактические таблицы хранения будут расти естественным образом и должны хорошо масштабироваться в Datastore.
Тем не менее, я могу придумать пару будущих улучшений, на которые я бы сразу обратился:
- Уменьшите объем хранилища редко отображаемых данных. Этот дизайн денормализует каждый твит в копию для каждого подписчика. Однако обычно доступны только самые последние твиты. Удаляя индивидуальную копию твитов по прошествии N дней, мы можем восстановить большой объем хранилища. Если пользователь пытается просмотреть что-то из древней истории, мы получаем данные из денормализованных таблиц. Это будет происходить медленнее, но не слишком часто, и экономия будет значительной. Экономия места на диске: (#avg_followers - 1) / #avg_followers
- Схема записи неоптимальна. В нескольких элементах очереди каждый работник очереди будет писать в таблицу твитов каждого пользователя, поэтому локальность записи будет не очень хорошей. (В худшем случае у нас будет #processor * #storage server connections.) Это можно исправить, применив несколько обновлений для каждого диапазона пользователей. Например, если два действия A и B должны быть применены к диапазону [0, 10000), то пусть один процессор очереди применяет эти два действия одновременно.
Причина, по которой Twitter было трудно масштабировать, заключалась в использовании SQL. Использование SQL означает, что вам нужно будет разбить или разбить вашу базу данных на сегменты для масштабирования. Это не очень хорошо работает для варианта использования Twitter, плюс, если вы используете SQL-сервер, вам придется платить за новую лицензию на каждой машине.