Turtle

 
 
 
   РАСШИРЕННЫЙ ПОИСК
   ПОИСК ПО ФРАГМЕНТУ
   ПОМОЩЬ
   ПРОСТАЯ ФОРМА
 
 СИНОНИМЫ   ВСЕ ФОРМЫ СЛОВ
 Добавить   Архитектура   Запросы сейчас   Цифры и факты   FAQ   Кнопка поиска   Сделать стартовой 

3.8. Некоторые замечания о поиске (кэш, отображение, дубли, ссылки).

Замечание 1.
Обратим внимание на то, что языки, на которых мы разговариваем, хотим мы этого или нет, имеют ограниченный набор слов. Некоторые слова используются при поиске различными людьми часто, другие значительно реже. Для частых слов можно предусмотреть сервер, который собирает результаты таких запросов. В этом случае при повторном запросе нет необходимости "ставить на уши" весь набор поисковых серверов, достаточно взять полученные результаты у этого сервера. Мы называем такой сервер кэширующим (Results Cache Server). Этот же сервер может применяться для отображения второй, третьей и.т.д. страницы результатов поиска. По данным такого сервера можно динамически наблюдать за введенными пользователями запросами (у некоторых поисковых систем есть функция - показать 20 последних запросов к системе. Мы также можем отобразить подобную информацию, используя специальный запрос к Cache Server). Программно он может быть реализован как независимая единица или войти в состав сервера балансировщика нагрузки (мы имеем оба варианта). В поисковой системе, кроме специального кэша результатов, реализован также кэш наиболее часто "поднимаемых с диска" поисковых терминов на каждом процессоре поиска SP. Дело в том, что очень часто возникает ситуация, когда пользователь повторно нажимает кнопку поиска по ошибке или недождавшись выполнения посланного им запроса. При этом навигационная программа пользователя добросовестно игнорирует предыдущее соединение и снова посылает поисковый запрос. Мы называем такой эффект электронным термином "дребезг контактов". Кэш поискового процессора предотвращает повторное чтение данных с дисковых массивов. Это может позволить существенно улучшить суммарную производительность системы.

Замечание 2.
В приведенной выше схеме поиска начисто отсутствует отображение результатов. Мы же не можем показать конечному пользователю набор ничего ему не говорящих цифр ID-документов. Мы должны показать фрагмент документа с ссылкой на оригинал, и желательно, чтобы фрагмент отображал часть текста, соответствующую поисковому запросу. Вспомним о том, что сами документы в процессе накопления мы складывали на архивных серверах. Таким образом, прослеживается первая ниточка между двумя крайними полюсами системы накопления и поиска. Архивный сервер умеет не только сохранять в специальном компрессированном формате исходный текст документа, но и отображать наиболее подходящий фрагмент текста. Этот тип серверов также наделен кэширующими свойствами. Он может отобразить документ даже в том случае, если оригинал уже был удален со своего сервера. На него также возлагаются функции ретроспективного просмотра документов, изменяющихся во времени.

Замечание 3.
В сетевом мире содержится много документов, которые не являются точными копиями друг друга. Такие документы могут содержать общие фрагменты или не очень сильно отличаться по тексту. Если в результатах поиска такие документы будут показаны вместе, то это вызовет у искавшего, как минимум, легкое раздражение. Для выявления нечетких дублей нами разработана специальная технология, основанная на выделении некоторого набора характеристических цифр (fingerprints) для каждого документа. Разработаны также быстрые алгоритмы работы с подобными типами данных. Используя эту технологию, можно с достаточно высокой степенью достоверности выяснить, является ли один документ схожим с другим. Для подобных целей нами разработан специальный сервер Fingerprints Server (FPS). Его назначение состоит в том, чтобы отфильтровать из пачки документов похожие. Исходными данными его снабжают накопители данных CA, описанные в начале. Запросы фильтрации на такой сервер посылают разборщики запросов QP после получения результатов работы от процессоров поиска. Таким образом, в целом в поисковой системе реализована двухуровневая модель выявления дублей. Первая - на основе точного совпадения содержания посредством технологии вычисления MD5-документов. Вторая - на основе фингерпринтов. Технологию фингерпринтов можно также успешно применять для обратной задачи - поиска "похожих" документов. Отметим, что в данном случае под похожестью мы понимаем наличие какого-то количества общего текста в документах. Технология поиска "похожих" документов позволяет проделывать массу, на первый взгляд не очевидной, полезной работы. Например, с помощью данной технологии можно по достаточно длинной цитате найти ее первоисточник в оригинале, разумеется, если оригинал представлен в сети в виде документа. Или разыскать документы, цитирующие содержание оригинала, найти потенциальный плагиат и пр.

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

Замечание 4.
Здесь мы рассмотрели только примерный механизм поиска в рамках поисковой системы "Turtle". Механизм поиска по локальным коллекциям, который мы собираемся поставлять в виде программного обеспечения желающим, выстроен совсем по другим принципам, т.к. хранилище данных имеет простую структуру.

Замечание 5.
Если конечный пользователь пожелает узнать, какие документы ссылаются на данный документ, то описанный индекс, распределенный по группе SP, не сможет ответить на данный вопрос. Поэтому в поисковом комплексе имеется специальный сервер ссылок References Server, который содержит информацию о ссылках. Этот сервер в процессе работы накопления взаимодействует с центральным диспетчером посредством SSTP-протокола и получает от него требуемые данные. Хранимые на нем данные, помимо визуализации подобных связей, участвуют также в вычислении одной из компонент ранжирования документов PageRank.
Все вышесказанное найдет отображение на результирующей функциональной схеме поискового комплекса.

<< 3.7. Ранжирование результатов | Содержание | 3.9. Язык поисковых запросов >>
Наверх Назад Turtle
 Черепаший Ранк.   Реклама на Turtle   Логотипы   Правовая информация   Конфиденциальность   Контакты 
    ©ЗАО "Группа компаний Стек". 2003-2007