Индексатор поисковой системы

Что такое индексатор
Движки индексаторов
Каталогизатор
Области поиска и индексы
Режимы индексирования
Основные команды управления индексатором
Создание индекса (новой базы данных)
Получение информации о состоянии индекса
Получение списка индексов
Статистика индексатора
Печать списка проиндексированных файлов
Удаление индекса
Удаление всех индексов
Задание имени используемого индекса
Включение и отключение индексатора
Индексация файлов
Переиндексация (обновление)

Использование индекса при поиске
Техническая реализация индексатора
Размещение индексной базы
Резервное копирование
Команды управления для параллельного сервера
Общий доступ при распределенном поиске
Когда индексирование неэффективно

Примеры использования индексатора

Что такое индексатор

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

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

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

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

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

Индексная база данных хранит для каждого документа не только его содержимое, то также некоторые другие параметры, в частности:

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

Движки индексаторов

Для использования доступны несколько движков индексаторов:

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

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

3. mysql - серверный вариант с хранением индексной базы в СУБД MySQL. Позволяет иметь одну индексную базу для множества пользователей, например для сетевого хранилища. При относительно невысокой скорости индексирования обеспечивает максимально возможную устойчивость к аппаратным и программным сбоям, так как даже при аварийном завершении обработки индексируемого документа записи в базе данных благодаря механизму транзакций откатываются до предыдущего корректного состояния. Индекс остается доступным для поиска даже во время индексирования.

4. locate - быстрый файловый поиск (по именам файлов), допускающий многопоточное индексирование (один поток для одного физического привода) и поиск. Относительная отказоустойчивость реализована через создание рабочей копии индексной базы при обновлении индекса.

Выбор движка индексатора выполняется пользователем, в случае поисковой утилиты faind явно в команде -index create_domain, а в случае системы Интегра - неявно. Нет никаких ограничений на создание разных типов индексов одной утилитой, так как поисковый движок автоматически настраивается на нужный тип при монтировании индексной базы.

Чтобы увидеть список поддерживаемых движков индексаторов, используйте команду -index info, не указывая имени индекса.

Каталогизатор

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

В зависимости от версии, список индексов хранится либо в виде простого файла на локальном диске (для Lite), либо во встроенной СУБД SQLite (для Pro), либо в таблицах на сервере MySQL (для Premium). Для пользователя используемое хранилище полностью прозрачно, почти все команды поддерживаются любой реализацией. Исключение составляют операции резервного копирования индексов, которые не поддерживаются серверным вариантом, вместо это следует использовать штатные средства СУБД.

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

 Области поиска и индексы

Область поиска - произвольно сформированное посредством команд -dir, -file, -uri множество файлов, в которых ведется поиск. Файлы, объединяемые в рамках области, физически не перемещаются. Один и тот же файл может быть отнесен к нескольким областям, в этом случае он индексируется независимо для каждой области.

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

Для повышения гибкости и эффективности допускается использование 2 видов индексов:

1. статические

2. динамические

Для статических индексов характерно то, что проиндексированные в данной области документы (файлы) уже не должны меняться. Пример такой области - компакт-диски. Создаваемый поисковым движком индекс для статической области наиболее компактен, а применяемый алгоритм поиска - самый быстрый. Чтобы переиндексировать документы в статической области, следует полностью очистить соответствующий индекс и запустить переиндексацию (-index domain="xxx" -index refresh). При поиске в статической области нельзя указывать команды -dir, -file, -url, так как фактически сканирования проиндексированных дисковых файлов не происходит. Для отсечения ненужных документов можно пользоваться всеми файловыми фильтрами (-iname и др.).

В динамических индексах можно эффективно собирать документы, которые время от времени изменяются (не слишком часто). Для этих областей создаются достаточно большие индексы, но скорость поиска сравнима с данным показателем для статических индексов. При обнаружении изменения в проиндексированных файлах необходимо выполнить переиндексацию (командой -index refresh) без очистки индекса. Индексатор сам просмотрит область поиска и обработает только изменившиеся документы. Если перед командой -index refresh указать команду -file со списком файлов, то индексатор проверит только эти файлы. Этот прием используется в настольном поисковике при обнаружении изменений в документах пользователя.

При поиске можно пользоваться всеми файловыми фильтрами (-iname, -modif, -size и др.).

Индексируя компакт-диски и DVD как раздельные индексы, можно получить в итоге достаточно большой кумулятивный объем индексной базы данных, работоспособный на достаточно слабых персональных компьютерах (далее пример множества индексов в поисковой системе Integra):

главное окно каталогизатора поисковой системы


Режимы индексирования

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

1. Самый компактный - индексирование с нормализацией словоформ по словарю (см. команды -index wordforms и -index dynforms); ускоряет поиск по отдельным словам, но при поиске по фразам возникает некоторая потеря эффективности, так как в индексе данного вида не сохраняется информация о расположении слов. Из-за этого при поиске фраз поисковый движок будет работать с файлами, в которых ключевые слова фразы не обязательно близки друг к другу. Лишние документы будут корректно отсеяны командой -index touchfiles, но время на обработку этих лишних файлов будет потрачено.

2. Простой - похож на вариант 1, но нормализация слов не выполняется, поэтому индексная база имеет несколько больший размер (см. бенчмарки).

3. С ускорением поиска по фразам (см. команду -index proximity), с нормализацией и без по словарю. В этом случае в индексной базе сохраняется некоторая информация о расположении слов в документах, поэтому поиск по фразе выполняется намного эффективнее, чем для варианта 1 или 2. Однако размер индексной базы получается на порядок больше, и существенно медленнее выполняется индексирование.

Опции, переключающие режимы, описаны ниже.

Кроме этих основных режимов, можно сохранять в индексе дополнительную информацию:

Основные команды управления индексатором

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

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

Создание индекса (новой базы данных)

Индексирование документов состоит из двух шагов: объявление индекса и его заполнение. При объявлении индекса командой -index create_domain вносится новая запись в базу каталогизатора.

При объявлении индекса в общем случае указываются следующие параметры:

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

-index create_domain условное_имя_индекса

Для работы с таким индексом по умолчанию назначается движок индексатора faind, преимущества и недостатки которого обсуждались ранее. В серверном варианте по умолчанию всегда назначается движок mysql.

Если область после индексации может изменяться, то есть индекс будет динамическим, тогда при объявлении следует указывать специальный флаг dynamic:

-index create_domain условное_имя_индекса clucene dynamic

В данном случае индекс будет обслуживаться движком clucene. В серверном варианте можно указать и другой движок с SQL back-end:

-index create_domain условное_имя_индекса mysql dynamic

Настольная поисковая система Интегра умеет отслеживать изменения в проиндексированных каталогах и автоматически обновлять соответствующие индексы. Для включения такой возможности используется параметр monitor_changes:

-index create_domain условное_имя_индекса clucene dynamic monitor_changes

Если необходимо, чтобы индекс обновлялся при простое системы, вместо monitor_changes используется параметр scheduled_refresh. Поисковая система Интегра сама указывает этот флаг только для индекса 'Мои файлы', так как мониторинг всех изменений файлов слишком дорог, а полное обновление этого индекса обычно занимает несколько минут и вполне подходит для запуска при простое.

Еще один параметр shared включает общий доступ к индексу из сети в режиме распределенного поиска:

-index create_domain условное_имя_индекса shared

Индексы, отмеченные признаком shared, участвуют в обработке поисковых запросов, полученных от внешних движков (см. команду -engine).

Параметр word_wheeled_search в команде create указывает, что для индекса будет доступен быстрый поиск по мере ввода текста запроса в Интегре. Обычно такой режим включается только для индекса 'Мой компьютер' для локальных файлов, так как он требует достаточно высокой скорости доступа к файлам.

После этого можно заполнять созданную индексную базу (подробнее команды индексирования описаны ниже):

-index domain="имя_индекса" -dir каталог_для_индексирования

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

При создании индекса можно явно задать папку, где будут размещаться файлы базы данных, с помощью команды -index dir:

-index dir XXX -index create_domain имя_индекса ...

API поискового движка позволяет работать с индексом, зная размещение папки с его базой, с помощью процедуры sol_AppendPortableIndex.

Импорт описаний индексов

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

-index import mysql host db login password

Для указания на конкретный сервер используются параметры host (сетевой адрес сервера), db (имя базы), login и password.

Получение информации о состоянии индекса

Посмотреть текущее состояние индексной базы можно опцией:

-index domain=имя_индекса -index info

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


Команда

-index domain=имя_индекса -index detailed имя_файла_выдачи

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

 

Получение списка индексов

Используется команда

-index domains

Данная команда применима только в консольном поисковике faind, так как она выводит список индексов непосредственно на текстовую консоль. Для получения совокупной статистики по всем индексам (занятое дисковое пространство и др.) можно использовать команду -index totals.

 

Статистика индексатора

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

-index totals

Для получения сведений об одном индексе следует использовать команду -index info.

 

Печать списка проиндексированных файлов

Индексатор может распечатать список файлов в загруженном индексе в нескольких форматах:

-index domain=имя_индекса -index files:HTML файл

Вместо HTML (тогда список печатается в формате html в кодировке utf-8) после токена files: можно указать CSV (формат с разделением полей символом ';') или TXT (простой текстовый файл в кодировке utf-8).

 

Переименование индекса

Изменить имя индекса можно с помощью команды

-index domain=старое_имя -index rename новое_имя

 

Установка комментария для индекса

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

-index domain=старое_имя -index set_comment строка_комментария

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

 

Удаление индекса

Чтобы полностью удалить индекс для именованной области и объявления самого индекса в корневой таблице, используется команда:

-index delete_domain="условное_имя_области"

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

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

Для MySQL-based индексатора удаление поискового индекса вызывает также удаление некоторых таблиц.

Аналогичную функциональность представляет команда -index purge, которая приводит индекс в "чистое" состояние, как после выполнения команды -index create_domain, но не удаляет объявление индекса.

 

Удаление всех индексов

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

-index delete_all

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

 

Задание имени используемого индекса

Для выполнения операции с конкретным, ранее созданным индексом, используется команда:

-index domain="имя_индекса"

После такой команды все операции (в пределах одного запроса) будут выполняться для индексной базы данных указанного индекса.

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

Команда domain допускает задание списка имен индексов, в этом случае соответствующая операция будет выполнена последовательно для всех перечисленных индексов:

-index domain="cd1;cd2;cd3"

Именно этот формат команды применяется в каталогизаторе поисковой системы Integra для поиска по группе CD/DVD.

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

 

Очистка индексной базы

Для очистки индекса используйте команду:

-index purge

Полностью командная строка будет иметь вид:

-index domain="условное_имя_области" -index purge

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

Если же нужно полностью удалить область, то используется команда -index delete_domain.

 

Включение и отключение индексатора

Отключение индекса для запроса выполняется опцией:

-index off

А включение (если по умолчанию индексатор отключен - см. описание ini-файла) опцией:

-index on

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

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

 

Индексация файлов

Для индексации любой области поиска команда будет такой:

faind -index domain="имя_индекса" область_поиска

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

Например, для индексирования CD можно использовать команду (см. описание -cdrom):

faind -index domain=имя_индекса -cdrom

В некоторых случаях в индексе достаточно сохранять только имена файлов. К примеру, индексирование FTP-серверов может потребовать слишком больших затрат для анализа содержимого хранящихся документов. С помощью команд -ignore_contents и -store_all_files=true можно ограничить индексатор запоминанием только имен файлов:

faind -index domain="имя_индекса" -ignore_contents -store_all_files -mycomp

В данном примере в индексе будут сохранены имена всех файлов на всех жестких дисках компьютера (см. команду -mycomp).

 

При индексировании автоматически из рассмотрения исключаются так называемые стоп-слова, то есть предлоги, союзы и прочие семантически не нагруженные части речи, которые встречаются очень часто. Стоп-слова берутся из текстового файла (его имя задается в ini-файле). Если использование стоп-слов для индексирования по каким-либо причинам нежелательно, то следует использовать опцию

-index stopwords=off

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

-index wordforms

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

-index dynforms

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

Поэтому для получения максимально компактного индекса следует использовать команду:

-index dynforms область_поиска

или

-index wordforms область_поиска

если время формирования индекса играет роль.

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

-index proximity

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

Чтобы накапливать и сохранять для каждого проиндексированного документа также таблицу частот ключевых слов, используется опция:

-index frequency

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

-index calc_freq_rank

Чтобы не только ранжировать документы, но и отсортировать их в результатах по убыванию (или возрастанию), используется команда -sort freq_rank.

Для упрощения поиска на сменных носителях можно сохранять текстовое содержимое проиндексированных документов в базе данных индексатора:

-index storecontents

 

Переиндексация (обновление)

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

-index domain="xxx" -index reindex=on

Аналогично работает команда

-index domain="xxx" -index refresh

Для статического индекса поисковый движок автоматически очищает индексную базу, поэтому нет необходимости в предварительном использовании команды -index purge.

Добавление документов в индекс

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

-index add

При этом полная строка выглядит примерно так:

-index domain=имя_индекса -dir добавляемая_папка -index add

 

Использование индекса при поиске

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

Возможен второй режим работы индексатора - когда область поиска вообще не определена, а задан только паттерн запроса (и возможно другие опции управления индексатором) и имя зоны. Например, если ранее была создана и проиндексирована зона с именем "Мошков-1", можно выполнить такую команду:

-index domain="Мошков-1" -sample "кошка"

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

Чтобы заставить индексатор найти точные контексты фиксации, используется опция -index touchfiles:

-index domain="Мошков-1" -index touchfiles -sample "кошка"

Особо отметим, что алгоритм индексатора допускает поиск по индексной базе по регулярным выражениям (если используется комбинация опций -rx -sample) и нечеткий поиск (так называемое частичное сопоставление - partial matching, и некоторые более сложные технологии). Никаких специальных опций для индексатора при этом вводить не нужно - переключение внутренних алгоритмов происходит автоматически.

 

Техническая реализация индексатора

Начиная с версии 3.0 поисковый движок путем настройки при компиляции позволяет использовать следующие подсистемы хранения индексной базы данных:

1. Встроенный простой движок СУБД с хранением как описаний отдельных индексов, так и собственно индексных БД в файлах ОС.

2. Движок реляционной SQL СУБД SQLite для хранения описания индексов, файлы ОС для хранения индексных БД.

Вы можете увидеть описание хранилища индексатора с помощью команды faind -help.

Для варианта 1 характерно следующее.

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

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

Реализация индексатора без установки какой-либо СУБД общего назначения имеет как свои плюсы (к примеру, возможность работы поискового движка без инсталляции, реализация хранения некоторых данных на диске со сжатием), так и минусы. Вообще говоря, основными чертами нормальных СУБД, отличающими их от простых контейнеров информации, являются 1) транзакции, 2) параллельная обработка команд на модификацию хранимой информации.

Транзакция - это набор действий, который либо целиком выполняется успешно, либо целиком проваливается (см. статью в Википедии). Типичный пример - электронный перевод денег, когда операция по переводу некоторой суммы не может завершится на половину. Развитый механизм транзакций - это очень важная особенность, позволяющая создавать устойчивые к сбоям базы данных. С точки зрения любой поисковой машины транзакции необходимы для создания устойчивого к случайным сбоям индексатора. К примеру, если в ходе создания индекса и записи создаваемых данных в дисковый файл возникает сбой питания, то состояние индексной базы данных после перезагрузки операционной системы будет неопределенным, так как часть информации была записана на диск, а часть (произвольная) - осталась незафиксированной. Понятно, что использование такой поврежденной базы данных индексатора в дальнейшем приведет в лучшем случае к некорректным результатам поиска. Ситуацию не спасет даже возможности некоторых файловых систем по выполнению транзакций (NTFS для Windows, ReiserFS для Linux), так как транзакции файловой системы обычно происходят на ином уровне представления данных.

Параллельное выполнение запросов к базе данных - это вторая особенность промышленных СУБД. Такая возможность необходима для реализации серверного варианта поисковой машины, которая обслуживает одновременно несколько запросов - например, в случае локального поиска на сайте. В этом случае поисковая машина выполняется в виде системной службы (сервиса), которая получает запросы по сетевому протоколу. Реализация многопользовательского режима работы вместе с транзакционными механизмами - сложнейшая задача, и реализация ее своими силами вряд ли разумна. В случае необходимости такого режима работы безусловно нужно использовать back-end СУБД общего назначения.

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

Размещение индексной базы

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

Следует заметить, что в некоторых режимах работы (например, при переиндексации измененных документов) в файлах данных индекса появляются неиспользуемые участки. Поэтому при частом изменении проиндексированных документов растет бесполезно занимаемого дискового пространства. Чтобы почистить мусор в индексной базе, необходимо сначала очистить ее (команда -index domain=xxx -index purge), а затем заново выполнить индексацию документов.

Резервное копирование

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

-index backup имя_каталога

Сохраняет в указанном каталоге файлы для корневой таблицы БД каталогизатора. В этой таблице хранится список индексов, поэтому его утеря приводит к невозможности работать со всеми созданными индексами. Чтобы сохранить файлы отдельного выбранного индекса, используется похожая команда:

-index domain=имя_индекса -index backup имя_каталога

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

-index backup c:\backups
-index domain=index1 -index backup c:\backups
-index domain=index2 -index backup c:\backups
-index domain=index3 -index backup c:\backups

Для восстановления индексной БД из резервных копий применяются симметричные команды:

-index restore имя_каталога

и

-index domain=имя_индекса -index restore имя_каталога

Таким образом, команды

-index restore c:\backups
-index domain=index1 -index restore c:\backups
-index domain=index2 -index restore c:\backups
-index domain=index3 -index restore c:\backups

восстановят структуру индексной базы, сохраненной в предыдущем примере.

При сохранении и восстановлении можно указать несколько индексов в команде -index domain=XXX;YYY;ZZZ (см. подробнее о команде -index domain).

Команда -index domain=* распространяет свое действие на все актуальные индексы. Поэтому пара команд

faind -index backup c:\backups\01-01-2006

faind -index domain=* -index backup c:\backups\01-01-2006

сохранит всю актуальную индексную информацию в каталоге c:\backups\01-01-2006.

Команды резервного копирования не работают для серверного варианта индексатора с хранилищем в MySQL, в этом случае следует использовать штатные средства администрирования самой СУБД.

Команды управления для многопоточного сервера

Снятие всех блокировок индексных баз.

-index unlock_all

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

Для серверного режма с параллельным выполнением множества запросов данная команда может привести к большим неприятностям, так как она нарушает внутреннюю логику защиты индексов от неправильного использования. Для разблокировки конкретного индекса в этих условиях лучше использовать команду -index domain=xxx -index unlock.

Снятие блокировки для одного заданного индекса

-index domain=xxx -index unlock

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

Общий доступ при распределенном поиске

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

-index domain=XXX -index share

и

-index domain=XXX -index unshare

Посмотреть список индексов в общем доступе можно командой

-index list_shared

Тегирование документов

Запоминание в базе данных тегов для проиндексированных документов

-index store_metainfo filename options

Источником тегов служат текстовые файлы с указанным в команде именем filename. В каждой проиндексированной папке движок ищет файл с таким именем, и если находит - читает из него теги и запоминает в индексной базе. Формат файла указан в параметре options.

Параметр options является списком из значений, разделенных запятыми:

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

xml - файл тегов имеет формат XML.

server - теги запоминаются не в локальном хранилище тегов, а в серверной БД.

Рассмотрим такой пример. Допустим, индексатор запущен командой

-index domain=Index1 -index store_metainfo descript.ion csv,server -dir e:\docs

В каждой папке, которую индекстор обрабатывает при рекурсивном обходе e:\docs, он после обработки файлов ищет файл с указанным именем descropt.ion. Если этот файл найден, то движок открывает его. Если у файла есть маркер BOM, то файл может быть в кодировке utf8 или другой, в противном случае кодировка соответствует текущей системной однобайтовой.

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

file1.txt;это первый файл
  file2.txt;это второй файл

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

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

-index show_metainfo

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

Когда индексирование неэффективно

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

Один из таких случаев - поиск образцов текста в файле неизвестного формата. Поисковый движок φaind умеет искать паттерны в произвольных двоичных файлах (с неизвестным вообще форматом - см. соответствующие опции, например -allow_raw). Один двоичный файл может содержать текст в разных кодировках - к примеру, исполнимый файл, содержащий строки сообщений в ASCII (1 байт на символ) и UNICODE (2 или 4 байта на символ). Обычная стратегия поиска в таких файлах - перебирать различные варианты кодирования символов и пытаться читать файл, извлекая слова. При этом возникаем очень много мусора - невозможных слов, которые отсеять без полного словаря невозможно. Эти невозможные слова, состоящие из всевозможных сочетаний символов, моментально загрязняют список ключевых слов индексатора, приводя к ее разбуханию во много раз (для английского и русского языков вместе реально получается до 5 миллионов ключевых слов, при добавлении "мусорных слов" база быстро разбухает до 10 миллионов, из которых 5 миллионов - однократно встретившиеся).

Поэтому индексировать двоичные файлы не рекомендуется - хотя это возможно.о.

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

Отказоустойчивость базы данных

Устойчивость индексатора (то есть хранимой индексной информации) полностью определяется используемым back-end хранилищем. Например, для простейшего файлового хранилища индексатор старается поддерживать корректность хранимой информации только для корневой таблицы со списком описаний индексов. Если во время выполнения операции типа DDL, например при изменении имени индекса, произойдет сбой, то после перезапуска хранилище попытается вернуться к предыдущему варианту корневой таблицы до начала изменений (см. статью о восстановлении баз данных). Так как файловое хранилище реализует только крайне простой алгоритм взаимодействия с файловой системой, то в некоторых случаях возможно повреждение корневой таблицы индексов, что приведет к полному отказу индексатора. Кроме того, файловое хранилище не реализует никаких средств для поддержки целостности отдельных индексов. Поэтому сбой во время обновления динамического индекса скорее всего приведет к порче соответствующего индекса с непредсказуемыми последствиями.

Второй поддерживаемый вариант хранилища частично опирается средства СУБД SQLite по поддержанию целостности корневой таблицы. Движок этой СУБД ведет журналы транзакций, прозрачно выполняя откаты в случае сбоя. Однако, сами индексы в этом хранилище никак не защищены от порчи при сбоях.

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

Дополнительные материалы

Процедурный API поисковой системы

Консольная поисковая утилита

Синтаксис определения области поиска

Индексирование в настольной поисковой системе

Где скачать поисковую систему и SDK

Скачать SDK поисковой системы с примерами и другие компоненты можно здесь поисковая система

  © Mental Computing 2010
изменено 07-Jun-10