История одной разработки, или Как мы делали siteMETA

 АНДРЕЙ КОВАЛЕНКО 

История одной разработки,

или Как мы делали siteMETA

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

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

Откуда растут уши?

Рано или поздно в жизни интернет-ресурса наступает момент, когда без поиска по растущему количеству документов уже не обойтись. Фактически, сайту, состоящему из сотни страниц, уже необходимы поисковые функции. Для иллюстрации данного утверждения достаточно обратиться к большим поисковым системам и дать запрос: «сделать поиск по сайту». Ответы будут содержать множество примеров. Это и просьбы пользователей, и «декларации намерений» владельцев серверов наконец-то доделать своё детище, и радостные новости о том, что «поиск по сайту заработал»... Но есть и сообщения о трудностях, с которыми приходится сталкиваться при выборе, установке и последующей эксплуатации поисковой системы. Давайте проанализируем, кому же нужен этот самый поиск по сайту?

Как пишет известный специалист по «Web-usability» Якоб Нильсен: «Пользователи обожают поиск по двум причинам». Во-первых, поиск позволяет посетителям управлять своей собственной судьбой и делает их независимыми от попыток веб-сайта направить их по определенной тропе, протоптанной веб-дизайнером, и результаты тестов регулярно подтверждают этот вывод. Типичное замечание пользователя: «Я не хочу идти по сайту так, как они задумали. Я просто хочу найти нужную мне информацию». Вот почему большинство посетителей сайтов идут к функции «Поиск» сразу с главной страницы.

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

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

Статика или динамика?

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

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

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

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

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

COM и UNIX? А почему бы и нет!

Для решения поставленной задачи была выбрана парадигма COM. Конечно, не сама Component Object Model (апологеты UNIX, мы солидарны с вами – не плюйтесь, читайте дальше) – ведь наша система ориентирована не только и не столько на Microsoft Windows, сколько на Linux и FreeBSD, а некоторое подмножество этой парадигмы, включающее декларацию классов с абстрактными методами и подсчет ссылок для автоматического освобождения памяти. Тем более что именно эта парадигма используется в наших разработках для подключения различных расширений – модулей языковой поддержки, фильтров специализированных форматов файлов.

Прежде всего предстояло по лицензионным соображениям отвязать систему от единственного применяемого ранее менеджера БД – BerkeleyDB, использовать который в коммерческих разработках не представляется возможным для небольшой украинской компании. Поэтому мы реализовали свой собственный альтернативный менеджер БД с использованием libgist, которая распространяется абсолютно бесплатно. По ходу разработки, правда, сложилось впечатление, что дешевле и быстрее было бы разработать нечто подобное «с нуля», так как ошибки в libgist всплывали достаточно долго, однако компонент, поддерживающий b-tree, был изготовлен и упакован в разработанный обобщенный интерфейс. Скажем сразу, что все программные интерфейсы модулей расширения, в том числе и фильтров форматов, доступны по запросу любому зарегистрированному пользователю наших продуктов, в том числе и распространяемых бесплатно.

Индекс здесь, индекс там...

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

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

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

... Что хранится под замком?

Испробовав много вариантов, мы остановились на хранении записей динамического индекса в БД типа b-tree, причем ключом каждой записи является сочетание собственно поискового ключа – преобразованной внутренними алгоритмами строки – с идентификатором документа, в котором этот ключ встретился, а данными – дополнительная информация, описывающая вхождения поискового ключа в тело документа. Такая реализация хоть и имеет элемент многократного дублирования данных (идентификаторов документов), однако позволяет удалить информацию об одном-единственном документе без реорганизации всего индекса. Добавление же новых записей происходит и вовсе прозрачно, никак не влияя на параллельно ведущийся поиск по индексу.

Будьте проще …

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

И вот что получилось...

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

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

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

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

Настройки

Настройка поискового сервиса через административную консоль не является единственным способом управления поиском. Более тонкая настройка может осуществляться при помощи конфигурационных файлов. Так, для поискового сервера можно настраивать порты, пути к лог-файлу, списку стартовых адресов и масок, время ожидания при индексации документов, время между циклами переиндексации, поддержку wildcard-символов и т. п. Для CGI-скрипта, формирующего поисковый запрос и страницу выдачи результатов поиска, можно задать путь к файлу-шаблону страницы результатов и сообщений об ошибках, количество документов, отображаемых на ответных страницах, и т. д.

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

Не web-ом единым...

Сейчас довольно распространенной практикой становится размещение на страницах сервера документов в самых различных электронных форматах. Отчеты, прайс-листы, сводки, договора, пресс-релизы – вот далеко не полный перечень того, что все чаще попадает на сайт без предварительной подготовки и верстки в HTML. Почему бы поисковой системе не обрабатывать и эти данные? Фильтры форматов могут быть легко дополнены в siteMETA, что позволяет работать не только с html-документами, но и с документами наиболее популярных офисных пакетов, таких как Microsoft Word, Microsoft Excel и некоторых других. В настоящее время доступны фильтры форматов .doc, .xls, .rtf и .xml. Используя эти фильтры, например, можно облегчить жизнь коллегам в своем офисе, организовав простую корпоративную поисковую систему по документам на внутреннем веб-сайте.

Ты скажи, ты скажи, че те надо…

В проекте был учтен опыт обработки протоколов деятельности большой поисковой машины. Все сообщения, возникающие в процессе работы siteMETA, пишутся в специальный log-файл. Анализ этого файла дает возможность оценить поступающие запросы, их частотность, просмотреть список и размер обработанных документов, статистику индекса, время индексирования и т. п., а также учесть сообщения об ошибках. Данные, получаемые при обработке статистики пользования поиском по сайту, дают пищу для размышлений и улучшений предоставляемых услуг. Так, наиболее частые обращения пользователей к поисковой системе позволяют понять, что именно ждут посетители от сайта. Зная это, можно оптимизировать структуру ресурса, пополняя его или меняя архитектуру: если какой-либо запрос встречается весьма часто, имеет смысл выделить соответствующие страницы в специальный раздел или же поместить ссылку на существующий на первую страницу. Например, после установки поисковой системы на сайт одного из банков анализ поисковых запросов показал, что пользователей очень интересует «облигация». Соответствующий раздел, подробно освещающий эту тему, на сайте присутствовал, однако находился на четвертом уровне вложенности. После размещения ссылки на этот раздел на главной странице продажи облигаций возросли!

Таки покажите мне этот таки поиск!

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

Удачных примеров использования описанного сервиса несколько, однако особо отметить хочется сайт Национального Банка Украины (www.bank.gov.ua). Сервис здесь обеспечивает поиск по английской и украинской версиям сайта, обрабатывает помимо документов формата html также электронные таблицы Microsoft Excel (.xls) и использует полные (словарные и бессловарные) модули лингвистической поддержки украинского и английского языков. Обрабатываемый объем данных – около 50 Мб в пересчете на плоский текст.

.

Также заслуживает внимания реализация поиска по сайту еженедельника «Зеркало недели» (http://www.zerkalo-nedeli.com). Здесь, наряду с украинским и английским языками, поддерживается русская версия ресурса. Обеспечивается поиск по разделам сайта, тексту и названию статей, автору, дате; поддерживается поиск по архиву материалов и текущей версии. Объем обрабатываемой информации – около 800 Мб.

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

Самую свежую версию программы siteMETA всегда можно бесплатно загрузить с сайта http://sitemeta.com.