Мы уже рассматривали (см. "КВ" №47) системы сжатия больших объемов информации в базах данных и обсуждали, для чего это делается. Понятно, что оптимальное сжатие значительно уменьшает размер индексного файла, но одного этого недостаточно для реализации быстрого поиска нужного слова, слово- или буквосочетания во всей базе. Как его все-таки можно осуществить?

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

Какая есть альтернатива? Например, для "ЮрИнформа 3.5" разработан и внедрен качественно другой поиск, основанный на современных технологиях и ноу-хау из СУБД LeoBase (цикл статей, посвященных LeoBase, публиковался в нашей газете).

Как это работает

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

Во-первых, это технология виртуальных битовых массивов (ВБМ), которые настраиваются на максимально возможный номер бита так, чтобы оптимально использовать выделяемую им память. После открытия комплекса баз весь механизм ВБМ настраивается, чтобы адресовать запись БД с максимально возможным номером. Нужно понимать, что поиск представляет собой манипуляции с неким количеством выделенных записей, с которыми совершаются различные операции: например, очередная выборка осуществляет уточняющий поиск - основной прием в посимвольном поиске слова. В виртуальном битовом массиве каждый элемент уникален. ВБМ можно представить как массив целых чисел с уникальными значениями. Важно также и то, что в таких массивах память используется очень оптимально. При работе менеджер ВБМ может использовать всю доступную ему оперативную память, но при запросе с помощью специальной процедуры эту память можно освободить. В Windows-версии такого запроса делать не нужно - память освободится автоматически. Информация из индекса LeoBase заносится в битовый массив очень быстро (например, занесение всей текущей группы повторяющихся значений или занесение всех значений индекса в определенном диапазоне номеров в индексе). Именно благодаря такой возможности результатом запроса на поиск в LeoBase являются все записи, удовлетворяющие запросу, а не только первая, причем, результат возвращается очень быстро.

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

Ну и, конечно же, приличная скорость поисковых операций не может существовать без оптимизации процесса файлового ввода-вывода. Тут вступает в действие уникальная в своем роде система кэширования файлов LeoBase Smart Files (LSF). Это система буферизации чтения и записи. Под буфер может выделяться вся память компьютера, причем набор операций с файлами по сравнению со стандартным значительно расширен. Он позволяет использовать LSF в качестве полноценного файлового менеджера. Кроме стандартных записи и чтения, поддерживается заполнение файла определенным байтовым значением, вырезание фрагмента файла, вставка пустого места в любое место файла, перемещение фрагмента файла в любое место и многое другое. Для успешной работы LSF необходимо около 10 К оперативной памяти, а для регистрации одного файла требуется около 60 байт памяти.

Как это выглядит

Если механизм поиска уже готов, перед разработчиком встает следующий вопрос - как его внедрить в систему. Как сделать так, чтобы пользователь мог легко использовать все возможности механизма. Нужно внимательно продумать интерфейс диалогового окна, все опции, индикаторы и переключатели, которыми сможет манипулировать пользователь. Один из вариантов - пример того, как выглядит реализация механизма поиска в системе "ЮрИнформ 3.5" или поиск в справочной системе Windows 95 (не будем только забывать, что размер базы данных в нашем случае в несколько сотен раз больше).

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

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

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

Если в строке поиска - несколько слов, то можно переключать опцию выбора типа поиска: "искать все вхождения" или "хотя бы одно".

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

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

Вадим МИРКО