eshum

Рейтинг
17
Регистрация
12.01.2004
Должность
Programmer
Как писал MaxGubin

Честно не слышал о таком решении. Во всех известных мне вариантах кластерного решения информация об одном документе помещалась на одном узле. Это естественно вытекает из более простой реализации индексации и поиска.

Судя по всему так работал Рамблер предыдущей версии и .Turtle


1. Хотелось бы узнать ссылочку на какую-нибудь доку на русском посвещенную поисковым системам для начинающих. Точнее именно применяемым в них технологиям. Как индексируется информация, как хранится информация. Мне интересно не готовые решение, а скорее теоретическая часть...

На русском практически ничего и нет, а вот на английском полно - http://www.google.com/search?q=Information+Retrieval+Course


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

http://www.aot.ru/ ?

Как писал MaxGubin

Если данные часто меняются и требуется большая скорость обновления, то пост-листы бьются на отдельно обновляемые кусочки (что, кстати может улучшать производительность MPMGJN и, соответственно, поиска фраз), позиции в документах делаются устойчивыми к изменению документа и еще десяток известных решений. Тем самым достигается уменьшение на порядки объема изменений по сравнению с обновление "в лоб".

Согласен, если требуется бысто обновить произвольный документ, лучше хранить постлист кусочками. Правда есть спорные моменты: что делать если после обновления блок становится больше по размеру, переносить данные в новый? Или как быть с фрагментацией таких блоков которая возникнет после некоторого количества обновлений? Если таких блоков будет много в постлисте и они не будут располагаться подряд, упадет производительность поиска т.к. подвод головки винчестера к началу блока (diskseek) не самая быстрая опрерация.

Что касается глобального инвертированного индекса (когда инфомация о документе находится в разных индексных файлах), обновления еще более затруднительны если эти файлы находятся на разных машинах.

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

Чем длинее запрос пользователя, тем дольше информация ищется в индексе

Иногда может быть и наоборот - чем больше слов в запросе, тем короче список результатов поиска, а значит и меньше времени потребуется на ранжирование. При большом количестве слов в запросе производительность, как мне кажется, будет больше "упираться" на объединение списков документов соответствующих каждому слову запроса. Подробне про объединение упорядоченных последовательностях можно посмотреть: Интерполяционный поиск, Hwang-Lin merging, binary merging algorithm

Как писал !Иван FXS
Какие "блоки", если многие поисковики позволяют ТОЧНО указывать в запросе расстояние между "запрашиваемыми" словами!

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

Отсюда вывод: если поисковик позволяет искать внутри предложения - он использует блочное хранение контента.

Могу предложить рекламу на wap.gala.net

Посещаемость около 150 000 хитов в сутки, аудитория сайта русскоязычная в основном Россия, Украина, зарубеж.

Прайс можно посмотреть здесь

1 234
Всего: 37