Вопрос о структуре поисковой системы
А какая конкретно стоит задача? Нужна ли поддержка морфологии? Нужен ли точный побуквенный поиск? Какой объём данных? Соотношение частоты запросов к частоте обновления? И т.д.
Есть база на сотни тысяч документов (считай просто txt файлы)
Нужно сделать поисковик по ним. Так чтобы чем больше документ подходит к запросу тем выше он находился в списке результатов поиска.
Алгоритм определения релевантности - чисто моя головная боль.
Сейчас допустим будем считать, что чем больше плотность ключевика (соотношение кол-ва вхождений запроса в текст документа к его общему объему) тем он более релевантен.
Меня интерисует что стоит хранить в базе данных а что нет.
Нужно организовать какие-то индексы и т.п. Т.к. "прочесывать" все документы налету не вариант, ибо медленно.
Частота обновления, ну в базу каждый день приходит от 10 до 1000 документов.
(Но апдейт думаю имеет смысл делать раз в какой-то разумный период, раз в 3 дня, а может раз в неделю)
Поисковиком в день пользуется x1000 пользователей.
Нужно сделать поисковик по ним. Так чтобы чем больше документ подходит к запросу тем выше он находился в списке результатов поиска.
Алгоритм определения релевантности - чисто моя головная боль.
Сейчас допустим будем считать, что чем больше плотность ключевика (соотношение кол-ва вхождений запроса в текст документа к его общему объему) тем он более релевантен.
Меня интерисует что стоит хранить в базе данных а что нет.
Нужно организовать какие-то индексы и т.п. Т.к. "прочесывать" все документы налету не вариант, ибо медленно.
Частота обновления, ну в базу каждый день приходит от 10 до 1000 документов.
(Но апдейт думаю имеет смысл делать раз в какой-то разумный период, раз в 3 дня, а может раз в неделю)
Поисковиком в день пользуется x1000 пользователей.
Вариант 1 - использовать какую-нибудь доступную БД с возможностью полнотекстового поиска (Например MySQL 4 или что-то по навороченнее). Возможно будут проблемы со скоростью, но это самый простой и наименее геморойный вариант.
Вариант 2 - считать, что все тексты написаны подряд, один за другим. В одной таблице хранить номера слов, являющихся началами текстов, в другой таблице - для каждого слова (вариант - корня слова, если используем морфологию) храним номера, на которых это слово встречается в нашем общем массиве текста. По запросу определяем, в каких позициях находятся интересующие слова, а по позициям - номера документов, в которых они встречаются и их взаимное расположение. Тут надо грамотно выбрать те слова, по которым не надо вести индекс (предлоги, местоимения, артикли, do и т.д.)
Тут быстродействие зависит от реализации, больше возможностей по маштабированию и тюнингу, но куча гемора. Ну, для большей эфективности нужна хорошая морфология.
Вариант 3 - лицензировать какое-нибудь готовое решение. Сейчас куча десктопных и сетевых поисковиков, а так же их запчастей. Внимание, реклама - http://www.abbyy.ru/arme/
Вариант 2 - считать, что все тексты написаны подряд, один за другим. В одной таблице хранить номера слов, являющихся началами текстов, в другой таблице - для каждого слова (вариант - корня слова, если используем морфологию) храним номера, на которых это слово встречается в нашем общем массиве текста. По запросу определяем, в каких позициях находятся интересующие слова, а по позициям - номера документов, в которых они встречаются и их взаимное расположение. Тут надо грамотно выбрать те слова, по которым не надо вести индекс (предлоги, местоимения, артикли, do и т.д.)
Тут быстродействие зависит от реализации, больше возможностей по маштабированию и тюнингу, но куча гемора. Ну, для большей эфективности нужна хорошая морфология.
Вариант 3 - лицензировать какое-нибудь готовое решение. Сейчас куча десктопных и сетевых поисковиков, а так же их запчастей. Внимание, реклама - http://www.abbyy.ru/arme/
А задача как возникла? Это для работы или для учебы? Тебе обязательно движок полнотекстового поиска с нуля надо написать или что?
С поисковиками я связан как по учебе так и по работе.
По учебе моя задача - алгоритм определения релевантности.
А как вытекающая вытекает задача написания качественной оболочки алгоритма, т.е. поисковика, которая интересна мне сама по себе, курсач можно сдать и при объеме документов x100, т.к. научника интерисует лишь сам алгоритм и его математическая база.
Ну и как говорилось ранее, самый тупой алгоритм - плотность ключевика, но даже его не знаю как толком на машину переложить, в момент получения запроса анализировать документы - слишком мемдленно.
По учебе моя задача - алгоритм определения релевантности.
А как вытекающая вытекает задача написания качественной оболочки алгоритма, т.е. поисковика, которая интересна мне сама по себе, курсач можно сдать и при объеме документов x100, т.к. научника интерисует лишь сам алгоритм и его математическая база.
Ну и как говорилось ранее, самый тупой алгоритм - плотность ключевика, но даже его не знаю как толком на машину переложить, в момент получения запроса анализировать документы - слишком мемдленно.
> плотность ключевика, но даже его не знаю как толком на машину переложить
Число вхождений на объём текста.
Объём текста можно измерять в словах, предложениях, буквах, знаках.
---
...Я работаю антинаучным аферистом...
Число вхождений на объём текста.
Объём текста можно измерять в словах, предложениях, буквах, знаках.
---
...Я работаю антинаучным аферистом...
в момент получения запроса анализировать документы - слишком мемдленноНу ясно море, индексы строить надо..
А как вытекающая вытекает задача написания качественной оболочки алгоритма, т.е. поисковика
Это совершенно новый, необычный взгляд на проблему.
Ты наверное просто не представляешь трудоемкость создания поискового движка. Не занимайся поисковым движком. Т. е. совсем. Считай, что он есть и сконцентрируйся на алгоритме вычисления релевантности. Если для демонстраций непрменно нужен поисковик, то надо найти open source поисковик, и встраиваться в него. Например для Java существует весьма приличный Lucene .З. Ы. Ни один известный приличный поисковик не хранит полнотекстовые индексы в реляционной БД, все используют специализированные индексы на файлах. Так что имхо не стоит пытаться построить поисковик, как надстройку над MySQL или чем-то подобным.
я бы почитал блог разработчика движка рамблера.
найти можно через яндекс
найти можно через яндекс
Так что имхо не стоит пытаться построить поисковик, как надстройку над MySQL или чем-то подобным.Ты знаешь, как-то раз народ придумал одну надстройку над постгресом... Кажется, с нее начался рамблер
Ты знаешь, как-то раз народ придумал одну надстройку над постгресом... Кажется, с нее начался рамблерНачал сочинять легенду?
Кажется, с нее начался рамблерНу и чего? Ключевое слово здесь"начался". Скажи еще, что оно там до сих пор так устроено.
To , я понимаю в чем можно измерять плотность Меня интерисует как хранить результаты измерений.
ОФФТОП:
Рамблер довольно стремительно несется к забвению.
Меня интерисует как хранить результаты измерений.ОФФТОП:
Рамблер довольно стремительно несется к забвению.
Это не показатель. Мало ли какой плохой движок в удачное время удачно использовали.
Скажи еще, что оно там до сих пор так устроено.Конечно! Постгрес же используется!
Рамблер довольно стремительно несется к забвению.Точно. Скоро Дельта-Софт его поглотит. Как только напишет поисковую систему.
Начал сочинять легенду?Да вроде нет.
Ща попробую нарыть ссылку.
UPD
Мда, все как будто вымерли, или почистили все нахрен. Пока нашел только ссылку, где Бартунов, разработчик tsearch, признается в том, что принимал участие в разработке Рамблера.
> как хранить результаты измерений.
Наиболее часто запрашиваемые ключи.
Например, полсотни, сотню, две, три первых по частоте.
---
...Я работаю антинаучным аферистом...
Наиболее часто запрашиваемые ключи.
Например, полсотни, сотню, две, три первых по частоте.
---
...Я работаю антинаучным аферистом...
может Google Desktop for Enterprise подойдёт?
Не подойдет также как и Яндекс.desktop
выложи их на сайт и индексируй яндексом 
советую lucene
опенсурсная библиотека
потратишь 3 дня на изучение ее внутренностей
верней на поиск места, куда вставить свой код алгоритма определения релевантности
это будет быстрее и проще чем писать все сначала
опенсурсная библиотека
потратишь 3 дня на изучение ее внутренностей
верней на поиск места, куда вставить свой код алгоритма определения релевантности
это будет быстрее и проще чем писать все сначала
Сходи на searchengines и узнай что думают о Яндексе
Нетовские поисковики в данном случае пользовать вобще без смысла, т.к. они в основном в последнее время ориентируются на ссылочное ранжирование.
А их десктоп версии мягко говоря не справляются.
lucene... Спасибо, пороюсь.
Нетовские поисковики в данном случае пользовать вобще без смысла, т.к. они в основном в последнее время ориентируются на ссылочное ранжирование.
А их десктоп версии мягко говоря не справляются.
lucene... Спасибо, пороюсь.
раскладываешь индексы по первой паре букв на сервера. в кэше хранишь последние запросы. при индексации определяешь на какие сервера инфу о файле класть. дальше селекты с тех серверов на которых лежит инфа по конкретному запросу. потом ещё кластер ... и будет яндекс
По первой паре букв чего? Запроса, тогда какого? Названия файла, а смысл? ....
sourceforge на днях выложил в открытый доступ проект - свой внутренний поисковик. который они используют на своих серверах.
Не помню его название, ask google
Не помню его название, ask google
Оставить комментарий
gruzvezem
Народ кто-нить сталкивался с разработкой поисковика?Можете помочь в таком вопросе:
Как по уму организовать хранение информации:
Есть документов несколько сотен тысяч, по ним организуется поиск, выдача результатов идет с учетом релевантности документа запросу.
Понятно что нужно делать различное хэширование, индексирование и т.п. Но не по каждому же запросу.
Мож кто сможет ссылку дать на что-нить по типу учебника по этой теме.