 |
Контекстно-поисковые процедуры на основе
|
|
|
|
Реляционных баз данных
Рассмотрим классическую архитектуру, которая чаще всего реализуется на корпоративных сайтах и информационных порталах (рис. 2.5).
Рис. 2.5. Поисковая архитектура корпоративных ИУС
Итак, существует клиентская вычислительная машина под управлением операционной системы (ОС) Windows и существует веб-сервер под управлением UNIX-подобной ОС. На стороне клиента запущен типичный браузер, такой как Netscape. На стороне сервера запущен веб-сервер, который обслуживает запросы от браузера, передавая запросы презентационному слою, понимающему CGI. Этот слой передает запросы к поисковому механизму в случае вызова услуги поиска или отображает наполнение (content) сайта. При работе администратора презентационный слой также может передавать запросы на инициализацию механизма индексации нового контента, который еще не проиндексирован. Это необходимо в связи с тем, что пока текст не проиндексирован, поиск в нем с помощью поисковой машины невозможен [51; 79; 100].
Идея контекстно-поисковых процедур заключается в следующем. Большой объем текстовой информации приводит к тому, что скорость поиска документов, содержащих заданные ключевые слова, будет отнимать очень много времени на обработку этой информации. Предположим, в 10 Мб текстовой информации ключевое слово будет находиться в течение 10 с. При наличии десятков клиентов, вызывающих услугу поиска, это не приемлемо, особенно если в ИУС содержатся сотни мегабайт текстовой информации. Необходим другой подход к поиску ключевых слов в текстовой информации, который позволил бы сократить время ответа до миллисекунд.
Известна такая характеристика реляционных баз данных, как очень малое время выборки конкретной записи из миллионов других. Это достигается, как правило, за счет создания индекса к таблице на какое-то из полей этой таблицы. Обычно индексы реализуются с применением алгоритма сбалансированного двоичного дерева.
|
|
|
Допустим, что у нас имеется таблица, в которой всего один столбец и в каждой записи таблицы хранится фамилия человека, а также что мы храним в такой таблице 1 млн фамилий. Необходимо проверить, существует ли в этой таблице фамилия Игумнов. Предположим, что никаких индексов на эту таблицу мы еще не создали и фамилия Игумнов стоит посередине таблицы. Когда мы пошлем запрос: select surname from ourtable where surname = 'ИГУМНОВ', то база данных переберет полмиллиона записей, пока не дойдет до фамилии Игумнов и не выдаст результат. Этот процесс занимает слишком много времени. Но как только мы создадим индекс на поле таблицы, так все наши запросы сразу же будут обрабатываться за миллисекунды, чего мы и добивались.
Естественно, что одной таблицы для решения проблемы поиска будет недостаточно. Принятая структура базы данных, которая позволит решить эту проблему, представлена ниже (рис. 2.6).
|
|
|
|
|
|
|
|
|
|
Рис. 2.6. Классическая структура базы данных
В таблице document хранятся имена файлов или ссылки на страницы, и каждой такой записи сопоставлен уникальный ключ id.
В таблице dictionary содержатся все слова, которые могут встретиться в документах системы, и каждому слову сопоставлен уникальный ключ id, после чего создаются индексы на поле word в таблице dictionary и на поле id в таблице document.
В таблице match хранится соответствие слова и документа, т. е. информация о том, какие слова есть в каждом документе. На таблицу match создается индекс на поле dict_id.
Прежде чем документы ИУС будут доступны для поиска, их необходимо проиндексировать. Объем индексной информации, полученной из текста, может быть в два раза больше, чем сам текст, или еще больше (в случае неоптимального использования памяти системы). Алгоритм индексирования работает следующим образом:
|
|
|
- выбирается документ для индексирования;
- этот документ регистрируется в таблице document и его уникального ключ id запоминается. Документ будет называться doc_id;
- документ разбивается на отдельные слова;
- уникальные ключи id этих слов определяются по таблице dictionary и им присваивается имя dict_id;
- запись с одним doc_id и разными dict_id (для каждого слова в документе) заносится в таблицу match.
После индексации документов нужно решить, какие запросы посылать в БД, чтобы искать эти документы по ключевым словам. Предположим, что есть поисковая фраза «река Обь». Пользователю необходимо получить все документы, содержащие эти два слова. Сначала следует обратиться к таблице dictionary и узнать уникальные id этих слов, например $dict_id1 и $dict_id2. Затем в таблицу match посылается запрос, который выдаст только номера документов, содержащих эти два слова, например: SELECT doc_id FROM match where dict_id = $dict_id1 group by doc_id INTERSECT SELECT doc_id FROM match where dict_id = $dict_id2 group by doc_id. Если пользователь введет три слова, то придется добавить еще раз INTERSECT и третью часть SQL-запроса. По полученным в результате запроса ключам doc_id из таблицы document можно извлечь информацию об имени файла документа.
Механизм взаимодействия с поисковой системой включает три потока управления (рис. 2.7): первый обслуживает запросы пользователя, второй выполняет поисковые запросы, а третий занимается индексированием новых документов, поступающих в систему. Первый поток – это ссылка на поисковые системы Perl, Servlet, ASP или PHP, которая из ключевых слов пользователя формирует поисковые SQL-запросы. Второй поток – это СУБД, которая поддерживает целостность данных, индексный механизм и обслуживает SQL-запросы. Третий поток – это тоже ссылка, которая работает с новыми документами, индексирует их и посылает запросы в базу данных на внесение новой индексной информации.
Рис. 2.7. Механизм взаимодействия с поисковой системой в ИУС
Представленный выше пример характеризует один из наиболее часто используемых алгоритмов. Конечно, данный подход не претендует на полноту и оптимальность, так как может возникнуть ряд новых проблем, например большие затраты времени на процесс индексирования, большое количество результатов запроса и т. д.
|
|
|
* * *
Таким образом, применение глобальной сети Интернет для поиска актуальной информации по любой теме дает наиболее полную информацию и является наименее ресурсоемкой технологией.
Для информационного поиска применяются поисковые системы разных типов. Но при этом возникает проблема сокращения трудоемкости поисковых работ, связанных с масштабным сбором информации в Интернете. Это приводит к необходимости планирования поиска. Ошибочная логика построения запроса, неоптимизированная последовательность применения инструментов, попытка форсировать поиск – все это не только затягивает получение результата на дни и даже недели, но и может поставить под сомнение смысл всех поисковых процедур.
Оптимизация процедуры поиска возможна за счет использования глобальных индексов не для прямого поиска нужных сведений, а для локализации региональных и специализированных поисковых систем.
В связи с глобальными и стремительными темпами роста Интернета, все большее место в поиске информации занимают метапоисковые технологии, которые позволяют производить поиск информации, охватывая больший ареал Сети, что способствует более качественному сбору интересующей пользователя информации.
Использование мультилингвистического информационно-термино-логического базиса для поисковых технологий в корпоративных ИУС повышает эффективность сетевых поисковых систем при определении релевантности и ранжировании данных и документов.
Модели и алгоритмы поиска
Документов в многоязычных
Информационных ресурсах
Ниже будут рассмотрены новые алгоритмы поиска документов, определения их релевантности и ранжирования информации в рамках полученной выборки из мультилингвистических информационных тематических коллекций, которые могут использоваться как в системах типа каталог, так и в обычных поисковых сервисах ИУС, а также в сервисах сети Интернет.
|
|
|
|
|
|
