Ещё один велосипед, или пишем свой поисковый движок. Для тех, кто в танке

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

Обычный поиск

Самым тривиальным решением было разбивать статьи на слова, разбивать запрос на слова и искать совпадения.
Плюсы:

• Высокая скорость. Можно было для этого использовать сразу mysql таблицу со словами
• Простота. Скрипт для такого алгоритма занимал бы всего несколько десятков строк.

• низкая точность, отсутствие возможности исправления ошибок

Нечёткий поиск

Итак, было решено сделать все как у «взрослых». Т.е. авто исправление ошибок и поиск не только по точному соответствию слов но и по формам слова. Т.к. хотелось большей производительности, поиск писался не на php, а на Яве постоянно висящей в памяти и хранящей индекс статей.

Стеммер

Для начала надо было определиться, как обобщать разные формы одного слова. Будем считать, что одинаковые слова это слова с одинаковым корнем. Но вот извлечение корня это не лёгкая задача. Решая эту проблему, я быстро нагуглил так называемый «стеммер Поттера» (Сайт автора). Стеммер Поттера выделяет корень слова, который, однако, не всегда совпадает с лексическим. К тому же он написан для разных языков, в том числе и для русского. Однако пример русского написан на пхп и, переписав его один в один на яву, я получил очень слабую производительность. Проблема решилась использованием регулярных выражений. Из-за нелюбви к регулярным выражениям я взял готовый пример www.algorithmist.ru/2010/12/porter-stemmer-russian.html (Спасибо автору).
В результате производительность получилась на уровне 1 млн. слов в секунду.

Исправление опечаток

Часто бывает так, что пользователь ошибается при вводе запроса. Поэтому нам необходим алгоритм определения похожести слов. Для этого существует много методов, но самым быстрым из них является метод 3-грамм. Суть его такова: Разбиваем слово на тройки последовательно идущих букв. Со вторым поступаем аналогично. Пример:
Конституция => КОН ОНС НСТ СТИ ТИТ ИТУ ТУЦ УЦИ ЦИЯ
Консттуция=> КОН ОНС НСТ СТТ ТТУ ТУЦ УЦИ ЦИЯ

Потом сравниваем эти тройки и чем больше одинаковых троек мы получили, тем выше похожесть слов.
Итого у нас совпадает 6 троек из 8 или 75%.
Этот метод хорош, когда в запросе пропущена или добавлена лишняя буква. Но вот когда человек заменяет одну букву на другую, у нас сразу попадает 3 тройки. Однако обычно лишняя или пропущенная буква это опечатка. А вот заменённая - это орфографическая ошибка. Какие же это ошибки:

• Замена а – о и о-а: мАлоко, пАбеда, рОдон
• Е-и, и-е. бИда, пЕрог
• неправильно употребление мягкого и твёрдого знака.

Поэтому приведём все к одному виду:

Private String replace(String word) { word=word.replace("а","о"); word=word.replace("е","и"); word=word.replace("б","п"); word=word.replace("д","т"); word=word.replace("г","к"); word=word.replace("щ","ш"); word=word.replace("ъ","ь"); word=word.replace("ж","ш"); return word; }

Таким образом, нам надо перебрать все имеющиеся слова и найти самое похожее. При 1 млн. слов это около 1 с, что не приемлемо. Оптимизируем. Для начала, положим, что нас интересуют слова, отличающиеся в длине максимум на 2 буквы. Потом заметим, что из трёх букв существует всего 30 000 вариаций.(33*33*33).Поэтому прохешируем ещё на этапе индексации итого алгоритм будет такой:

String gramms=get3gram(word); int i=0; for (String gram:gramms) { if (this.tgram_abc[i]==null) this.tgram_abc[i]=new ArrayList(); this.tgram_abc[i].add(id); i++; }

Далее сделаем аналогичное для слова с «приведёнными» буквами, потом заменим нн на н и добавим в третий массив, и напоследок удалим все мягкие знаки.
Теперь можно искать похожие слова. Разбиваем слова на граммы, находим хеш кажой тройки и получаем списко слов в которых одни есть на похожих позициях.

HashMap GramBalls=new HashMap(); int StartG=(i-2>=0)?i-2:0; int EndG=(i+2); for (int l=len-2;l<=len+2;l++) for (int j=StartG;j<=EndG;j++) if (this.tgram_abc[l][j]!=null) for (int id:this.tgram_abc[l][j]) if (!GramBalls.containsKey(id)) GramBalls.put(id, (1-(double)Math.abs(len-l)/3) /(word.length()-2));

В последней строке выведенная методом «тыка» формула, которая означает, что триграмм в конце будет приносить слову 0.7 очков/кол-во триграмма. А первая будет приносить 1 очко/кол-во грамм.
Дальше аналогично ищем для «приведённого» слова из запроса и для слова с заменёнными нн и мягкими знаками. Правда там вместо 1 будет 0.7 и 0.3 соответственно.
После сортируем слова по очкам и выбираем слово с наибольшим кол-вом очков. Однако если у «чемпиона» меньше 0.1 очка то возвращаем null. Это нужно чтобы не учитывать совсем непохожие слова. Т.к. приведённый выше алгоритм определяет что «космонавт» «астма» имеют похожесть 0.05.

Механизм индексации

У «взрослых» индексацией занимаются специальные программы пауки, которые периодически обходят сайты, индексируют содержимое, ищут ссылки на странице и идут по ним дальше. У нас же все просто. При добавлении страницы php скрипт посылает запрос нашем поисковику индексировать страницу. Далее страница очищается от тегов. После разбивается на слова. После этого определяется язык слова. Мы проходим по слову и для каждой буквы добавляем балл языкам, которые поддерживают это символ. Для русского это а-я и дефис «-».Для английского это a-z, дефис и апостроф(‘). Все символы и цифры вынесены в отдельный «символьный язык».
Для хранения и быстрого поиска у нас существует массив списка слов.

ArrayList WordIndex[язык текста][служебный индекс текста][язык слова]

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

Механизм поиска и ранжирования

Это самый главный механизм любой поисковой системы. Именно от того насколько правильно он создаёт выдачу зависит мнение пользователей.
Когда пользователь нажимает на кнопку поиск php скрипт пересылает запрос поисковику. Тот его разбивает на слова. Только тут есть одно отличие от индексации. Если при добавленной статьи при встрече незнакомого слова мы добавляем его в список слов, то при встрече в запросе незнакомого слова мы ищем наиболее похожее используя метод 3 грамм.
После разбиения для каждого слова мы получаем список из пар id текста – вхождение слова.
Определим, насколько статья подходит запросу:

1. Посчитаем, сколько всего слов из запросов есть в статье.(a)
2. Посчитаем, сколько всего корней из запросов есть в статье.(b)
3. Посчитаем сколько существует словосочетаний слов аналогичных словосочетаниям в запросе(c)
4. Посчитаем, сколько существует словосочетаний корней аналогичных словосочетаниям в запросе(d)
5. Определим сколько слов из запроса встречаются в статье(e)
6. Определим сколько корней из запроса(f)

После чего каждой статье добавим баллы по след формуле:

Math.log(2*a+1)+ Math.log(2+1)+2+Math.log(c*5+1))+ Math.log(d*3+1)))*(f+2*e));

Формула создана по след принципам:

1. Слова приоритетнее корней
2. Словосочетания приоритетнее обычных слов
3. Чем более полно статья описывает поисковый запрос, тем выше её рейтинг. Причём полнота является ключевым

Далее пройдёмся по заголовкам, только там будем умножать баллы на 10, т.к. заголовок отражает суть статьи.
Сортируем и выводим.
Приведённый алгоритм обрабатывает 100 запросов в секунду при индексе в 1000 статей на VPS с процессором 1Ггц.
P.S. Эта статья лишь служит лишь для ознакомления с некоторыми алгоритмами и идеями нечёткого поиска.

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

Возможности поискового движка 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, поместив в него нужные параметры для индексации данных.

Вконтакте

Технические проблемы создания поискового движка сайта