Как реализовать 'друзей' Твиттера временная шкала' функция
Я пытаюсь изучить проектирование баз данных путем создания клона Твиттера.. И я задавался вопросом, каков самый эффективный способ создать функцию временной шкалы друзей. Я реализую это в Google App Engine, который использует Большую Таблицу, чтобы хранить данные. IIRC, это означает очень быстро, что скорость чтения (добирается), но значительно более медленные запросы страницы, и это также означает значительно более медленные скорости записи. В настоящее время в моем уме существует два метода, каждый с его неудачами:
Для каждого пользователя существует структура списка, это - временная шкала их друзей. Каждый раз кто-то делает твит, эта структура обновляется для каждого из ее подписчиков. Этот метод использует много операций записи, но для каждого пользователя, получающего список, это будет казаться очень быстрым.
или
Для каждого пользователя вычислите временную шкалу друзей динамично путем получения всех твитов людей, за которыми он следует, и сделайте слияние всех твитов для получения временной шкалы друзей (так как для каждого физического лица твиты отсортированы хронологически). Это могло бы быть медленно, если человек следует за большим количеством людей.
Есть ли некоторые другие способы, которыми я не знаю? Оба из этих методов кажутся, что это составит системный дроссель, когда число пользователей увеличится.
1 ответ
Вам нужно сосредоточиться на объекте упражнения, который, как вы говорите, - это изучение дизайна базы данных. Так что не зацикливайтесь на масштабируемости. Создайте базу данных, которая будет удобна для вас и ваших товарищей. Практически любой выбранный вами дизайн сможет выдержать такую нагрузку. Помимо всего прочего, лицензия GAE начнет взимать с вас большие деньги, если вы даже начнете приближаться к уровням хитов в стиле Twitter.
Дело в том, что масштабируемость для таких игроков, как Twitter и Facebook, является важной частью их предложения. Следовательно, они прилагают много усилий для создания масштабируемых приложений. Они делают это с множеством оптимизаций, включая разные архитектуры хранения для разных типов данных, распределенные серверы и кэширование, большое количество кэширования. Другими словами, это делается с помощью инфраструктуры и архитектуры, а не проектирования базы данных
. Высокая масштабируемость - очень хороший источник актуальной информации.Например, это резюме презентации Эвана Уивера из Твиттера в прошлом году чрезвычайно актуально:
«[E] все в оперативной памяти сейчас, база данных - это резервная копия; достигает 300 твитов в секунду; каждый твит, за которым следует в среднем 126 люди; векторный кеш идентификаторов твитов; ряд кеш; фрагментный кеш; кеш страницы; хранить отдельные кеши; GC делает Ruby оптимизация устойчива, поэтому пошла с Scala; Используются Thrift и HTTP внутренне; 100 внутренних запросов на каждый внешний запрос; переписал MQ но сохранил интерфейс прежним; 3 очереди есть используется для запросов балансировки нагрузки; обширное A / B-тестирование для обратного возможность; перешел на C memcached клиент на скорость; оптимизировать критические дорожка; быстрее получить кешированные результаты из сетевой памяти, чем пересчитать их локально ».
Хммм,« База данных - это только резервная копия ». Страшная штука (для такого парня, как я).