 |
|
|
|
Возможности поискового движка DataparkSearch
Возможности поискового движка DataparkSearch Как организовать поиск информации на файловом сервере не только по названию и типу документа, но и по его контенту? Возможно ли создать подходящий инструмент, доступный и прозрачный для пользователей? В настоящее время вопрос поиска информации становится все более и более актуален. В сети Интернет давно идет конкурентная борьба между поисковыми системами, постоянно предлагающими новые сервисы, возможности и совершенные механизмы поиска. Но нужные данные сложно найти не только в Интернете. На домашних компьютерах пользователей также накапливается огромное количество и разобраться в этом многообразии иногда очень не просто. В организациях чаще всего информацию централизуют и сортируют на файловых серверах, но со временем поиск нужных документов затрудняется. Производители программного обеспечения отреагировали на данную потребность. На сегодня существуют десятки поисковых машин, работающих локально на PC, также появились серверные поисковые машины. Локальные поисковые машины в большинстве своем распространяются бесплатно, тогда как корпоративные версии, позволяющие пользователям производить поиск информации на сервере, стоят достаточно дорого. Несомненно, покупая коммерческий продукт, мы получаем грамотную техническую поддержку и другие преимущества, но небольшие организации или владельцы частных сетей не всегда в состоянии заплатить тысячи долларов за подобные продукты. К счастью, в мире Open Source существуют свободные проекты, не уступающие по функциональности своим коммерческим конкурентам, с качественной поддержкой и обновлениями. Сейчас мы рассмотрим один из вариантов по организации поиска документов на файловом сервере, который был реализован на конкретной задаче. Начальные условия Имеется файловый сервер под управлением ОС Linux. Для совместного использования файлов установлены популярные пакеты samba и pro-ftp. На диске используется файловая система reiserfs, как наиболее производительная для работы с большим количеством маленьких файлов (документы, около 3 тысяч, различных форматов: txt, html, doc, xls, rtf). Данные отсортированы, но их объем растет с каждым днем, удаление устаревшей информации не решает проблему. Как организовать поиск по именам и типам документов, а также по контенту? Как сделать его доступным для пользователей в локальной сети? Для решения этих вопросов нам понадобится поисковый движок, сервер баз данных (MySQL, firebirg, ...), веб-сервер Apache [13] и около гигабайта дискового пространства для работы комплекса. Какой из поисковых движков выбрать? Существуют локальные поисковые машины, такие как Google Desktop Search [1] или Ask Jeeves Desktop Search [2]. Возможно, для организации поиска в маленькой компании или на рабочей станции пользователя, под управлением ОС Windows, эти движки могут быть полезны, но не в данном случае. Поисковые «монстры» вроде Яндекса очень дороги, но если требуется качественная помощь разработчиков, то крупным компаниям, возможно, следует подумать об его аренде. Для *nix-семейства существует несколько проектов. Это движки:
Перечисленные движки позиционируются как свободно распространяемые поисковые машины для работы в локальной и/или глобальной сетях. Хочу заметить, что многие проекты не мультиплатформенные и не работают под операционными системами компании Microsoft. Для Windows-систем существуют серверные решения, такие как: MnogoSearch и «Ищейка» [8]. Итак, коротко рассмотрим поисковые машины под *nix-платформу: Beagle – преемник в SUSE Linux движка Htdig [9]. Последний дистрибутив 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 [10], firebird [11], PostgreSQL [12] и другими. По заявлению разработчиков, 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.
Рисунок 1. Минимальные набор параметров indexer.conf Рассмотрим файл подробнее. Как упомянуто в комментарии, команда 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.
Рисунок 2. Минимальные параметры search.htm Рассмотрим 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), добавив в него код формы поиска: <FORM METHOD=GET ACTION="/cgi-bin/search.cgi"> <INPUT TYPE="text" NAME="q" VALUE=""> <INPUT TYPE="submit" VALUE="Search"> </FORM> Теперь можно зайти на ресурс localhost, используя любой доступный браузер. В появившейся форме ввести искомое слово, допустим «процессор» (см. рис. 3). В итоге мы должны получить страницу с результатами поиска, если, конечно, такие документы существуют (см. рис. 4). Если вместо страницы с результатами поиска появится документ с ошибками, то следует проверить работу скрипта. Зайдя в директорию cgi-bin веб-сервера, выполним скрипт «seach.cgi test >> test.htm». Если страница результатов сформирована правильно, следует проверить конфигурацию сервера Apache: правильно ли указан путь до cgi-скрипта, выполняется ли тестовый скрипт test.cgi в директории веб-сервера.
Рисунок 3. Форма ввода данных
Рисунок 4. Страница результатов поиска Если 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 [14] преобразует документы в txt-формат, XLHTML [15] и vwHtml [16] конвертируют файлы в HTML-формат. Я рекомендую использовать пакет catdoc, так как скорость преобразования в txt-формат намного выше преобразования в HTML-формат, к тому же программа XLHTML иногда «подвисала» при конвертировании документов. Хотя разработчики предвидели данную проблему и рекомендуют во избежание «зависания» парсета установить в indexer.conf параметр ParserTimeOut 300 (число указывается в секундах), но время индексирования тогда еще более возрастет. Также нам понадобится еще один парсет – unrtf [17] – для работы с 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 БД: DBAddr mysql://searcher:qwerty/search/?dbmode=cache Теперь можно отредактировать файлы 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 и внести необходимые изменения в конфигурационные файлы. Далее перейдем в директорию sbin нашего движка и запустим утилиту cached с параметрами: 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, поместив в него нужные параметры для индексации данных. Ссылки:
|
Иван Максимов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
