Признаки похожести

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

Artisan, причем здесь письма?

речь идет о похожести страниц, а не о регистрации ресурсов и доставке почты.

Ну да. Запросили страницу - если дубль - запомнили, что по такому-то адресу дубль. 10 тыс. страниц не так много же, их даже в индекс заносить не надо.

Т.е. алгоритм следующий:

1. запросили страницу

2. сравнили со всеми страницами в базе...

дальше продолжать? ;)

прошу еще учесть, что есть ряд сайтов, которые доступны как ...com, так и ...net

а еще есть сайты, которые имеют различные домены (и даже зеркала в разных уровнях - типа tra-la-la.com и tra.123456.net)

Возвращаясь к началу - по каким признакам производить выборку страниц из базы для последующего сравнения на похожесть?

Хотя, для себя я уже вроде решил...

При индексировании страниц берется сугубо контент (удаляются все теги) и вычисляется его контрольная сумма.

При индексации следующей страницы - сверяется контрольная сумма текущей страницы и производится проверка наличия такой суммы среди проиндексированных страниц.

Страницы с одинаковой контрольной суммой проверяются методом шинглов на похожесть.

Критика будет? ;)

Зачем так сложно? Сделайте массив в котором на местах зависящих от хэша будут номера счетчиков и сравнивайте страницы в этих корзинах.

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

Можно хранить для всех имеющихся в базе страниц хеши 10-словных последовательностей. Таблицу хеш/документ или хеш/список документов. И когда вы получаете новый текст - считать для него эти хеши, и выборочно проверять - нет ли уже таких. Если есть - брать те документы, в которых они есть, и сравнивать с текущим.

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

Надо было сразу сказать в постановке задачи - четкие дубли вы хотите найти или нечеткие. Если четкие - то хэша всего текста должно хватить... Если нечеткие - то шинглы надо использовать.

Как правильно отметил Interitus лучше брать частичные хэши а так как их много то для скорости проверять только счетчики тех страниц которые попадают в корзину одинаковых хэшей.

Потому, что робот не знает, какой параметр будет - на то он и робот.

И к счетчикам это никакого отношения не имеет (я их привел только в качестве примера)

Мне это представляется примерно так:

1) Берется контент страницы освобожденный от тегов

2) Если размер страницы меньше некого значения, контент страницы циклически размножается до достижения нужного размера

3) Для страницы вычисляются набор шинглов

4) Из набора шинглов отбираются только кратные некому числу, т.е. их будет не больше чем это число

5) Для каждого полученого шингла ищем дубликат среди хранилища шинглов уже ВСЕХ ранее добавленных страниц

6) Ищем документы у которых совпадает один или несколько шинглов с искомым (необходимое количество совпадений шинглов можно выяснить эксперементально на реальных данных).

7) Для надежности сравниваем полученный список документов с искомым при помощи методов нечеткого сравнения.

8) Если решили что дубликатов документа ранее несуществовало - ДОБАВЛЯЕМ его шинглы в некое хранилище по которому мы ищем в п. 5.

п. 3 - какую хеш функцию подобрать?

п. 4 - неясно какое это должно быть число?

п. 5 - мне кажется что такой поиск не займет много времени, на небольших объемах подойдет даже sql база.

п. 6 - сколько должно быть совпадений шинглов чтобы документы считать идентичными?