Эффективно ли получать и хранить твиты из нескольких сотен профилей в Твиттере?

Question

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

На страницах будут отображаться

• последние 20 твитов (или 21-40 и т. Д.) По дате, группе профилей, отдельному профилю, поиску или «теме» (что-то вроде другой группы .. я думаю ..)
• живое, контекстно-зависимое облако тегов (на основе последних 300 твитов текущего поиска, показанной группы профилей или одного профиля)
• различные статистические данные (групповые, наиболее активные и т. Д.), Которые зависят от типа отображаемой страницы.

Мы ожидаем довольно много трафика. Последний, аналогичный сайт достиг пика почти в 40 тысяч посещений в день и столкнулся с проблемами, прежде чем я начал кэшировать страницы в виде статических файлов и отключать некоторые функции (некоторые, случайно ...). Это было вызвано главным образом тем, что при загрузке страницы также извлекал последние x твитов из 3-6 профилей, которые не были обновлены дольше всего.

С этим новым сайтом я могу, к счастью, использовать cron для получения твитов, так что это помогает. Я также немного денормализую БД, поэтому для этого нужно меньше объединений, оптимизирую его для более быстрого выбора вместо размера.

Теперь, основной вопрос : как мне выяснить, какие профили эффективно проверять наличие новых твитов? Некоторые люди будут чирикать чаще, чем другие, некоторые будут чирикать в очередях (это часто случается). Я хочу, чтобы главная страница сайта была как можно более актуальной. Если речь идет, скажем, о 300 профилях, а я проверяю 5 каждую минуту, некоторые твиты появятся только через час после факта. Я могу проверять чаще (до 20 КБ), но хочу максимально оптимизировать это, чтобы не превышать ограничение скорости и , чтобы не исчерпать ресурсы на локальном сервере (это достигло предела подключения mysql с этого другого сайта).
Вопрос 2: , поскольку cron «запускается» только один раз в минуту, я полагаю, что мне приходится проверять несколько профилей каждую минуту - как указано, по крайней мере, 5, возможно, больше. Чтобы попытаться распространить его за эту минуту, я мог бы поспать несколько секунд между партиями или даже отдельными профилями. Но тогда, если это займет больше 60 секунд, скрипт запустится сам по себе. Это проблема? Если так, как я могу избежать этого?
Вопрос 3: Есть еще какие-нибудь советы? ? Файлы сведений URL-адрес?

Answer 1

Я бы не стал использовать cron, просто используйте потоковый API в Твиттере с фильтром для ваших 150-300 пользователей Твиттера.

статусы / фильтр

Возвращает публичные статусы, которые соответствуют одному или нескольким предикатам фильтра. Должен быть указан как минимум один параметр предиката, follow, location или track. Можно указать несколько параметров, что позволяет большинству клиентов использовать одно соединение с Streaming API. Размещение длинных параметров в URL может привести к отклонению запроса на чрезмерную длину URL. Используйте параметр заголовка запроса POST, чтобы избежать длинных URL.

Уровень доступа по умолчанию позволяет использовать до 200 ключевых слов отслеживания, 400 отслеживающих идентификаторов пользователей и 10 блоков местоположения в 1 градус. Повышенные уровни доступа позволяют 80 000 отслеживаемых идентификаторов пользователей (роль «теневого»), 400 000 отслеживаний идентификаторов пользователей (роль «птичьего пса»), 10 000 ключевых слов отслеживания (роль «ограниченного отслеживания»), 200 000 ключевых слов отслеживания (роль «отслеживания партнера») и 200 10- поля местоположения степени (роль "locRestricted"). Повышенные уровни доступа к дорожке также передают большую долю статусов перед ограничением потока.

Я считаю, что при указании идентификаторов пользователей вы действительно получаете все твиты из потокового API:

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

Это позволит вам получать результаты в реальном времени, не беспокоясь об ограничении скорости. Вам просто нужно убедиться, что вы можете принять данные достаточно быстро. Но с 300 пользователями это не должно быть проблемой.

Обновление - Как использовать API : К сожалению, у меня никогда не было возможности поиграть с потоковым API. У меня, однако, ранее были демонизированные скрипты php (да, я знаю, что это не сила php, но если все остальное, что вы делаете, в php, это можно сделать).

Я бы настроил простой php-скрипт для получения статуса и затем выводил их (необработанный JSON) в очередь сообщений. Затем я бы указал другой сценарий на очередь сообщений, чтобы получить статусы и поместить их в базу данных. Таким образом, подключение и время обработки БД не мешают просто принимать потоковые данные.

Судя по всему, пожарный шланг поместится в первой части этого решения. Что-то вроде beanstalkd (с pheanstalk ) будет работать в качестве очереди сообщений.

Answer 2

Я бы посмотрел на http://corp.topsy.com/developers/api/

У меня нет с ними никаких отношений, кроме того, что я играл с API.Я думаю, что это даст вам именно то, что вы хотите, с более высоким уровнем API-лимита.