Конкурс в Твиттере ~ сохранение твитов (PHP и MySQL)

Question

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

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

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

Это имеет очевидный недостаток - запускать 100 запросов к БД каждые 5 минут, и сколько бы INSERT их не было. Что мне действительно не нравится. К тому же, я бы предпочел что-то более реалистичное. Поскольку твиттер - это прямая трансляция, очевидно, что мы должны обновить наш список участников, как только они войдут.

Это снова вызывает недостаток необходимости повторного опроса в Твиттере, что, хотя и может быть необходимо, но я не уверен, что хочу использовать их API таким образом.

У кого-нибудь есть идеи по поводу элегантного решения? Мне нужно убедиться, что я перехватываю все твиты и никого не пропускаю, и сохраняю уникальность пользователя БД. Хотя я подумал просто добавить все, а затем сгруппировать результирующую таблицу по имени пользователя, но это не аккуратно.

Я рад иметь дело с дисплеем отдельно, так как это просто вывод из mysql и display. Но дизайн бэкэнда вызывает у меня головную боль, так как я не могу найти эффективный способ заставить его работать, не ударяя ни API, ни DB.

Answer 1

100 запросов за 5 минут - ничто.Тем более, что твит имеет по существу только 3 фрагмента данных, связанных с ним: идентификатор пользователя, временную метку, твит, идентификатор твита - скажем, около 170 символов данных на твит.Если вы не используете свою базу данных на частоте 4,77 МГц 8088, ваша база данных даже не будет мигать при такой нагрузке

Answer 2

Twitter API предлагает API потоковой передачи, который, вероятно, именно то, что вы хотите сделать, чтобы обеспечить захват всего: http://dev.twitter.com/pages/streaming_api_methods

Если я понимаю, что вы ищете, вы, вероятно, захотите statuses/filter, используя параметр track с любыми отличительными характеристиками (хэштегами, словами, фразами, местоположениями, пользователями), которые вы ищете.

Во многих библиотеках Twitter API это встроено, но в основном вы оставляете HTTP-соединение открытым, и Twitter постоянно отправляет вам твиты по мере их появления. Подробнее об этом см. В обзоре потокового API . Если ваша библиотека не делает это за вас, вам нужно будет проверить наличие сброшенных соединений и переподключиться, проверить коды ошибок и т. Д. - все это в обзоре. Но добавление их по мере их поступления позволит вам полностью исключить дубликаты (если только вы не разрешите только одну запись для пользователя - но это ограничения на стороне клиента, с которыми вы столкнетесь позже).

Если вы не забиваете свою БД, то, если у вас есть Твиттер, просто отправляющий вам материал, вы сами контролируете свои задачи - вы можете легко заставить своего клиента кешировать твиты по мере их поступления, а затем записывать их в дБ в заданное время или с интервалами подсчета - напишите все, что он собрал каждые 5 минут, или напишите, как только у него будет 100 твитов, или оба (очевидно, эти числа являются просто местозаполнителями). Это когда вы можете проверить существующие имена пользователей, если вам нужно - написание кэшированного списка даст вам лучший шанс сделать вещи эффективными, как вы хотите.

Обновление: Мое решение выше, вероятно, лучший способ сделать это, если вы хотите получить живые результаты (что, кажется, вы делаете). Но, как упомянуто в другом ответе, вполне возможно, что можно просто использовать API поиска для сбора записей после окончания конкурса и не беспокоиться о их сохранении вообще - вы можете указать страницы, когда спросите для результатов (как указано в ссылке API поиска), но есть ограничения на количество результатов, которые вы можете получить в целом, что может привести к пропуску некоторых записей. Какое решение лучше всего подойдет для вашего приложения, зависит только от вас.

Answer 3

Я думаю, что запуск крона каждые X минут и основание его на дате создания твитов может сработать. Вы можете запросить вашу базу данных, чтобы найти последнюю дату / время последнего записанного твита, а затем запустить только выбирает, если есть совпадающие времена, чтобы предотвратить дублирование. Затем, когда вы выполняете вставку в базу данных, используйте одну или две инструкции вставки, содержащие все записи, которые вы хотите записать, чтобы сохранить производительность.

INSERT INTO `tweets` (id, date, ...) VALUES (..., ..., ...), (..., ..., ...), ...;

Это не кажется слишком интенсивным ... также зависит от количества твитов, которые вы ожидаете записать. Также убедитесь, что таблица правильно проиндексирована.

Answer 4

Я перечитал ваш вопрос, и мне кажется, что вы хотите дублировать данные, уже сохраненные в Твиттере.Без дополнительной информации о соревнованиях, о вашем беге, о том, как пользователи вводят, например, примерное количество заявок;невозможно определить, является ли хранение этой информации локально в базе данных лучшим способом решения этой проблемы.

Может быть лучшим решением, пропустить локальное хранение дубликатов данных и перетащить участников прямо из твиттера, то есть когда вы пытаетесь найти победителя.Вы можете удалить дубликаты записей на лету, пока код работает.Вам просто нужно будет вызвать «следующую страницу», как только она закончит обработку 100 записей, которые уже получены.Хотя я не уверен, что это возможно напрямую через Twitter API.