 |
|
|
|
Тестируем движки поисковых машин
Тестируем движки поисковых машин Большинство из вас каждый день пользуется поисковыми машинами в Интернете. Какие они изнутри? Чем они отличаются? Разные компании, разрабатывающие поисковые движки, пытаются занять ниши на рынке, кто-то совершенствует пользовательский интерфейс, другие заботятся о скорости работы и функциональности, третьи пытаются охватить все популярные платформы, а другие собирают все перечисленные возможности. Некоторые разработчики поисковых движков не выдерживают конкуренции и выходят из борьбы, иные переходят частично или полностью на «коммерческие рельсы». Надеюсь, обзор прольет свет на некоторые проекты, продемонстрирует их преимущества и недостатки в различных задачах. Задача. Файловый сервер В сети имеется файловый сервер под управлением ОС Linux. Для совместимости с различными задачами на сервере установлены популярные пакеты samba и proftpd. Количество документов – около 2 тысяч (занимаемый размер на диске примерно 1,5 Гб), различных форматов (txt, html, doc, xls, rtf), используется файловая система reiserfs (3-я версия). Отмечу, что большая часть документов (около 80-85%) состоит из форматов MS Excel (xls) и MS Word (doc). Аппаратное обеспечение файлового сервера: AMD Athlon 2500+, 512 DDR 3200 (DUAL), HDD 160 Гб WesternDigital SATA (8 Мб кэш, 7200 оборотов). Именно этот документооборот мы и будем индексировать. Возможно, кто-то задастся вопросом: «Мы рассматриваем движки поисковых машин, почему бы не тестировать их на реальных внешних ресурсах, например на www.samag.ru?» Сделано это для того, чтобы максимально не зависеть от пропускной способности канала. Поисковые машины будут устанавливаться на практически идентичную машину, расположенную в данной сети. Пропускная способность локальной сети 100 Мб (half duplex). Все движки будут тестироваться с максимально едиными условиями, но все же отличными. Связано это с тем, что разные движки обладают различным функционалом, инструментарием, некоторые иногда в чем-то ограничены (коммерческие версии). В конце обзора каждого движка будут даны примерные сравнительные характеристики. Итак, приступим к обзору, установке, конфигурированию и сравнению движков. Обзор поисковых машин Движки поисковых машин можно отнести к двум категориям. Первые – корпоративные, предназначенные для работы с множеством клиентов и группой ресурсов. К ним можно отнести рассматриваемые далее движки Yandex.Server, DataparkSearch, Mnogosearch, ASPseek и htdig. Вторые – пользовательские, предназначенные для облегчения поиска информации на компьютере пользователя. В связи с тем, что пользовательские движки поисковых машин под ОС Linux плохо освещены в Интернете, и для полноты картины данного обзора я также рассмотрю движок Beagle (как наиболее «сильного» представителя группы). Yandex.Server Известный многим движок поисковой машины Яндекс – коммерческий проект. Для ознакомления существует shareware-версия движка, которую мы и рассмотрим. К сожалению, пробная версия во многом ограничена. Установить движок можно под операционные системы FreeBSD, Linux, Solaris, Windows. По заявлениям разработчиков, при заказе версии Professional возможно портирование движка практически под любую платформу заказчика. Рассмотрим установку движка под Linux из tgz-архива. Скопируем и разархивируем Яndex.Server Standard. Распаковывать архив лучше в корень диска: gzip -d name.tgz / tar -xvf name.tar / Движок сконфигурирован на работу в директориях /etc/rc.d/inid.d, /usr/local/yandex и /usr/local/sbin/yandex. Если вам необходимо расположить все файлы в удобном для вас месте, отредактируйте параметры рабочих директорий WORK_DIR и YANDEX в файле yandex.sh. Первое, что сразу бросается в глаза после установки, – отсутствие исходных кодов столь привычных пользователям открытых систем. Заглянем в файл конфигурации yandex.cfg.dist (расположенный в папке движка). Все комментарии на русском языке, никаких проблем возникнуть не должно. Файл разделен на две секции server (параметры работы серверной части движка) и collection (параметры индексирования). Для начала работы движка необходимо создать файл yandex.cfg из файла шаблона yandex.cfg.dist и отредактировать параметры в секции collection: StartUrls (индексируемый ресурс) и IndexLog (запись результатов индексирования), а в секции server – Serverlog (запись отчета работы сервера). По умолчанию многие подсекции закомментированы, допустим, для индексации text/plain формата нужно удалить в подсекции DocFormat символы <!-- и --> (или закомментировать их символом #). Добавим форму поиска на заглавную страницу нашего apach сервера (см. рис. 1): <FORM METHOD=GET ACTION="http://HOST:17000/"> <INPUT TYPE="text" NAME="text" VALUE=""> <INPUT TYPE="submit" VALUE="Search"> </FORM>
Рисунок 1. Примеры форм поисковых движков HOST – имя ресурса с Yandex-сервером. Теперь поиск доступен для пользователей нашей локальной сети. Итак, программа настроена, запустим скрипт «yandex.sh start» и зайдем на ресурс http://localhost:17000/admin (см. рис. 2). Перед нами появится веб-интерфейс, состоящий всего из трех основных функций: запуска индексирующего «паука», открытия доступа пользователям к поисковый машине и остановки Yandex.Server. Если все настройки были выполнены правильно, можно начать индексирование и запускать поиск для пользователей (см. рис. 3).
Рисунок 2. Администрирование Yandex.Server
Рисунок 3. Пример результата поиска Yandex.Server Хотелось бы отметить, что проблем и неудобств в конфигурировании движка не возникало. Простая настройка и качественная документация – это несомненно огромные плюсы. Также к преимуществам относится высокая скорость движка: время индексации и поиска осуществляется в очень короткое время, но об этом позже. Неприятным моментом оказалось то, что в shareware-версии достаточно много ограничений, например, нет возможности редактировать файл результатов поиска, как и добавление дополнительных модулей (парсетов) для обработки иных типов файлов (doc, xls, rtf и другие). Так как в shareware-версия движка нет возможности индексировать форматы, отличные от HTML и text plain для проведения тестирования по скоростным характеристикам и получения «чисел», все xls-, doc-, rtf-документы были конвертированы пакетами catdoc и unrtf в формат txt. Итак, индексирование 2000 документов (text/plain) объемом 170 Мб заняло чуть менее 2 минут. Очень впечатляющая скорость, но есть подозрения, что обработка тех же файлов в их исходных форматах (xls, doc, rtf их объем в 5-7 раз больше) займет время, пропорциональное размеру файлов, плюс время работы внешнего модуля (парсета). Время поиска по базе также феноменально – менее секунды. DataparkSearch В статье «Возможности поискового движка DataparkSearch» [8] мы уже рассматривали установку поисковой машины, поэтому я коснусь лишь новых моментов, появившихся в движке. Последняя стабильная версия (на момент написания статьи) 4.40.1, версия снапшота 4.41 от 16.07.2006, как уже было отмечено, обновление и исправление движка происходят достаточно оперативно. Какие интересные и полезные функции были добавлены после версии 4.38? Была улучшена работа движка в режиме cache, добавлена возможность сборки модуля mod_dpsearch для веб-сервера Apache без пересборки всего движка. Последнее нововведение было сделано в связи с тем, что многие пользователи вначале конфигурируют поисковый движок для работы без модуля, а позже, желая достичь максимальной производительности (или просто «посмотреть, как это работает»), пересобирают весь движок для получения mod_dpsearch. На данный момент некоторые нововведения не вошли в официальную документацию движка, поэтому ниже будет приведен пример компиляции модуля для веб-сервера Apache. Раз уж зашел разговор о документации, отмечу, что на веб-сайте проекта выложена документация по версии движка 4.39, в самом же дистрибутиве находится обновленная для последней версии 4.41, так что будьте внимательны. Итак, чем же достигается большая скорость работы движка за счет данного модуля? mod_dpsearch совмещает в себе функции searchd и search.cgi. Первый хранит в памяти некоторые загруженные данные, без него движок каждый раз при запросах будет читать информацию с диска. Второй файл – скрипт поиска и выборки информации из СУБД, как правило, каждый раз загружается с жесткого диска. Модуль хранит большинство данных в памяти, а не подгружает постоянно с жесткого диска нужную информацию, за счет этого и достигается большая эффективность движка. Рассмотрим теперь конфигурирование. После распаковки движка запустим конфигуратор не скриптом мастером установки (install.pl), а иначе: # ./configure –enable-apachecacheonly Далее компиляция происходит стандартными командами «make && make install». Новоиспеченный откомпилированный модуль будет располагаться вместе с остальными модулями веб-сервера в папке /etc/httpd/modules/ (или /etc/httpd/libexec/). Теперь добавим в файл конфигурации apach сервера (скорее всего /etc/httpd/conf/httpd.conf) информацию о модуле: # Директивы загрузки LoadModule dpsearch_module modules/mod_dpsearch.so AddModule mod_dpsearch.c # Конфигурационные файлы модуля <Ifmodule mod_dpsearch.c> DataparkSearchdConf /usr/local/dpsearch/etc/modsearchd.conf <Location /search> SetHandler dpsearch DataparkSearchTemplate /usr/local/dpsearch/etc/modsearch.htm </Location> <Location /storedoc> SetHandler dpstoredoc DataparkStoredocTemplate /usr/local/dpsearch/etc/modstoredoc.htm </Location> </IfModule> Как вы видите, конфигурационные файлы – это копии файлов без приставки «mod», расположенных в директории etc движка, достаточно просто скопировать их и все, модуль готов к работе. Так как примеры конфигурационных файлов были описаны в предыдущей статье, не буду к ним возвращаться, также напомню, что не стоит забывать про штатную документацию движка. Запустим веб-сервер командой «service httpd start», обратимся по адресу localhost/search, перед нами появится форма поиска движка DataparkSearch. Отмечу, что сами разработчики рекомендуют для наибольшей эффективности работы комплекса использовать именно mod_search совместно с режимом хранения cache. В предыдущей статье уже были представлены скоростные характеристики движка, но для примерного сравнения все же повторюсь, индексирование примерно 2000 файлов (txt, html, doc, xls, rtf) в режиме хранения данных cache занимает примерно 30 минут. При добавлении модуля mod_search скорость поиска практически не выросла, около одной секунды. Возможно, при большем количестве данных и построении сложных поисковых запросов эффективность от использования модуля для сервера Apache будет более наглядна. MnogoSearch MnogoSearch [3] – это многим известный и распространенный движок, входящий в комплект некоторых дистрибутивов Linux. Возможна установка движка под Windows и Linux/BSD-платформы в «связке» с различными SQL СУБД (MS Access, MySQL, PostgreSQL, Interbase, MS SQL, Oracle и другие). При первом взгляде на MnogoSearch сразу бросается в глаза схожесть с его клоном – DataparkSearch, но это не совсем так. Ознакомившись с функционалом и настройками данной поисковой машины, вы в этом убедитесь. Для работы понадобится MySQL и веб-сервер Apache. После распаковки архива движка вы видите уже знакомый нам файл install.pl (мастер конфигурирования), запустим его и ответим на все необходимые вопросы, такие как выбор пути установки движка, SQL СУБД и другие. Далее откомпилируем движок стандартными командами «make && make install». Перейдем в дирректорию с установленным движком. Первое, что можно заметить, – практически идентичность папок и файлов с DataparkSearch, даже при беглом осмотре конфигурационных файлов (indexer.conf и search.htm) это мнение усиливается. Сразу хочу предупредить пользователей, работающих с DataparkSearch, не следует копировать конфигурационные файлы в MnogoSearch, при кажущейся однотипности движки очень разные. Конечно, из эксперимента можно сделать так – переписывать, переконфигурировать и добавлять информации придется много, намного проще взять готовые шаблоны файлов MnogoSearch и исправить параметры под свои задачи. Но мы отвлеклись, продолжим настройку. Создадим базу данных в MySQL командой: sh$ mysqladmin create search Если у вас не создан пользователь в MySQL, то создайте его: sh$mysql --user=root mysql mysql> GRANT ALL PRIVILEGES ON *.* TO пользователь@localhost IDENTIFIED BY 'пароль' WITH GRANT OPTION; exit Для минимальной конфигурации движка необходимо indexer.conf-dist (шаблон, находящийся в папке etc относительно движка) переименовать в indexer.conf и изменить некоторые параметры. Первое и необходимое – указываем используемую СУБД, имя и пароль пользователя в MySQL, название базы данных и используемый режим хранения данных (о dpmode будет рассказано позже). DBAddr mysql://пользователь:пароль@localhost/search/?dbmode=режим Так как мы будем индексировать txt-, html-, doc-, xls-, rtf-файлы, то закомментируйте строки, запрещающие их индексацию: #Disallow *.tex *.texi *.xls *.doc *.texinfo #Disallow *.rtf *.pdf *.cdf *.ps Также необходимо расскомментировать три строки, отвечающие за конвертацию офисных форматов в формат text, понятный MnogoSearch: Mime application/msword "text/plain; charset=utf-8" "catdoc -a -dutf-8 $1" Mime application/vnd.ms-excel text/plain "xls2csv $1" Mime "text/rtf*" text/html "rthc --use-stdout $1 2>/dev/null" И последнее – укажем индексируемый ресурс: Server ftp://192.168.0.11/ Конфигурационный файл не приведен здесь целиком из-за большего объема, но если вы желаете достичь большей функциональности «паука», рекомендуется ознакомиться с сопроводительной документацией. Теперь подробнее о режимах dpmode. В MnogoSearch с версии 3.2.16 отключена поддержка режима cache в связи с найденными там ошибками, данный режим был заменен на blob. Именно его и рекомендуют использовать разработчики, но если верить документации, движок в данном режиме не работает с СУБД Interbase/Firebird и SQLite. На мой взгляд, это упущение, так как Firebird становится все более и более распространенной базой данных. Использование более медленного режима dpmode – multi сильно тормозит движок, но позволяет использовать его с Firebird. Очень хочется надеяться, что разработчики решат данную задачу. Должен напомнить, что пакеты catdoc и rthc – внешние программы, их нужно установить до начала индексации. Если необходимо обрабатывать иные типы файлов, то нужно установить и другие парсеты (пакеты), более подробно мы говорили о них в предыдущей статье, поэтому не будем рассматривать этот вопрос (информацию с некоторыми примерами о парсетах можно также найти в документации). Второй файл конфигурации – это search.htm, состоит из двух основных блоков, первый содержит данные для скрипта search.cgi, второй – дизайн шаблона вывода информации. Необходимо изменить параметр DBAddr, он должен совпадать с таким же в indexer.conf DBAddr mysql://пользователь:пароль@localhost/searchmn/?dbmode=режим Если указанные параметры будут иными, движок вместо вывода искомой информации сообщит вам о соответствующей ошибке. Это наиболее распространенная ошибка при конфигурировании движка, поэтому будьте внимательны. Скопируем search.cgi из директории bin движка в директорию cgi-bin веб-сервера и пропишем форму для вызова скрипта в index.shtml: <FORM METHOD=GET ACTION="/cgi-bin/search.cgi"> <INPUT TYPE="text" NAME="q" VALUE=""> <INPUT TYPE="submit" VALUE="Search"> </FORM> Минимальное конфигурирование выполнено, можно создать SQL-таблицы и начать индексацию. Команда: ./indexer -Ecreate создаст все необходимые записи в MySQL, если появились сообщения об ошибке – внимательно посмотрите выходную информацию выше, чаще всего это ошибки об отсутствии доступа. Для начала индексации просто запустите indexer, если вы хотите проиндексировать небольшое количество документов, то запустите «indexer -n N», где N количество файлов или с параметром «indexer -с N», где N время работы «паука» в секундах. Если используется режим dpmode – blob, то по окончании работы «паука» нужно выполнить команду indexer – Eblob. Теперь о скоростных характеристиках. Индексируются те же 2000 файлов, время индексации в режиме dpmode-blob занимает чуть менее 20 минут. Время поиска по базе около секунды. Пример результатов поиска MnogoSearch смотрите на рис. 4.
Рисунок 4. Пример результата поиска MnogoSearch Beagle Поисковая машина хорошо знакома пользователям ОС SUSE Linux от Novell. Именно в этот дистрибутив включен по умолчанию «поисковик». Но это не значит, что Beagle [4] нельзя использовать в других Linux-дистрибутивах, на официальном сайте проекта имеются рекомендации по установке движка под Debian, Mandrake (известный теперь как Mandriva), Gentoo, Ubuntu и другие. Замечу, что если вы пользуетесь SUSE Linux, то без особого труда установите движок. А пользователям других дистрибутивов Linux придется устанавливать большое количество пакетов. Итак, скачав данную поисковую машину, откомпилируем ее стандартными командами «configure, make && make install» и приступим к ее конфигурированию. Настройка Beagle возможна как в графическом режиме, так и в консоли. Запустим программу конфигурирования движка beagle-settings, перед нами появится графический интерфейс (см. рис. 5) настройки: «горячей» клавиши для вызова поиска, папок для индексации и возможности назначения исключений, думаю большинство пользователей легко справляется с этой задачей. Настройка из консоли осуществляется утилитой beagle-config, немного сложнее, чем в графическом режиме, но опытные пользователи ОС Linux так же быстро разберутся со всеми параметрами. Рассмотрим пару примеров: beagle-config indexing AddRoot /mnt/disk2 где indexing – необходимый конфигурационный файл, AddRoot – секция и последний параметр – путь к индексируемой папке. beagle-config indexing AddExclude pattern file.xxx В примере мы добавляем одно исключение – на запрет индексации файлов «file.xxx». Некоторые примеры и полный синтаксис команд вы можете найти в сопроводительной документации движка и быстрой справке по отдельным утилитам.
Рисунок 5. Графический интерфейс настройки Beagle Пользователи, предпочитающие все настраивать вручную и не доверяющие всевозможным мастерам настройки, могут самостоятельно отредактировать конфигурационные файлы Beagle (их всего пять: indexing.xml, daemon.xml, searching.xml, networking.xml и webservices.xml), расположенные в папке configure движка. Не стану приводить примеры всех этих файлов, остановлюсь только на indexing.xml для ознакомления синтаксиса и одновременно проверим, занесла ли утилита beagle-config два наших параметра: <?xml version="1.0" encoding="utf-8"?> <IndexingConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Roots> <Root>/mnt/disk2</Root> </Roots> <IndexHomeDir>true</IndexHomeDir> <Excludes> <ExcludeItem Type="Path" Value="/mnt/disk3/DENY" /> <ExcludeItem Type="Pattern" Value="file.xxx" /> </Excludes> </IndexingConfig> В секции Root указывают индексируемые директории, тогда как Excludes содержит правила запретов индексирования (путь к директории или название файла). Разобраться в синтаксисе не так и сложно. Минимальное конфигурирование выполнено, для начала индексации просто запустим демона beagled. В папке log можно найти результаты индексирования, файлы формируются в таком виде: 2006-07-02-13-02-04-IndexHelper, а не единым log-файлом. После окончания индексации приступаем к поиску информации. Возможен поиск по базе как в графическом режиме, утилитой beagle-search (см. рис. 6), так и в консоли, программой beagle-query.
Рисунок 6. Графический интерфейс утилиты beagle-search В комплект поставки Beagle входит достаточно много вспомогательных утилит, например, beagle-index-info выводит информацию о количестве и типе проиндексированных документов. С помощью Beagle-index-url можно задать веб-ресурс для индексации. Beagle-info выводит исчерпывающую информацию о демоне beagle, собранной информации, установленных фильтрах и так далее. Должен заметить, что возможность конфигурирования и поиска из консоли позволяет устанавливать данный движок на удаленный шелл и легко использовать его в работе, при этом не задействуя сервисов требующих права суперпользователя (root). Время индексации примерно 2000 тысяч документов равна 23 минутам. Огорчило только время поиска по базе, простые запросы beagle обрабатывает 3-4 секунды, но не стоит забывать, что движок позиционируется как пользовательский. Итоги Я не претендую на то, что все движки были идеально сконфигурированы, в каждом конкретном случае можно добиться более впечатляющих результатов (можно «выиграть» в скорости поиска по СУБД простой оптимизацией базы данных в MySQL). К сожалению, охватить все стороны выбранных движков в одной статье просто невозможно. Документация ко всем корпоративным поисковым машинам составляет сотни страниц, простое чтение этой информации займет несколько дней. Но все же можно сделать некоторые выводы из полученных данных (см. таблицу). Сравнительные характеристики поисковых движков (* напомню, что все файлы были переведены из форматов xls, doc, rtf в формат text/plain)
Yandex.Server – из рассмотренных движков явный фаворит, время индексации и поиска минимальное. Отличная документация, поддержка, кроссплатформенность, мощный функционал – большие плюсы. Движок можно рекомендовать для крупных и хорошо финансируемых проектов. Компромисс, конечно, есть всегда, существует несколько редакций движка, но полная версия движка все же дорога, по данному поводу на форуме Yandex уже давно идут дебаты. DataparkSearch – полностью свободный проект, давно уже переставший быть клоном MnogoSearch. Основное отличие и плюс – это mod_dpsearch для веб-сервера Apache, за счет него движок очень быстро обрабатывает при поиске большие объемы данных. MnogoSearch– полукоммерческий проект с богатым функционалом, есть выбор версий движков и платформ. Движок давно уже успел себя зарекомендовать. Индексация документов происходит достаточно быстро, но время поиска по базе при больших объемах данных и сложных запросах бывает очень большое. Не хватает движку документации на русском языке, так как неискушенному пользователю разбираться в достаточно сложных поисковых машинах все же проще на родном языке. Beagle – простой пользовательский движок, предназначенный для облегчения поиска информации на локальном компьютере. Движок хорошо справляется с задачами, на которые он ориентирован. Немного огорчает время поиска по базе и некоторые проблемы при индексации документов MS Word (doc), о чем нас предупреждают разработчики. Примечательно, что все три корпоративные поисковые машины Yandex, DataparkSearch, MnogoSearch– российские проекты, причем выбор обзора был сделан не целенаправленно по данному критерию, а из соображений «какие хорошие проекты рекомендуют на просторах сети Интернет?». Остается только порадоваться за наших разработчиков, движки развиваются и поддерживаются. Приложение О движках, не вошедших в обзор... ...Но весьма интересных. В статье [8] я упоминал некоторые поисковые машины, такие как Wordindex [5], ASPseek [6], htdig [7] и другие. Из перечисленных, но не вошедших в сегодняшний обзор, стоит выделить ASPseek и hidig. Почему именно они? ASPseek уже успел устареть, последняя официальная версия движка вышла в 2002 году, но на форуме сайта можно встретить энтузиастов, которые помогают с поддержкой движка. Официальный релиз версии 1.2.10 достаточно проблематично поставить на новые дистрибутивы Linux и *BSD-систем, одно из затруднений – ошибки при компиляции в gcc3 (и особенно 4 версии), но обратившись на форум можно найти ссылки на измененные версии движка, которые вполне работоспособны. Как мы видим, ASPseek еще используется и дорабатывается, несмотря на отсутствие официальной поддержки. Хотелось бы напомнить, что стоит «доверять, но проверять» неофициальные снапшоты любого программного обеспечения. Htdig – движок поисковой машины остается все еще популярным (для обработки небольших объемов данных), несмотря на то, что последний официальный релиз был в 2004 году. Хорошим примером работы движка, можно считать то, что он помогает обеспечивать работу достаточно популярного и многим известного портала – www.opennet.ru. Как можно увидеть на странице-путеводителе (http://www.opennet.ru/guide.shtml), htdig хорошо справляется с объемом данных в 1,5 Гб, ну а о качестве работы движка можно судить там же.
|
Иван Максимов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
