Похоже ничего не делают :) Весь вопрос как определить переменная сессии это или нет? Не исключено что на каком нибудь сайте переменная 'PHPSESSID' даже с 32 байтовым значением будет не сессией.
При считывании страницы, нужно смотреть на пришедшую куку в которой записывается идентификатор сессии и искать этот идентификатор в URL'ях контента страницы, если идентификатор нашелся - можно смело делать выводы что это переменная сессии и выкусывать его с URL. Такой способ работает для любого количества считываемых за один проход страниц.
Если crawler будет принимать cookie и за один проход индекировать много страниц с одного сайта, то таких страниц с сессией в URL'е наверное будет не много. Я имею ввиду сессии PHP которые передаются в параметрах только один раз и затем хранятся в cookie браузера.
Может подойдет такой вариант - объединить таблицу "саму на себя" и отсортировать в порядке разницы позиций.
Для таблицы index(doc_id, word_id, weight, pos) запрос для двух слов ($word_id1, $word_id2) будет выглядеть так:
select i1.doc_id from index i1, index i2 where i1.doc_id=i2.doc_id and i1.word_id=$word_id1 and i2.word_id=$word_id2 and (i2.pos - i1.pos) > 0 order by (i2.pos - i1.pos)
Если предполагается ранжировать еще и в порядке веса слова в документе дописываем ...order by ((i2.pos - i1.pos) + N * ((i1.weight + i2.weight) / 2))
N - коэфициент "важности" веса слова
weight - чем меньше значение, тем вес выше
По идее можно написать такой запрос для 3-x и более слов. Под каждое количество слов свой запрос.
Верно, но можно перетранслировать запрос в форму ((функция || функцию) && chmod). Видимо и Яндекс хранит "не нормальную форму слова", т.к. позволяет искать точное соответствие без подключения морфолигии (такая возможность описана в синтаксисе запросов расширенного поиска).
А почему бы и нет? :)
Подумайте как работает морфология mail.ru поверх Гугла. А ведь Гугл ничего не знает о русской морфологии.
А смысл в таком хранении - отсутстивие возможности децентрализованно назначать словам идентификаторы.
На этапе поиска можно обойтись и без идентификаторов слов. Сегмент индекса можно сделать состоящим из двух файлов:
Файл смещений - файл для поиска начала и длины постлиста в индексе. Ключем для в этом файле будет слово в "в текстовом виде", и будет иметь переменную длину. Значением - абсолютное смещение начала постлиста в индексе и его длина. Для такого файла подойдет база BerkeleyDB, в ней есть поддержка ключей переменной длины.
Файл индекса - собствено инвертированный индекс, где хранятся списки документов соответствущих словам.
Похоже идеальной хеш функции в природе не существует :) Близкая к идеалу - CRC32, о чем уже писали. Кстати она используется в нескольких проектах с открытым исходным кодом.
Как правило, id документов в списке хранят в порядке возрастания их идентификаторов. Причин такого вида хранения несколько:
1) Возможность бысторого слияния (к примеру бинарным методом) нескольких таких отсортированых списков для многословных запросов.
2) Такие списки эфективно компрессируются. Алгоритмы компрессии (Elias gamma или delta, Variable byte и еще добрый десяток) целых положительных чисел (которымы являются идентификаторы документов) дают лучшую степень сжатия для малых чисел. А в отсортированных списках как раз есть возможность хранить не абсолютные идентификаторы а относительные, т.е хранить разницу от предыдущего значения, например список id документов: 910, 912, 915, 920, 921 хранится как: 910, 2, 3, 5, 1.
Есть aot.ru для Linux под LGPL лицензией.
Вот немного по теме - хранение лексикона в сжатом виде:
http://www-db.stanford.edu/cs347.2001.spring/handouts/lecture2-4in1.pdf
