2.2 Особенности поисковых систем
Особенности поисковых систем. В работе поисковый процесс представлен четырьмя стадиями: формулировка (происходит до начала поиска); действие (начинающийся поиск); обзор результатов (результат, который пользователь видит после поиска); и усовершенствование (после обзора результатов и перед возвращением к поиску с иной формулировкой той же потребности). Более удобная нелинейная схема поиска информации состоит из следующих этапов:
– фиксация информационной потребности на естественном языке;
– выбор нужных поисковых сервисов сети и точная формализация записи информационной потребности на конкретных информационно-поисковых языках (ИПЯ);
– выполнение созданных запросов;
– предварительная обработка и выборка полученных списков ссылок на документы;
– обращение по выбранным адресам за искомыми документами;
– предварительный просмотр содержимого найденных документов;
– сохранение релевантных документов для последующего изучения;
– извлечение из релевантных документов ссылок для расширения запроса;
– изучение всего массива сохраненных документов;
– если информационная потребность не полностью удовлетворена, то возврат к первому этапу.
3 Строение поисковой системы
3.1 Архитектура поисковой системы
Рассмотрим классическую архитектуру, которая чаще всего реализована на корпоративных сайтах и информационных порталах. Такая архитектура изображена на рисунке 3.1
Рисунок 3.1 Архитектура поисковой системы
Разберем по частям то, что изображено на рисунке. Существует клиентская вычислительная машина под управлением ОС Windows и существует Web-сервер под управлением UNIX-подобной ОС. На стороне клиента запущен типичный браузер, такой как Netscape. На стороне сервера запущен web сервер, который обслуживает запросы от браузера, передавая запросы презентационному слою понимающему CGI. Презентационный слой передает запросы к поисковому механизму в случае вызова услуги поиска или отображает наполнение (content) сайта. При работе администратора презентационный слой также может передавать запросы на инициализацию механизма индексации нового контента, который еще не индексирован. Это необходимо по той причине, что пока текст не индексирован, поиск в нем с помощью поисковой машины невозможен.
Идея заключается в следующем. Существуют мегабайты текстовой информации, и скорость поиска документов содержащих заданные ключевые слова отнимает очень многопроцессорного времени. Предположим, в 10 мегабайтах текстовой информации ключевое слово будет находиться в течение 10 секунд. И вот заходит посетитель на Ваш сайт, задает ключевые слова, вызывает услугу поиска и ждет 10 секунд, пока ваш сервер не выдаст ему результат. Предположим, случилось так, что одновременно запросило поиск 5 человек. Естественно, время ответа увеличится в 5 раз. Получается, что в среднем по 50 секунд пользователь будет ждать ответа от вашего сервера. Это не приемлемо, особенно если у Вас сотни мегабайт текстовой информации и время реакции системы будет катастрофически велико. Необходимо использовать другой подход при поиске ключевых слов в текстовой информации - время ответа сократить до миллисекунд.
3.2 ER-модель поискового механизма
Существует такая хорошая характеристика реляционных баз данных, как очень маленькое время выборки конкретной записи из миллионов других. Это достигается созданием, так называемого, индекса к таблице на какое-то из полей этой таблицы. Обычно индексы реализуются с применением алгоритма сбалансированного двоичного дерева. Предположим, у нас есть таблица, в которой всего один столбец и в каждой записи таблицы хранится фамилия человека. Предположим, мы загнали в такую таблицу 1 миллион фамилий. Нам необходимо проверить существует ли в этой таблице фамилия ИГУМНОВ. Предположим, что мы еще никаких индексов на эту таблицу не сделали, так же фамилия ИГУМНОВ стоит посередине таблице. Когда мы пошлем вот такой запрос: select surname from ourtable where surname='ИГУМНОВ' база данных переберет пол миллиона записей пока не дойдет до фамилии ИГУМНОВ и не выдаст результат. Получается слишком медленно. Но как только мы сделаем индекс на поле нашей таблицы, как сразу все наши запросы будут обрабатываться за миллисекунды, чего мы и добиваемся. Естественно, одной таблицы будет мало для решения нашей проблемы. Классическая структура базы данных, которая позволит решить нашу проблему, изображена на рисунке 3.2:
Рисунок 3.2 Классическая структура базы данных
Начнем с таблицы document. В этой таблице хранятся имена файлов или URL'ы страниц и каждой такой записи сопоставлен уникальный ключ id. В таблице dictionary хранятся все слова, которые могут встретиться в наших документах, и каждому слову сопоставлен уникальный id. Естественно, создаются индексы на поле word в таблице dictionary и на поле id в таблице document. В нашем примере существует отношение многие ко многим. Это необходимо, так как в таблице match мы храним соответствие слова и документа. Другими словами, в таблице match хранится информация о том, какие слова есть в каждом документе. На таблицу match создают индекс, на поле dict_id.
3.3 Индексный механизм
Прежде чем ваши документы будут доступны для поиска, их необходимо проиндексировать. Объем индексной информации, полученной из текста, может быть в два раза больше чем сам тексте. А может еще больше, в случае если вы будете не оптимально использовать память. Алгоритм выглядит следующим образом:
1. получаем документ для индексирования;
2. регистрируем его в таблице document, запоминаем полученный его уникальный id и будем его называть doc_id;
3. разбиваем документ на отдельные слова;
4. узнаем уникальные id этих слов из таблицы dictionary и будем их называть dict_id;
5. потом заносим записи с нашим одним doc_id и разными dict_id (для каждого слова в документе) в таблицу match.
3.4 Поисковый механизм
После того как мы проиндексировали наши документы, нужно понять какие запросы посылать в базу, что бы искать эти документы по ключевым словам. Предположим, есть поисковая фраза "река объ". Пользователю необходимо получить все документы содержащие эти два слова. Сначала нужно обратиться к таблице 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.- 1992.-№5.-С.19-27 Кноп К. Поиск в Интернете как хроническое заболевание // Мир Internet. - 2002. - N 10. - С. 33-35 Конжаев А. Стратегия информационного поиска // http://www.msiu.ru. Попов С. Поиск информации и принятие решения // НТИ. Сер.2.-2001.-№1.-С.1-4 Степанов В.К Русскоязычные поисковые механизмы в Интернет // ComputerWorld Россия.-1997.-N11 ...
... 11,375 53,7 Google 3,932 18,6 Rambler 2,939 13,9 Mail.ru 1,863 8,8 Апорт 0,155 1,5 Другие 0,39 3 Диаграмма 2 – Рейтинг основных Российских поисковых систем (2007г.) 1.4 Обзор основных мировых поисковых систем На сегодняшний день всемирная сеть Интернет насчитывает огромное множество поисковых систем во всех странах мира, из них всех можно выделить несколько самых крупных и ...
... реализованы как простая программная система, которая запрашивает информацию из удаленных участков Интернет, используя стандартные cетевые протоколы. 4. Наиболее популярные русскоязычные справочно-поисковые системы в интернет 4.1 Rambler Поисковая система Рамблер начала свое существование с 1996 года. На сегодняшний день она является одной из самых популярных в РуНете, уступая лишь ...
... управления, ее разработки и внедрения в жизнь. Второй раз потоки информации используются для адекватного управления в рамках уже сложившейся системы логистики. 2. Стратегия и организация информационного обеспечения логистики На уровне фирмы логистическая система распадается на ряд структур, которые можно представить в виде горизонтальных функциональных субсистем в сфере закупок, ...
0 комментариев