Важное примечание: приведенные ниже вопросы не предназначены для нарушения ЛЮБЫХ авторских прав на данные. Все обходные и сохраненные данные напрямую связаны с источником.
Привет, ребята!
Для клиента я собираю информацию для создания комбинации поисковых систем и веб-пауков. У меня есть опыт с индексацией внутренних ссылок веб-страниц с определенной глубиной. У меня также есть опыт в очистке данных с веб-страниц. Тем не менее, в этом случае объем больше, чем у меня есть опыт, поэтому я надеялся получить некоторые знания и знания в этой лучшей практике.
Прежде всего, мне нужно пояснить, что клиент собирается предоставить список сайтов, которые будут проиндексированы. Итак, на самом деле, вертикальная поисковая система. Результаты должны иметь только ссылку, название и описание (например, как Google показывает результаты). Основная цель этой поисковой системы - облегчить посетителям поиск большого количества сайтов и результатов, чтобы найти то, что им нужно.
So:
Веб-сайт A содержит кучу ссылок → сохранить все ссылки вместе с метаданными.
Во-вторых, существует более конкретная поисковая система. Тот, который также индексирует все ссылки на статьи (пусть их называют), эти статьи распространяются на многие более мелкие сайты с меньшим количеством статей по сравнению с сайтами, которые попадают в вертикальную поисковую систему. Причина проста: статьи, найденные на этих страницах, должны быть очищены как можно больше деталей. Здесь возникает первая проблема: для написания скребка для каждого веб-сайта потребуется огромное количество времени, данные, которые необходимо собрать, например: название города, дата статьи, название статьи. So:
Веб-сайт B содержит более подробные статьи, чем веб-сайт A, мы собираемся индексировать эти статьи и извлекать полезные данные.
У меня есть метод, который может работать, но это требует написания скребка для каждого отдельного веб-сайта, на самом деле это единственное решение, о котором я могу думать прямо сейчас. Поскольку DOM каждой страницы полностью различен, я не вижу возможности построить алгоритм с проверкой дурака, который ищет DOM и "знает", какая часть страницы является местоположением (однако... это возможность, если вы можете сопоставить текст против полного списка городов).
Несколько вещей, которые приходили мне в голову:
Вертикальная поисковая система
- Для вертикальной поисковой системы это довольно прямолинейно, у нас есть список веб-страниц, которые нужно индексировать, должно быть довольно просто обходить все страницы, соответствующие регулярному выражению, и хранить полный список этих URL-адресов в базе данных,
- Я бы хотел разделить сохраненные данные страницы (метаописание, название и т.д.) в отдельный процесс, чтобы ускорить индексирование.
- Существует вероятность того, что в этой поисковой системе будут дублироваться данные из-за сайтов, которые имеют соответствующие результаты/статьи. Я не думал о том, как фильтровать эти дубликаты, возможно, в заголовке статьи, но в бизнес-сегменте, где данные поступают оттуда, огромные изменения в дубликатах, но разные статьи.
Скребок страницы
- Индексирование "готовых" страниц может быть сделано аналогичным образом, если мы знаем, какое регулярное выражение должно соответствовать URL-адресам. Мы можем сохранить список URL-адресов в базе данных
- Используйте отдельный процесс, который запускает все отдельные страницы, на основе URL-адреса, скребок должен теперь использовать какое-то регулярное выражение для соответствия требуемым деталям на странице и записать их в базу данных
- Достаточно сайтов, которые уже индексируют результаты, поэтому я предполагаю, что должен существовать способ создания алгоритма скремблирования, который знает, как читать страницы, не полностью совпадающие с регулярным выражением. Как я уже говорил: если у меня есть полный список названий городов, должна быть возможность использовать алгоритм поиска, чтобы получить название города, не сказав
the city name lies in "#content .about .city"
.
Резервирование данных
Важной частью паука/искателя является предотвращение индексации повторяющихся данных. То, что я надеялся сделать, это отслеживать время, когда искатель начинает индексировать веб-сайт, и когда он заканчивается, я также буду отслеживать "последнее время обновления" статьи (на основе URL-адреса статьи) и удалите все статьи, которые старше начального времени обхода. Потому что, насколько я вижу, эти статьи больше не существуют.
Устранимость данных проще с помощью скребка страницы, так как мой клиент составил список "хороших источников" (читайте: страницы с уникальными статьями). Уверенность данных для вертикальной поисковой системы сложнее, потому что индексируемые сайты уже делают свой собственный выбор произведений искусства из "хороших источников". Таким образом, есть вероятность, что несколько сайтов имеют выбор из тех же источников.
Как сделать результаты поиска
Это вопрос, отличный от того, как сканировать и очищать страницы, потому что, как только все данные будут храниться в базе данных, его нужно искать с высокой скоростью. Объем данных, которые будут сохранены, по-прежнему неизвестен, по сравнению с некоторыми конкурентами у моего клиента было указание около 10 000 мелких записей (вертикальный поиск) и, возможно, 4000 больших записей с более подробной информацией.
Я понимаю, что это по-прежнему небольшая сумма по сравнению с некоторыми базами данных, над которыми вы, возможно, работали. Но в конце может быть до 10-20 полей поиска, которые пользователь может использовать для поиска, что они ищут. С высоким объемом трафика и множеством этих поисков я могу представить, что использование обычных запросов MySQL для поиска не является умной идеей.
До сих пор я нашел SphinxSearch и ElasticSearch. Я не работал ни с одним из них, и на самом деле я не изучил возможности обоих. Единственное, что я знаю, это то, что оба должны хорошо работать с большими объемами и большими поисковыми запросами в данных.
Подводя итог
Чтобы суммировать все, вот краткий список вопросов, которые у меня есть:
- Есть ли простой способ создать алгоритм поиска, способный сопоставлять данные DOM без указания точного div, в котором находится контент?
- Какова наилучшая практика для обхода страниц (ссылки, название и описание).
- Должен ли я разделить обход URL-адресов и сохранить название страницы/описание скорости?
- Есть ли готовые решения для PHP для поиска (возможных) дубликатов данных в базе данных (даже если есть небольшие различия, например: если 80% совпадений → отмечают как дубликаты)
- Каков наилучший способ создания поисковой системы будущего поиска для данных (помните, что количество данных может увеличиваться как трафик сайта и поисковые запросы).
Надеюсь, я сделал все ясно и прошу прощения за огромное количество текста. Я предполагаю, что это показывает, что я провожу некоторое время, пытаясь разобраться в себе.