Как создать базу данных элементов из RSS-каналов для анализа (не для приложения), обновляемую по мере публикации RSS-элементов?
Мне нужно создать базу данных элементов из RSS-каналов, и я хотел бы, чтобы она обновлялась асинхронно (через push ala AJAX), а не вытягивала (ala чистит RSS через python/magpie в php). База данных будет использоваться для анализа, а не для приложения, поэтому ее необходимо масштабировать. Если кто-то знает о приложении для чтения RSS-каналов, для которого вы можете просто экспортировать элементы из своего канала через XML, это было бы здорово.
Я бы предпочел не создавать кучу серверной инфраструктуры, чтобы заставить анализатор php rss играть с mysql на заданиях chron, но я сделаю это при необходимости. Также заинтересованы в потенциальных решениях Python.
Я взглянул на Superfeedr/PubSubHubbub, но не уверен, что это правильное решение для меня.
2 ответа
Пожалуйста, добавьте соль в мой комментарий, потому что я создал Superfeedr. Я постараюсь оставаться объективным в любом случае.
Если вы хотите увеличить масштаб и хотите, чтобы ваш набор данных продолжал расти со временем, вполне вероятно, что (как вы уже догадались) опрос будет чрезвычайно сложным. Вероятно, вы потратите много времени на обработку проблем HTTP и проблем с синтаксическим анализом XML. В Superfeedr мы уже собираем и анализируем миллионы кормов, и нет недели, когда мы не сталкиваемся с новым "видом" ошибок. Иногда я чувствую себя первым поселенцем в тропическом лесу Амазонки.
Среди проблем HTTP вы, очевидно, увидите, что некоторые сервисы блокируют вас, поскольку они считают, что ваши запросы слишком агрессивны, но вам также придется иметь дело с простоями некоторых из этих сервисов, которые могут затем замедлить работу всей системы. Конечно, я не говорю о неясностях в работе с заголовками HTTP (мы знаем, что некоторые серверы имеют значение между Etag а также etag и некоторые, которые будут принимать только etags с кавычками... в то время как другие откажутся от них...)
На стороне XML это еще хуже. Сначала вам нужно будет разобрать столько супа, что вы, вероятно, сможете накормить мир (каламбур!). XML кажется очень сложной наукой для многих веб-разработчиков, которые забыли, что экранирование является необходимостью, что пространства имен имеют префиксы, но также и то, что most <open> tag must eventually be </closed>, Теперь вам также придется разбираться с разновидностями RSS, ATOM или RDF и разбираться со всеми ними.
Как только вы определили правильный формат, вам также придется разобраться в данных. Я всегда цитирую временные метки в каналах, потому что люди часто их путают. Некоторые каналы, которые мы нашли, даже показывают " вчера " как <published> Дата. Как мило это? Теперь, для тех, кто делает машинно-читаемые метки времени, вы увидите, что просто с числовым значением, другие с 06/03/2012. Даже если они используют правильный формат (не указан в спецификации RSS!), Нередко люди не понимают, как работают часовые пояса (ага, для материалов, опубликованных в будущем!) Или даже для перехода на летнее время. Наконец, и это действительно законное утверждение: некоторые каналы используют не наш григорианский календарь, а, например, арабский календарь.
Разбираться (идентифицировать новое и старое) также невероятно сложно, потому что временные метки определены, но также и потому, что RSS 1.0, например, не имеет понятия. Создать его сложно, потому что многие люди помещают код отслеживания (меняется!) В ссылки или даже в текст своих записей:(
Короче говоря, опрос - это беспорядок, и с ним очень трудно справиться в масштабе. Теперь, если вы идете по этому пути, пожалуйста, используйте открытый протокол PubSubHubbub. Это маленький шаг для вас, но огромный шаг для веб-сообщества, потому что он будет расти принятия, и, если все пойдет хорошо, мы можем в конечном итоге сделать опрос. Хорошая новость заключается в том, что многие платформы приняли его, что должно значительно снизить ваши потребности в опросах.
То, что вы пытаетесь создать, не очевидно для меня, но я считаю, что использование такого решения, как Superfeedr, является хорошим подходом. Мы разберемся со всеми проблемами HTTP и максимально нормализуем XML, чтобы вам было проще его использовать (мы можем даже превратить его в JSON). Да, мы берем плату за наш сервис, но он также экономит много раз, чтобы вы могли сосредоточиться на том, что действительно отличает ваш сервис / хранилище данных от всех остальных.
К лентам обычно обращаются через HTTP GET, поэтому, если вы не хотите использовать стороннее приложение (такое как Superfeedr), на самом деле не существует опции push.
Сказав это, вариант тяги не так уж и плох. Это зависит от того, сколько данных вы хотите собрать. Для "чтения и экспорта" большинство настольных программ чтения могут иметь проблемы по количеству, но что-то без всех накладных расходов с графическим интерфейсом, как, например, Венера, вероятно, поможет вам в этом.
Различия в форматах и качестве каналов - большая проблема, но есть библиотеки, которые могут позаботиться об этом, - особенно хорош Python feedparser.
Не требуется много кода для настройки опроса каналов и передачи результатов через анализатор в БД. (Если вы настраиваете опрос самостоятельно, не забудьте проверить ETags и Last Modified заголовки - или пусть feedparser сделает это за вас).