как у них это все работает???

Для одной машины тоже лучше хранить индексы в нескольких файлах. Например можно их положить на разные диски, что ускорит чтение. Кроме того, так можно частично решить проблему обновления индекса, когда при доиндексировании нескольких документов прийдется "перелопатить" почти весь индекс. А так, разбив индекс на несколько файлов, уже будет легче, т.к. прийдется обновлять всего лишь его часть. Сооветственно при таком обновлении весь документ должен полностью сохраняться в одном файле индекса.

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

Насчет способа хранения: пост-лист сохраняют обычно отсортированным, в порядке возрастания id документов. Причин тому несколько:

1) При поиске нескольких слов нужно объединять несколько пост-листов. При отсортированных списках это делается достаточно быстро - бинарным методом или другими более эффективным.

2) Для лучшей компресии, в отсортированных списках принято хранить не абсолютные значения id документов, а относителные (чем меньше значения - тем выше степень сжатия). Например 10, 15, 17, 18, 21 хранится как 10, 5, 2, 1, 3 (т.е. 10, 10+5, 15+2, 17+1, 18+3).

Не вижу серьезной проблемы в хранении и обработке "и".

Частотность этого предлога ~3%, следовательно хватит 5-6 бит на одно словоупотребление. Кладем с запасом байт, при скорости чтения 60 Мб/сек за 1 сек можно прочитать 60 млн словоупотреблений, этого хватит на базу с общим словоупотреблением примерно 1,8 млрд. Т.е. около 15 Гб текста. Достаточно для одной машины? И это при простейшем решении.

AlexA,

А зачем? - вот в чем вопрос? Чтоб жизнь себе усложнять и индекс увеличивать?

Нормальный человек не будет "и" вводить как ключевое слово запроса. Или вы собираетесь по нему искать? :)

Кроме того, поверьте - 3% - это ОЧЕНЬ много :)

При всем при том, 60 млн/ сек. - утопия. При остальных дисковых операциях и многопоточности поиска... или у вас получилось ? :)

То, что это есть в яндексе и гугле, недостаточно?

Хорошо, например, для поиска точных фраз, а также инициалов: Иванов И.И. и Иванов А.А. - есть разница, правда?

Вы про 60 Мб/с? Эти цифры давал не я - вопрос к постановщику данной задачи.

AlexA,

Конечно, недостаточно!

Яндекс и Гугль себе такое позволить могут. Не сравнивайте кластерную систему с одним-единственным сервером и СУБД - беркли ДБ.

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

Кроме того, если такая часть речи встречается в НОРМАЛЬНОМ запросе, не требующем точности, она, скорее всего, учитывается только в окончательном ранжировании.

Давайте разделим проблемы "зачем" и "может загнуться".

На второй вопрос я попытался ответить выше, а на первый - в предыдущем посте.

Что до реализации сего в локальном поисковике, то мы это сделали (да и не только мы) достаточно давно. Правда, базы тогда были до гигабайта, машины - первые пентюхи (помните такие?).

Весь этот спор не имеет смысла потому что очень многое зависит от того для чего именно нужна поисковая система.

AlexA,

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

И вообще - в данном случае "зачем" и "загнется" - две стороны одной проблемы.

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

Artisan,

Конечно, не имеет :) но давай не тыкать пальцами в первого на деревне спорщика :)

Если можно, Artisan, чуть конкретнее. Желательно, примеры, когда стоит экономить на стоп-словах, строя индекс, а когда нет.

В то, что Вы, lagif, представляете многие аспекты проблем ПС, у меня сомнений нет. Будет время, с удовольствием могу с Вами обсудить и проблемы ранжирования.

AlexA,

Правильное ранжирование - недостижимый идеалЪ :D