Крутой поисковик!!!

[fisher]

Автор оригинала: [VS]
этой системе поиска абсолютно пофигу расстояние в тексте между словами? судя по тому что я увидел, она абсолютно безполезная.

позволю не согласиться. или я совсем отстал от жизни или учет расстояния и позиции слов в документе у многосерча всё ещё в 2do-листе
http://www.mnogosearch.ru/todo.html
ispell-поиск, сделанный по принципу многсерча без учета позиции и расстояний слов в принципе плох глобально, но это же не яндекс, вполне себе нормально будет искать.

 

[fisher]

кстати, странно, что за 3 страницы обсуждения про ispell - ядро как htdig так и mnogoserach - так и не поговорили. а это, повторюсь, - основа, т.к. грамматику русского языка самому реализовывать - бред. так что наиболее правильным решением (если по каким-то причинам не можете поставить себе многосерч) я вижу собственный front-end к ispell. это вполне реально. но по функциональности многосерч всё равно будет круче (но, возможно, менее удобен).

 

[Silent]

To PartizaneN:

>У меня на хостинге места не осталось....

Что, впрочем, не должно мешать тебе рассказать о принципах работы движка.

>Надеюсь ты меня понял...

Ты имеешь в виду подсветку найденных слов в оригинальном документе? Делал. А в чем тут могут быть сложности? Я надеюсь, что такой ориентированный на веб язык, как ПХП, имеет в своем арсенале функции парсинга HTML текста?

To alex_great:

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

To fisher:

ispell никак не может являться ядром многосерча. Ядром является поисковый движок. А к готовому движку прикрутить морфологию не так уж и сложно. Причем достаточно несложно (если походить несколько часов по Яндексу) сделать морфологию на основе Зализняка.

 

[PartizaneN]

2 Silent да ты меня не понял... Подсветку, выделение и т.п. можно легко сделать, а вот как сделать, чтобы было видно все фразы со словами, которые ты искал и при том, чтобы они не повторялись(в смысле слова в фразах). Опять замудрил... Ну хоть сейчаззз ты меня понял... А алгоритм у меня очень прост... Засовываю все файлы на сервере в ИНДЕКС по строкам - 1 строка - 1 файл... причем строка выглядит примерно так. урл||заглавие||сам текст||размер. Ну а в поиске ищу по строкам совпадение... Выглядит это примерно так...

$word=explode(" ",$word);
$countwords=count($word);


$file_array = file ("index.dat");
$x=1;
while( list($line_num, $line) = each( $file_array )):
$ok=str_replace("||"," ¦",$line);
$ok1=stristr($ok,$word[0]);

if(strlen($ok1)==0){$ok="";}
else{

for ($e=1; $e<$countwords ; $e++):
if($word[$e]){
$ok2=stristr($ok, $word[$e]);
if(strlen($ok2)==0){
$ok="";}
else {$ok=$ok1;}
}
endfor;

}..........

Дальше разбиваю саму строку на элементы и т.д. и т.п. Впринципе должно быть понятно...

 

[sapenov]

Автор оригинала: Silent
Тебе перевести это предложение на русский язык или сам догадаешься, в чем твоя ошибка?

P.S. Ашманов (бывший разработчик Рамблера) утверждает, что не используется там реляционная база. Подробности тут:
http://www.searchengines.ru/forum/showthread.php?s=&threadid=2365&perpage=15&pagenumber=2

друг мой, похоже вы не удосужились прочитать приведенную мною ссылку.
тов. ашманов (как и многие бывшие другие работники рамблера ), там уже не работают
[РАЗМЕРОМ=1] напишите разработчикам openfts, что они ссылаются на непроверенную информацию[/РАЗМЕРОМ]

 

[Silent]

А вы, похоже, так и не удосужились взять словарь и перевести нормально. Перевожу: "В настоящий момент OpenFTS используется для индексации архивов рассылки PostgreSQL, где находится более 160,000 сообщений, а также для индексации портала www.rambler.ru, который имеет более 500,000 документов ...".

Портал Рамблер - это не только поисковая машина, там есть много всяких документов, которые можно индексировать. Насколько точна эта информация я не знаю, но из приведенного текста никак не следует, что OpenFTS стоит на самом Рамблере, я могу поставить его дома и индексировать Рамблер. То факт, что Ашманов уже не работает в Рамблере, не означает, что новые разработчики тут же выбросили работающую систему и написали совершенно новую на PostgreSQL, и в данной ситуации я склонен верить Ашманову, у которого наверняка больше информации об этом вопросе.

 

[fisher]

Автор оригинала: Silent
ispell никак не может являться ядром многосерча. Ядром является поисковый движок. А к готовому движку прикрутить морфологию не так уж и сложно. Причем достаточно несложно (если походить несколько часов по Яндексу) сделать морфологию на основе Зализняка.

давай не будем вносить путаницу в термины. основной частью любого поисковика является морфология. у меня нет желания доказывать, почему она просто необходима, если ты вдруг с этим не согласен. я не знаю, что там с малым количеством документов, меня это не интересует. меня интересуют сотни тысяч документов. искать среди них по полному совпадению формы слова - каменный век. теперь о сложности. самому сделать морфологию на основе словаря Зализняка можно. первое - зачем, когда всё уже есть? второе: да и на луну паадумаешь, легко полететь, надо только построить корабль, сесть и всё. у меня создалось впечатление, что ты сильно переоцениваешь свои возможности. возми версию Лебедева и не открывай америк. там ~1000 разных правил почти на все случаи жизни. сам словарь содержит 112 тыс. базовых слов. 1000 правил и 100000 слов, аккуратно выверенных, вычищенных с 1997 года. разговор про несколько часов ходьбы по яндексу он не смешной, он грустный. извини за резкость, но мне сложно предположить, что за продукт ты собирался изготовить. желаю тебе скорее встать на истинный Путь и не делать ничего, что сделано до тебя. да пребудет с тобой сила

 

[Silent]

У нас видимо очень разные представления о том, что такое основа. Имея поисковый движок без морфологии возможно сделать поиск, пусть плохо, но работать будет. Имея морфологию без движка нифига сделать нельзя. Так какая же это основа, если на основе этой основы ничего построить нельзя?

>у меня создалось впечатление, что ты сильно переоцениваешь свои возможности

А я их и не пытался оценивать. Морфология на основе Зализняка у меня УЖЕ есть.

 

[PartizaneN]

Автор оригинала: fisher
давай не будем вносить путаницу в термины. основной частью любого поисковика является морфология

Основная часть - это движок!!! А морфология - это навороты...

 

[aloner]

Автор оригинала: PartizaneN
Основная часть - это движок!!! А морфология - это навороты...

Согласен.

 

[fisher]

отвечая сразу на все три предыдущих поста.
я не утверждаю, что морфология - это наше всё. дело в том, что тред-то начался вообще с preg_match, если не ошибаюсь. ну ладно, давайте посмотрим с другой стороны. хорошо, пусть главное - некий мистический движок, о котором вы говорите. тогда я не совсем врубаюсь, что такого действительно необычного и интересного в движке, который без морфологии, без ранжирования? а ранжирование вообще отдельный разговор, очень больная тема (даже для Рамблера, например). когда-то давно я поковырялся в коде многосерча, так вот, если грубо, то мы имеем: правила образования словоформ, сам словарь, несложную но удобную архитектуру хранения данных и api к этому безобразию. если приложить это к mysql, то действительно основного кода(api)- "ядра" если хотите - вот это будет _максимум_ тысяча строк - и на индексирование, и на поиск. и это и с морфологией, и с ранжированием (пусть и возможно достаточно убогим ранжированием сточки зрения "больших" коммерческих поисковых систем). если отсюда выкинуть эти фичи - что там останется? и вот я пытаюсь понять, что тогда вы имеете ввиду под движком. ну пускай есть библиотека функций, которые:
- бьют входной текст на слова и кладут их куда-то в базу или как ещё со своми весами с привязкой к некоторой сущности, полностью описывающей нужный документ
- по набору входных слов поискового запроса ищут точные совпадения и выдают результаты
это - движок? это пара сотен строк кода, имхо, это не движок.
что же я забыл? или всё-таки это - "движок"?

 

[PartizaneN]

2 all какие слова по вашему при поиске должны отображаться первыми: слова, которые первыми и ввел юзверь, либо те слова, которые идут первее в индексе...?
И как искать по шаблону не используя регулярных выражений т.е. мне надо просто в строке найти, что есть там такое слово, которое я хочу... substr_count() мне нравится, но поиск без учета регистра... Пока пользуюсь preg_match_all() он вроде не такой тормозной как eregi...

 

[Silent]

Вот эти пара сотен строк кода и есть движок. Пусть плохой, корявый, примитивный, но без него нечего делать дальше. А если он есть, можно развивать его дальше. Кстати, раз ты возился с многосерчем, может можешь уточнить, есть ли там учет расстояния между словами? А то [VS] тут говорил, что без учета расстояния - это не поиск. Я даже попробовал реализовать это в своем движке (кстати, заняло это 50 строк кода), правда для Перла это оказалось уже слишком большой нагрузкой, при нескольких тысячах хитов начинает тормозить (просто сортировка по числу ключевых слов в документе масштабируется достаточно неплохо и даже 20-30 тысяч документов сотируются за приемлимое время).

А если мерить все в строках, то могу сказать, что мой простенький морфологический анализатор занимает 320 строк на Перле (вместе с пустыми строками). Причем там все функции дублируются, одни для словаря на диске, другие для словаря, загруженного в память. Если оставить один API, будет в два раза меньше. И код для генерации самого словаря занимает тоже 300 строк. По твоим меркам это получается не анализатор. А чтобы встроить его в существующий поисковый движок, тоже много кода не потребуется.

То PartizaneN: можно самому перевести текст в нижний регистр и тогда искать любым удобным методом. Тем более, что перловые регэкспы при поиске без учета регистра все равно создают копию строки, переводят ее и шаблон в один регистр и потом ищут.

 

[fisher]

oops, delete this, plz

 

[fisher]

oops, delete this, plz

 

[fisher]

пардон, руки кривые, убейте мои два предыдущий поста.

>> про многосерч и позицию слова
см. выше. по-моему, это до сид пор в 2do-листе, но что касается нынешнего состояния проекта - я могу ошибатся. хотя в принципе, прикрутить это к нему несложно, весь вопрос в том, как прикрутить так, чтоб работало быстро. если просто хранить позицию у привязки слова к документу (это делается в лоб как раз в несколько десятков строк, не больше)- на небольшой нагрузке это будет работать, а дальше - непонятно. можно строить какой-нибудь перекрестный индекс скажем для каждой пары близких слов в каждом документе с расстоянием <=M(~10, например), можно эту размерность(2) увеличить, но тогда там имхо появится колоссальное количество алгоритмических подзадач и насколько это будет оправдано - не знаю, не разбирался.

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

 

[PartizaneN]

2fisher
>кстати, заняло это 50 строк кода
У меня это ваще занимает строки 3 от силы.... Но мне кажется, что при количестве страниц < 10000 это расстояние нах не нужно...
>Тем более, что перловые регэкспы при поиске без учета
>регистра все равно создают копию строки, переводят ее и
>шаблон в один регистр и потом ищут.
Спасибо большое... Будем знать...
Еще вопросик... Можно ли искать в файле, не занося его в массив... в смысле

$file=file("index.dat");

...

 

[Silent]

> У меня это ваще занимает строки 3 от силы

Я ведь ищу не в тексте, а в индексе. Это две большие разницы.

> Можно ли искать в файле, не занося его в массив

Можно, и даже нужно, заносить файл в одну большую строку.

Примерно так:

while (!feof ($fp)) {
$text .= fgets($fp, 4096);
}

или так:

$text = fread ($fp, $size);

А про массивы лучше вообще забыть. И вспоминать только тогда, когда совсем никак без них не обойтись. Я тут тестировал массивы в ПХП на одной простенькой задачке (выделение из текста уникальных слов), так у меня просто нет слов. Такой кривизны я от разработчиков не ожидал. Такое ощущение, что для встроенных функций они используют исключительно алгоритмы с экспоненциальной сложностью, хотя существует элементарное решение с линейной сложностью.

 

[fisher]

Автор оригинала: Silent
А про массивы лучше вообще забыть. И вспоминать только тогда, когда совсем никак без них не обойтись. Я тут тестировал массивы в ПХП на одной простенькой задачке (выделение из текста уникальных слов), так у меня просто нет слов. Такой кривизны я от разработчиков не ожидал. Такое ощущение, что для встроенных функций они используют исключительно алгоритмы с экспоненциальной сложностью, хотя существует элементарное решение с линейной сложностью.

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

 

[sapenov]

угу...
очень интересное заявление