Как реализовать функцию «временной шкалы» в Твиттере

Question

Я пытаюсь изучить дизайн базы данных, создав клон твиттера. И мне было интересно, каков наиболее эффективный способ создания функции временной шкалы друзей. Я реализую это в Google App Engine, который использует Big Table для хранения данных. IIRC, это означает очень высокую скорость чтения (получает), но значительно медленнее запросы страниц, и это также означает значительно меньшую скорость записи. В настоящее время, на мой взгляд, есть два метода, каждый со своими неудачами:

Для каждого пользователя есть структура списка, которая является временной шкалой его друзей. Каждый раз, когда кто-то делает твит, эта структура обновляется для каждого из его последователей. Этот метод использует много операций записи, но для каждого пользователя, получающего список, он будет казаться очень быстрым.

или

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

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

Answer 1

Вам нужно сосредоточиться на объекте упражнения, которое, как вы говорите, изучает проектирование базы данных.Так что не зацикливайтесь на масштабируемости.Создайте базу данных, которая будет работать для вас и ваших партнеров.Практически любой выбранный вами дизайн сможет справиться с такой нагрузкой.Помимо всего прочего, лицензия GAE будет стоить вам больших денег, если вы даже начнете приближаться к уровням хитов в стиле Twitter.

Дело в том, что масштабируемость для таких игроков, как Twitter и Facebook, является основной частьюих предложение.Следовательно, они тратят много усилий на создание своих приложений для масштабирования.Они делают это с множеством оптимизаций, включая разные архитектуры хранения для разных типов данных, распределенные серверы и кеширование, большое кеширование.Другими словами, это делается с помощью инфраструктуры и архитектуры, а не проектирования базы данных

Высокая масштабируемость является очень хорошим источником актуальной информации.Например, эта сводка презентации Эвана Уивера в Твиттере в прошлом году чрезвычайно актуальна:

"[E] что-то в оперативной памяти сейчас, база данных является резервной копией, пики на 300твиты в секунду, за каждым твитом следуют в среднем 126 человек; векторный кэш идентификаторов твитов; кеш строк; кэш фрагментов; кэш страниц; хранить отдельные кеши; GC делает стойкой к оптимизации Ruby, поэтому используется со Scala; Thrift и HTTP используются внутренне; внутренние 100 сзапросы на каждый внешний запрос; переписали MQ, но интерфейс оставался прежним; 3 очереди используются для запросов на балансировку нагрузки; расширенное A / B-тестирование для определения обратной возможности; переключение на клиент C memcached для скорости; оптимизация критического пути; ускорение для получения кэшированных результатовиз сетевой памяти, чем пересчитать их локально. "

Хммм, только" База данных является резервной копией ".Страшные вещи (для парня из базы данных, как я).