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

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

Более того, они заранее не знали, существует ли искомый инструмент. Поэтому приходилось вручную просматривать FTP-хранилища, структура которых значительно отличалась. Именно эта проблема и привела к появлению одного из ключевых аспектов современного мира - интернет-поиска.

/ фото mariana abasolo

История создания

«Вместо того чтобы тратить свое время на брожение по FTP-сайтам и пытаться понять, что на них есть, я написал скрипты, которые делали это за меня, - рассказывает Алан, - и делали быстро».

<поле>:<необязательный пробел><значение><необязательный пробел>
Запись <поле> могла принимать два значения: User-agent или Disallow. User-agent конкретизировала имя робота, для которого описывалась политика, а Disallow определял разделы, к которым закрывался доступ.

Например, файл с такой информацией запрещает всем роботам доступ к любым URL с /cyberworld/map/ или /tmp/, или /foo.html:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space Disallow: /tmp/ # these will soon disappear Disallow: /foo.html
В этом примере закрывается доступ к /cyberworld/map для всех роботов, кроме cybermapper:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space # Cybermapper knows where to go. User-agent: cybermapper Disallow:
Этот файл «развернет» всех роботов, которые попробуют получить доступ к информации на сайте:

# go away User-agent: * Disallow: /

Бессмертный Archie

Хотя Archie очень старый поисковый движок, он все же предоставляет довольно мощную функциональность при поиске нужного файла. Однако по сравнению с современными поисковыми системами, он крайне примитивен. «Поисковики» ушли далеко вперед - достаточно лишь начать вводить желаемый запрос, как система уже предлагает варианты поиска. Не говоря уже об используемых алгоритмах машинного обучения.

Сегодня машинное обучение представляет собой одну из главных частей поисковых систем, таких как Google или «Яндекс». Примером использования этой технологии может быть ранжирование поиска: контекстуальное ранжирование, персонализированное ранжирование и др. При этом очень часто применяются системы Learning to Rank (LTR).

Машинное обучение также позволяет «понимать» запросы, вводимые пользователем. Сайт самостоятельно корректирует написание, обрабатывает синонимы, разрешает вопросы многозначности (что хотел найти пользователь, информацию о группе Eagles или же об орлах). Поисковые системы самостоятельно учатся классифицировать сайты по URL - блог, новостной ресурс, форум и т. д., а также самих пользователей для составления персонализированного поиска.

Прапрадедушка поисковых движков

Что касается Алана Эмтейджа, то когда его спрашивают об упущенной возможности разбогатеть, он отвечает с долей скромности. «Разумеется, я бы хотел разбогатеть, - говорит он. - Однако даже с оформленными патентами я мог бы и не стать миллиардером. Слишком легко допустить неточности в описании. Иногда выигрывает не тот, кто был первым, а тот, кто стал лучшим».

Google и другие компании не были первыми, но они превзошли своих конкурентов, что позволило основать многомиллиардную индустрию.

На тысячах анонимных FTP-сайтов. В этом многообразии пользователям было достаточно сложно обнаружить программу, подходящую для решения их задачи.

Более того, они заранее не знали, существует ли искомый инструмент. Поэтому приходилось вручную просматривать FTP-хранилища, структура которых значительно отличалась. Именно эта проблема и привела к появлению одного из ключевых аспектов современного мира - интернет-поиска.

История создания

«Вместо того чтобы тратить свое время на брожение по FTP-сайтам и пытаться понять, что на них есть, я написал скрипты, которые делали это за меня, - рассказывает Алан, - и делали быстро».

<поле>:<необязательный пробел><значение><необязательный пробел>
Запись <поле> могла принимать два значения: User-agent или Disallow. User-agent конкретизировала имя робота, для которого описывалась политика, а Disallow определял разделы, к которым закрывался доступ.

Например, файл с такой информацией запрещает всем роботам доступ к любым URL с /cyberworld/map/ или /tmp/, или /foo.html:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space Disallow: /tmp/ # these will soon disappear Disallow: /foo.html
В этом примере закрывается доступ к /cyberworld/map для всех роботов, кроме cybermapper:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space # Cybermapper knows where to go. User-agent: cybermapper Disallow:
Этот файл «развернет» всех роботов, которые попробуют получить доступ к информации на сайте:

# go away User-agent: * Disallow: /

Бессмертный Archie

Хотя Archie очень старый поисковый движок, он все же предоставляет довольно мощную функциональность при поиске нужного файла. Однако по сравнению с современными поисковыми системами, он крайне примитивен. «Поисковики» ушли далеко вперед - достаточно лишь начать вводить желаемый запрос, как система уже предлагает варианты поиска. Не говоря уже об используемых алгоритмах машинного обучения.

Сегодня машинное обучение представляет собой одну из главных частей поисковых систем, таких как Google или «Яндекс». Примером использования этой технологии может быть ранжирование поиска: контекстуальное ранжирование, персонализированное ранжирование и др. При этом очень часто применяются системы Learning to Rank (LTR).

Машинное обучение также позволяет «понимать» запросы, вводимые пользователем. Сайт самостоятельно корректирует написание, обрабатывает синонимы, разрешает вопросы многозначности (что хотел найти пользователь, информацию о группе Eagles или же об орлах). Поисковые системы самостоятельно учатся классифицировать сайты по URL - блог, новостной ресурс, форум и т. д., а также самих пользователей для составления персонализированного поиска.

Прапрадедушка поисковых движков

Что касается Алана Эмтейджа, то когда его спрашивают об упущенной возможности разбогатеть, он отвечает с долей скромности. «Разумеется, я бы хотел разбогатеть, - говорит он. - Однако даже с оформленными патентами я мог бы и не стать миллиардером. Слишком легко допустить неточности в описании. Иногда выигрывает не тот, кто был первым, а тот, кто стал лучшим».

Google и другие компании не были первыми, но они превзошли своих конкурентов, что позволило основать многомиллиардную индустрию.

Когда нетпиковец сталкивается с задачей, требующей временных затрат (например, создать проект Звезды смерти или построить компактный аппарат холодного ядерного синтеза), он в первую очередь думает, как автоматизировать эту работу. Результаты таких размышлений мы собираем на cпециальной странице нашего сайта. Сегодня мы расскажем о том, как в недрах агентства Netpeak рождается новый полезный сервис.

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

Задача

Поисковый движок клиентского проекта, с которым нам пришлось работать, создавал отдельную страницу под каждый запрос. Так как запросы бывают с опечатками, то таких страниц накопилась целая гора — как правильных, так и с ошибками. В общем — более двух миллионов страниц: поровну для русского и английского языка. Страницы с ошибками индексировались и засоряли выдачу.

Нашей задачей было сделать так, чтобы все варианты запросов — как правильные, так и с ошибками — вели на одну страницу. Например, для каждого из запросов baseball, basaball, baaeball, baselball были свои страницы, а нужно было сделать так, чтобы все варианты сходились на одну страницу с правильным запросом — baseball. В таком случае страница будет соответствовать правильной форме запроса и мы сможем избавиться от мусора в выдаче.

Примеры групп:

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

Цель

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

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

Как рождался новый метод

Самое простое решение, которое тут же приходит в голову — загнать запросы в Google, а он нам честно исправляет. Но организовать такую пробивку — довольно затратное мероприятие. Поэтому мы с товарищами пошли другим путем. Наш математик-аналитик решил использовать лингвистический подход (внезапно!) и построить языковую модель.

Что это значит? Мы определяем вероятность встретить слово в языке и для каждого слова находим вероятности допустить в нем разные ошибки. Все бы ничего, и теория тут красивая, но для сбора такой статистики нужно иметь огромный размеченный текстовый корпус для каждого языка (опять же, ближе всего к этому подошли поисковики). Естественно, возникли вопросы, как это делать и кто все это будет воплощать в код. До нас подобным делом никто не занимался (если знаете кейс — киньте ссылку в комментарии), поэтому методику разрабатывали с нуля. Было несколько идей и заранее не было очевидно, какая из них лучше. Поэтому мы ожидали, что разработка будет вестись циклически — подготовка идеи, реализация, тестирования, оценка качества, а затем решение — продолжать дорабатывать идею или нет.

Реализацию технологии можно условно разбить на три этапа. О каждом из них — подробнее.

Этап №1. Формирование проблемы. Первые грабли

Внимание! После этой строки будет много терминов, которые мы постарались объяснить максимально простым языком.

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

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

Расстояние Левенштейна показывает, какое минимальное количество изменений (удаление, вставка и замена) в строке А надо сделать, чтобы получить строку В.

• Замена символа: sh[e]res — sh[i]res, sh[o]res;
• Вставка символа: sheres — s[p]heres;
• Удаление: gol[d][f] — golf, gold.

В каждом из примеров расстояние между словом с ошибкой и правильной формой — 1 исправление.

Коэффициент Жаккарда на би- и триграммах помогает выяснить, сколько общих комбинаций из двух- или трехсимвольных слогов есть у строк А и В.

Пример: пусть мы рассматриваем строки A = snowboard и B = border. Общая формула коэффициента для биграмм имеет вид:

J = (число одинаковых биграмм для А и В) / (общее число биграмм в А и В)

Разобьем строки на биграммы:

биграммы для A = { sn, no, ow, wb, bo+, oa, ar, rd+ } - 8 штук; биграммы для B = { bo+, or, rd+, de, er } - 5 штук; Плюсиками отмечены одинаковые биграммы их 2 штуки - bo и rd.

Для триграмм будет аналогично, только вместо двух букв будут использоваться три. Коэффициент Жаккарда для них будет такой:

Пример более похожих слов:

А = baseball и В = baaeball { ba+, as, se, eb+, ba+, al+, ll+ } { ba+, aa, ae, eb+, ba+, al+, ll+ } J = 5 / (7 + 7 - 5) = 0.56

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

Большинство испытанных методов требовали терабайтов памяти и недели процессорного времени. Мы же адаптировали методы так, чтобы программе хватало 2 гигабайта памяти и одного ядра. Впрочем, миллион запросов обрабатывался примерно 4-5 дней. Так что время выполнения задачи все равно оставляло желать лучшего. Результат работы алгоритма на небольшом примере можно представить в виде графика:

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

1. Непонятно, как из групп находить правильные формы и есть ли они там вообще.
2. Неизвестно, какие пороги для ошибок использовать. Если будет большой порог (больше 3-х ошибок), то группы будут очень большими и замусоренными, если слишком маленький — то каждое слово образует свою группу, что нас также не устраивало. Найти какое-то универсальное, приемлемое для всех групп значение — невозможно.
3. Неясно, что делать со словами, которые могут быть отнесены одновременно к нескольким группам.

Этап №2. Упрощение. Новая надежда

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

Из открытого доступа были собраны следующие словари:

• английский (Великобритания);
• английский (США);
• немецкий;
• французский;
• итальянский;
• испанский;
• русский;
• украинский.

1. Если оно правильное (находится в одном из словарей) — оставляем его как есть;
2. Если оно неправильное — получаем список подсказок и берем первую попавшуюся;
3. Все слова вновь склеиваем в фразу. Если такой фразы мы раньше не встречали, то создаем для неё группу. Исправленная форма фразы становится её «центром». Если же встречали, то значит для этой фразы уже есть своя группа, и мы добавляем туда новую ошибочную форму.

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

Этап №3. Дополнения и пробуждение Силы

Проблема транслитерации решилась довольно просто и традиционно. Во-первых, сделали словарик соответствия букв кириллицы и латиницы.

В соответствии с ним преобразовали каждую букву в проверяемых словах и отметили, есть ли для полученного слова исправление по словарю. Если вариант с транслитерацией имел наименьшее количество ошибок, то мы выбирали его как правильный. А вот имена собственные — тот еще орешек. Самым простым вариантом пополнить словари оказался сбор слов из дампов Википедии. Однако и в Вики есть свои слабые места. Слов с ошибками там довольно много, а методика их фильтрации еще не идеальна. Мы собрали базу слов, которые начинались бы с большой буквы, и без знаков препинания перед ними. Эти слова и стали нашими кандидатами в имена собственные. Например, после обработки такого текста подчеркнутые слова добавлялись в словарь:

При внедрении алгоритма оказалось, что для поиска подсказок в дополненном словаре Enchant иногда требуется больше 3 секунд на слово. Чтоб ускорить этот процесс, была использована одна из реализаций автомата Левенштейна .

Если коротко, идея автомата состоит в том, что по имеющемуся словарю мы строим схему переходов. При этом нам заранее известно, сколько исправлений в словах будут для нас приемлемы. Каждый переход означает, что мы делаем какое-то преобразование над буквами в слове — оставляем букву или применяем один из видов исправления — удаление, замена или вставка. А каждая вершина — это один из вариантов изменения слова.

Теперь, допустим, у нас есть слово, которое мы хотим проверить. Если в нем есть ошибка, нам нужно найти все подходящие нам формы исправления. Последовательно мы начинаем двигаться по схеме, перебирая буквы проверяемого слова. Когда буквы закончатся, мы окажемся в одной или нескольких вершинах, они и укажут нам варианты правильных слов.

На изображении представлен автомат для слова food со всевозможными двумя ошибками. Стрелка вверх означает вставку символа в текущую позицию. Стрелка по диагонали со звездочкой — замена, с эпсилон — удаление, а по горизонтали — буква остается без изменений. Пусть у нас есть слово fxood. Ему будет соответствовать путь в автомате 00-10-11-21-31-41 — что равносильно вставке в слово food буквы x после f.

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

Что в итоге?

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

На создание кода и его испытания в общем ушло 40 часов работы математика-аналитика. Вывод: если вам однажды понадобится обработать около двух миллионов запросов — не отчаивайтесь. Такие задачи можно автоматизировать. Понятно, что добиться 100% точности будет очень сложно, но обработать корректно хотя бы 95% процентов информации — реально.

Иван Максимов

Возможности поискового движка DataparkSearch

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

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

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

Сейчас мы рассмотрим один из вариантов по организации поиска документов на файловом сервере, который был реализован на конкретной задаче.

Начальные условия

Имеется файловый сервер под управлением ОС Linux. Для совместного использования файлов установлены популярные пакеты samba и pro-ftp. На диске используется файловая система reiserfs, как наиболее производительная для работы с большим количеством маленьких файлов (документы, около 3 тысяч, различных форматов: txt, html, doc, xls, rtf). Данные отсортированы, но их объем растет с каждым днем, удаление устаревшей информации не решает проблему. Как организовать поиск по именам и типам документов, а также по контенту? Как сделать его доступным для пользователей в локальной сети?

Для решения этих вопросов нам понадобится поисковый движок, сервер баз данных (MySQL, firebirg, ...), веб-сервер Apache и около гигабайта дискового пространства для работы комплекса.

Какой из поисковых движков выбрать?

Существуют локальные поисковые машины, такие как Google Desktop Search или Ask Jeeves Desktop Search . Возможно, для организации поиска в маленькой компании или на рабочей станции пользователя, под управлением ОС Windows, эти движки могут быть полезны, но не в данном случае. Поисковые «монстры» вроде Яндекса очень дороги, но если требуется качественная помощь разработчиков, то крупным компаниям, возможно, следует подумать об его аренде. Для *nix-семейства существует несколько проектов. Это движки:

• DataparkSearch
• Wordindex
• ASPseek
• Beagle
• MnogoSearch

Перечисленные движки позиционируются как свободно распространяемые поисковые машины для работы в локальной и/или глобальной сетях. Хочу заметить, что многие проекты не мультиплатформенные и не работают под операционными системами компании Microsoft. Для Windows-систем существуют серверные решения, такие как: MnogoSearch и «Ищейка» .

Итак, коротко рассмотрим поисковые машины под *nix-платформу:

Beagle – преемник в SUSE Linux движка Htdig . Последний дистрибутив SUSE, в который вошел движок Htdig, был за номером 9, в последующих версиях компания Novell заменила его на beagle. Htdig закончил свое развитие в 2004 году, последняя доступная версия – 3.2.0b6 от 31 мая 2004 года. Новый движок в SUSE позиционируется как локальный поисковик, но возможно использовать его и в корпоративной среде.

MnogoSearch (бывший UdmSearch) – известный многим и достаточно распространенный движок. Существуют версии как под Windows (30-дневная бесплатна версия), так и под *nix-платформы (лицензия GNU). Возможна работа практически со всеми распространенными версиями СУБД SQL под обе платформы. К сожалению, на данный движок достаточно много нареканий, поэтому я не остановил свой выбор на нём.

Wordindex – движок, находящийся в стадии разработки (на момент написания статьи последняя доступная версия 0.5 от 31 августа 2000 года). Работает в связке СУБД MySQL и веб-сервера Apache. Работоспособный проект представлен только на сайте разработчиков.

ASPseek – поисковая машина, получившая в прошлом достаточно большое распространение, но в 2002 году этот движок прекратил свое развитие (последняя доступная версия данной поисковой системы 1.2.10 от 22 июля 2002 года).

DataparkSearch – клон поискового движка MnogoSearch. Позволяет производить поиск как по именам файлов, так и по их контенту. Обработка txt-файлов, HTML-документов и тэгов mp3 встроена, для обработки содержимого документов иного типа необходимы дополнительные модули. Возможен поиск информации, как на локальном жестком диске, так и в локальной/глобальной сети (http, https, ftp, nntp и news).

Поисковая машина функционирует с самыми распространенными СУБД SQL, такими как MySQL , firebird , PostgreSQL и другими. По заявлению разработчиков, DataparkSearch стабильно работает на различных *nix-операционных системах: FreeBSD, Solaris, Red Hat, SUSE Linux и других. По сравнению с MnogoSearch в движке были исправлены некоторые ошибки, изменены в лучшую сторону некоторые функции. На сайте разработчиков приведены ссылки на рабочие версии движка в сети Интернет. Большой плюс – качественная документация на русском языке.

Итак, сравнив все «за» и «против», для реализации поиска на файловом сервере был выбран движок поисковой машины DataparkSearch.

Установка

Для работы нам понадобятся: веб-сервер Apache, сервер базы данных MySQL и исходные коды DataparkSearch. Устанавливаем сервер Apache и БД MySQL (со всеми необходимыми библиотеками). Если на вашем сервере установлена иная СУБД, то можно использовать и ее (см. документацию по движку). Далее распакуем архивы DataparkSearch и приступим к сборке нашего комплекса.

Запустим скрипт install.pl и ответим на необходимые вопросы: выбор папки установки движка, базы данных и другие относящиеся к параметрам работы движка. Рекомендуется оставит настройки по умолчанию. Опытные пользователи, прочитав документацию, расположенную в папке doc, могут вручную сконфигурировать движок (команда configure). Если при инсталляции скрипт не может найти mysql, возможно не установлены библиотеки для разработчиков (libmysql14 devil). Теперь скомпилируем и установим DataparkSearch командами make и make install.

Минимальное конфигурирование

Создадим базу данных:

sh$ mysqladmin create search

Командой mysqlshow просмотрим все таблицы в БД. Сразу хочу отметить, что удобнее работать с MySQL с помощью веб-консоли phpmyadmin, но можно обойтись и стандартным набором утилит. Необходимо создать нового пользователя в MySQL:

sh#mysql --user=root mysql

mysql> GRANT ALL PRIVILEGES ON *.* TO пользователь@localhost

IDENTIFIED BY "пароль" WITH GRANT OPTION;

exit

Перезагрузим MySQL.

Допустим, имя пользователя – searcher, пароль – qwerty.

Теперь создаём файл indexer.conf в папке /etc/ движка, примеры данного файла (для некоторых задач) можно найти в папке /doc/samples исходников DataparkSearch. Пример с минимальными настройками приведен на рис. 1.

Рассмотрим файл подробнее. Как упомянуто в комментарии, команда DBAddr указывает путь к SQL-серверу (в нашем случае это MySQL), способ хранения данных и другие параметры (если необходимо). Существуют несколько режимов хранения: если не указывать dpmode, то по умолчанию будет значение single – самый медленный. Рекомендуется использовать режим cache, но если с ним возникли проблемы, можно использовать менее эффективный, но более простой в конфигурировании режим multi. Подробное описание всех параметров dbmode находится в документации.

DoStore хранит сжатые копии проиндексированных документов. Sections – модуль, предоставляющий гибкие возможности индексирования. Допустим, можно создать ограничение по тэгу или настроить индексацию не только содержимого файлов, но и URL (хост, путь, имя). Langmap – специальные языковые карты для распознавания кодировок и языков, эффективны, если документы размером более 500 байт.

Второй необходимый конфигурационный файл – файл результатов поиска search.conf. Рекомендуется взять готовый шаблон (файл /etc/search.htm-dist) и отредактировать его под свои запросы. Нужно заметить, что основные параметры, указанные в файле indexer.conf, должны совпадать с параметрами в search.htm, иначе будут ошибки при работе движка. Search.htm состоит из нескольких блоков: первый – variables – содержит данные для работы движка (скрипт search.cgi), а все остальные блоки необходимы для формирования html-страницы результатов поиска. Пример блока variables в search.conf приведен на рис. 2.

Рассмотрим search.htm подробнее. Как видно, параметры DBAddr и LocalCharset совпадают с идентичными параметрами в indexer.conf. Если ваш веб-клиент поддерживает формат xml, то можно установить параметр ResultContentType text/xml. Ниже идут HTML-блоки, необходимые для дизайна страницы результатов, они здесь не представлены из-за большого объема. Рекомендуется пользоваться готовым шаблоном, расположенным в файле /etc/search.htm-dist. В сопроводительной документации полностью описан формат HTML-блоков (дизайна), желающие могут настроить его по своему вкусу.

Теперь можно запускать файл indexer из папки sbin движка DataparkSearch с параметром -Ecreate. Если все было сделано правильно, то будут созданы необходимы sql-таблицы в БД. Если появились ошибки, следует проверить имя пользователя mysql и пароль в файле indexer.conf, это наиболее распространенная ошибка.

Для тестирования рекомендуется проиндексировать небольшой участок ресурса, чтобы если возникнут ошибки, новая переиндексация не заняла много времени. Индексирование выполняется командой indexer без параметров, в итоге нам выведут результаты: затраченное время, количество документов и скорость работы.

Скопируем файл bin/search.cgi из директории DataparkSearch в папку cgi-bin нашего веб-сервера и отредактируем файл index.shtml нашего веб-сервера Apache (расположенный в папке html), добавив в него код формы поиска:

Теперь можно зайти на ресурс localhost, используя любой доступный браузер. В появившейся форме ввести искомое слово, допустим «процессор» (см. рис. 3). В итоге мы должны получить страницу с результатами поиска, если, конечно, такие документы существуют (см. рис. 4). Если вместо страницы с результатами поиска появится документ с ошибками, то следует проверить работу скрипта. Зайдя в директорию cgi-bin веб-сервера, выполним скрипт «seach.cgi test >> test.htm». Если страница результатов сформирована правильно, следует проверить конфигурацию сервера Apache: правильно ли указан путь до cgi-скрипта, выполняется ли тестовый скрипт test.cgi в директории веб-сервера.

Если test.htm пуст или также содержит ошибки, рекомендуется проверить, существуют ли данные в базе, делается это командой «indexer -S». Возможно, следует переиндексировать сервер командой «indexer – v 5» – максимальный уровень выдачи отладочной информации. Выставив в файле search.htm команду LogLevel 5 и внимательно просмотрев логи веб-сервера, можно выяснить, как выполняется обработка данных в SQL-сервере.

Добавление дополнительных модулей (парсетов)

По умолчанию движок работает только с файлами html и txt, но возможно установить дополнительные модули (парсеты), которые преобразуют иные типы документов в html или txt (plain text). Возможна работа с xls (Excel), doc (Word), rtf (Word), ppt (Power Point), pdf (Acrobat Reader) и даже rpm (RedHar Package Manager)-файлами, в последнем будут отображаться только метаданные. В нашем случае понадобится обработка офисных форматов. Для xls и doc существует несколько парсетов: catdoc преобразует документы в txt-формат, XLHTML и vwHtml конвертируют файлы в HTML-формат.

Я рекомендую использовать пакет catdoc, так как скорость преобразования в txt-формат намного выше преобразования в HTML-формат, к тому же программа XLHTML иногда «подвисала» при конвертировании документов. Хотя разработчики предвидели данную проблему и рекомендуют во избежание «зависания» парсета установить в indexer.conf параметр ParserTimeOut 300 (число указывается в секундах), но время индексирования тогда еще более возрастет.

Также нам понадобится еще один парсет – unrtf – для работы с rtf-файлами, он конвертирует документы в html-код или text/plain-формат на выбор пользователя.

Скачаем и установим нужные пакеты, для подключения парсета нужно добавить строки в indexer.conf:

Для формата xls (программа xls2csv входит в пакет catdoc):

Mime application/vnd.ms-excel text/plain "xls2csv $1"

AddType application/vnd.ms-excel *.xls *.XLS

для документов doc параметры выглядят так:

Mime application/msword text/plain "catdoc $1"

AddType application/vnd.ms-excel *.doc *.DOC

обработка RTF-документов:

AddType text/rtf* *.rtf *.RTF

AddType application/rtf *.rtf *.RTF

Mime text/rtf* text/html "/usr/local/bin/unrtf --text $1"

Mime application/rtf text/html "/usr/local/bin/unrtf --text $1"

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

Для индексации можно добавлять любые типы документов, но движок будет показывать только ссылки на имена файлов.

Допустим, если необходимо проиндексировать rpm или iso-файлы и получить из них метаданные, вам понадобится сначала найти соответствующую программу (парсет) и добавить нужные параметры в index.conf. Список поддерживаемых типов документов можно посмотреть, например, в файле mime.types сервера Apache. Готовые решения для конвертации файлов или получения из них метаданных можно найти среди настроек пакета Midnight Commander, в файле mc.ext.

Режим хранения cache

Существует несколько способов ускорить работу движка, один из них – использовать метод хранения данных cache. Для работы в этом режиме нам потребуются утилиты cached и run-splitter, находящиеся в директории sbin относительно движка. Если у вас уже создана SQL-база данных в другом режиме (dpmode), не забудьте сначала ее удалить и только потом изменить режим хранения. Очистим базу данных командами: «indexer -С» (очистка SQL-таблиц) и «indexer Edrop» (удаление таблиц). Далее создайте из файла шаблона cached.conf-dist, расположенного в папке etc нашего движка, файл cached.conf. Не забудем изменить в нем параметры доступа к SQL БД:

Теперь можно отредактировать файлы index.conf и search.conf, изменив в них параметры:

indexer.conf

DBAddr mysql://searcher:qwerty@localhost/search/?dbmode=cache&cached=localhost:7000

search.htm

DBAddr mysql://searcher:qwerty/search/?dbmode=cache

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

cached & 2> cached.out

Демон запустится и будет записывать отладочную информацию в файл cached.out. Порт работы cached по умолчанию – 7000, но если необходимо, его можно изменить (в cached.conf).

Заново создадим SQL-таблицы для нового режима хранения данных командой «indexer -Ecreate» и проиндексируем сервер – indexer. После завершения выполним команду:

run-splitter -k

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

Дополнительные функции

В приведенной конфигурации использовались минимальные параметры настройки, с помощью дополнительных можно добиться большей функциональности и гибкости движка, все зависит от поставленных задач. Для повышения скорости работы поиска движка можно использовать модуль mod_dpsearch для сервера Apache. Потребность в данном модуле возникает, если индексируются сотни тысяч документов и необходимо повысить скорость работы движка до максимума. Также в документации можно найти и другие методы ускорения работы движка, например: оптимизация SQL БД или использование виртуальной памяти в качестве кэша.

Достаточно часто возникает необходимость в поиске грамматических форм слов. Допустим, нам нужны все формы слова «процессор» (процессоры, процессоров, ...), для этого можно настроить модули ispell или aspell. Более подробно о них написано в документации.

В DataparkSearch имеется возможность индексировать сегменты сетей, за это отвечает параметр: subnet 192.168.0.0/24 в indexer.conf.

Также возможно запрещать индексировать определенные типы файлов или конкретные папки на серверах: Disallow *.avi или Disallow */cgi-bin/*.

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

Выводы

Поисковый движок DataparkSearch – мощное средство для работы c веб-ресурсами, расположенными как в локальной сети, так и в глобальной. Проект постоянно развивается и дорабатывается, на момент написания статьи последняя стабильная версия движка 4.38 (от 13.03.2006) и снапшота 4.39 (от 19.04.2006). Должен заметить, что обновления последней версии происходят почти через день.

Мы не рассматривали вопрос о создании публичного поискового сервиса в Интернете, если же вам это требуется, ознакомтесь с соответствующей документацией по СУБД, веб-серверу и другим моментам, касающимся защиты информации от несанкционированного доступа.

Приложение

Работа

Сервер был установлен на машине: AMD Athlon 2500 Barton, 512 Мб DDR 3200 (Dual), HDD WD 200 Гб SATA (8 Мб кэш, 7200 оборотов). Конфигурация движка: движок DataparkSearch (v4.38), СУБД MySQL (v4.1.11), веб-сервер Apache (v1.3.33), производится индексация doc, xls, rtf (конвертация в text/plain), html, txt-файлов. Используется режим хранения данных multi. Обработка примерно 2 тыс. файлов, расположенных на данной машине (размер на диске ~1 Гб), и индексация их контента требует 40 мин, размер БД после работы примерно равен 1 Гб. Должен заметить, что скорость работы движка с нелокальными ресурсами будет зависеть от скорости канала. Также скорость индексирования зависит от используемых парсетов. Использование режима хранения cache улучшает скорость работы примерно на 15-20%. В качестве клиентского ПО используются веб-браузеры, проверялась работа на: Firefox, Opera, Konqueror, Microsoft Internet Explorer и даже Lynx – проблем не возникло. Всю работу серверной части движка можно автоматизировать с помощью всем известного демона cron, поместив в него нужные параметры для индексации данных.