10.1.1. Настраиваем Яndex.Server

10.1.1. Настраиваем Яndex.Server

Программу можно разделить на две основные и две вспомогательные подсистемы:

? основные — подсистема индексации и подсистема поиска. Индексатор обеспечивает анализ документов и сохранение информации о них в индексных файлах. Поисковый сервер обрабатывает запросы и формирует полученные результаты;

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

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

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

Установка и настройка

Для установки программы под Windows (есть релизы и под другие системы —.nix, FreeBSD, Sun Solaris) достаточно распаковать дистрибутив в выбранный вами раздел (размер дистрибутива для Windows составляет примерно 6 Мбайт), отредактировать конфигурационный файл, установить программу в качестве системного сервиса. После выполнения этих действий поиск готов к работе.

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

Конфигурационный файл обычно называется yandex.cfg и располагается в том же каталоге, где находится выполняемый модуль Яndex. Server (для Windows). В этом файле можно определять параметры, относящиеся к сервису в целом, к процессу индексирования и процессу поиска. Каждый параметр определяется своей директивой, состоящей из одного или нескольких слов, разделенных пробельными символами.

Директивы конфигурационного файла могут быть сгруппированы в секции. Каждая секция начинается со строки <имя_секции> и кончается строкой </имя_секции>, где Имя_секции соответствует параметру, настраиваемому с помощью одной или нескольких директив, расположенных внутри секции. Секции могут быть вложенными.

Секция Server

Секция Server, не являющаяся обязательной, определяет настройки сервера. В ней могут быть определены:

? IP-адрес, на котором работает Яndex.Server. Значение должно соответствовать одному из допустимых IP-адресов компьютера;

? порт, на котором работает Яndex.Server. По умолчанию используется порт 17000;

? хост, на котором работает Яndex.Server. Значение по умолчанию: официальное имя хоста;

? количество одновременно выполняемых поисковых запросов. Если уже выполняется определяемое данной директивой количество запросов, выполнение вновь поступивших запросов откладывается до тех пор, пока не будут выполнены текущие запросы. По умолчанию это значение равно 5;

? максимальный размер очереди поисковых запросов, ожидающих начала выполнения. В случае нулевого значения директивы максимальный размер очереди запросов бесконечен. Если начала выполнения уже ожидает определяемое данной директивой количество запросов, на вновь поступившие запросы сервер отвечает HTTP/1.0 503 Service Unavailable и не выполняет их;

? рабочий каталог Яndex.Server. Должен быть указан абсолютный путь;

? путь к файлу, в который будут выводиться сообщения Яndex.Server.

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

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

Листинг 10.1. Пример секции Server

<Server>

Port 80

Host www.my_site.ru Threads 4 QueueSize 20 <Authorization>

UserName webadmin UserPassword abv12345 </Authorization>

</Server>

Секция Collection

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

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

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

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

IndexLog indexer.log

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

Вы, наверно, помните, что "большой" Яндекс индексирует не все слова, найденные в документах. Существует определенный набор стоп-слов, которые игнорируются в процессе обработки. Рассматриваемая программа также может учитывать стоп-слова, не подлежащие индексированию. Этот список входит в состав поставки в виде файла, который вы можете самостоятельно редактировать. При этом необходимо учитывать лишь то, что текст в нем должен быть набран в кодировке Windows-1251. Директива, определяющая имя файла, называется stopWordFiie.

На Яндексе при просмотре результатов поиска для найденных документов присутствует ссылка Сохраненная копия, позволяющая посмотреть документ даже в том случае, если он удален с сайта. Аналогичная возможность есть и в программе Яndex.Server. Режим сохранения документов (без элементов форматирования) задается директивой storeArchive, используемой по умолчанию. Если вы не отказываетесь от использования этой опции, помните, что в этом случае архив сохраненных документов (текстов) может иметь размер до 30–40 % от общего объема проиндексированных документов.

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

При этом размер индекса увеличивается примерно в 2 раза. (В последней версии программы точные словоформы учитываются всегда.)

Примечание

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

На начальном этапе настройки с помощью директивы Debug можно задать режим получения отладочной информации.

Области индексирования

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

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

Существует три способа получения данных для индексирования:

? чтение файлов, доступных в локальной сети, где работает индексатор, с использованием протоколов операционной системы;

? обращение к веб-серверам по протоколу HTTP;

? обращение к произвольному внешнему источнику данных по специальному протоколу, реализованному в модуле связи с источником данных.

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

Способ доступа к данным для каждой секции indexedArea определяется единственным образом и должен включать одну из возможных директив. Директива HttpPrefix определяет доступ по HTTP-протоколу, директива FilePrefix определяет путь к разделу в локальной сети.

Но можно обойтись и без этих директив, если список начальных адресов (URL) будет в явном виде задан в ключе StartUrls, например, так:

StartUrls = http://localhost/my_site/index.htm

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

Например, для определения режима получения URL документа применяются такие директивы:

? IndexFollow — индексирует документы и распознает гипертекстовые ссылки для получения URL новых документов;

? IndexNofollow — позволяет индексировать документы, но не распознает гипертекстовые ссылки для получения URL новых документов;

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

Поисковый сервер и защита от роботов

А вот еще одна интересная особенность продукта, в какой-то мере раскрывающая и работу "пауков" большого Яндекса. Веб-страницы могут содержать специальный мета-тег robots. Этот мета-тег имеет более высокий приоритет, чем настройки индексатора или директивы управления, заданные в файле robots.txt. То есть если директивы управления в файле robots.txt разрешают индексировать все файлы в каталоге, то блокирующий мета-тег <meta name="robots" content="noindex, nofollow"> может запретить индексирование страницы, находящейся в этом каталоге.

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

? AllowMetaRobots — учитывает при индексировании содержимое метатега robots;

? IgnoreMetaRobots — игнорирует содержимое мета-тега.

При индексировании документов по протоколу HTTP Яndex.Server поддерживает стандарт исключений для роботов. В соответствии с этим стандартом, правила, управляющие поведением поискового робота, должны располагаться в файле /robots.txt, лежащем в корне веб-сервера. Но и здесь есть обходные маневры (впрочем, обходные лишь для вас, поскольку на свой веб-сервер этот поисковик вы будете устанавливать сами, и сами будете определять, что включать в состав индексируемых документов, а что не включать). Пример конфигурации HTTP-запросов при индексировании хоста приведен в листинге 10.2.

Листинг 10.2. Пример конфигурации HTTP-запросов при индексировании хоста

<HttpOptions name="myhttp">

Timeout: 150 Delay: 0

ProxyUrl: http://proxy.my_site.ru:8080 <Authorization>

UserName: my_site UserPassword: abf12345 </Authorization>

<Headers>

User-Agent: MyYandexServer/3.0 From: admin@host.ru Accept-Language: ru, *;q=0.1 MyHeader: TestStroka </Headers>

</HttpOptions>

Если вам нужно, чтобы Яndex.Server при индексировании вашего сайта не учитывал общие правила для поисковых роботов, модифицируйте файл robots.txt, добавив специальное правило для User-Agent, заданного при конфигурировании HTTP-запросов. В следующем примере (листинг 10.3) каталог скриптов закрывается от всех роботов, кроме робота MyYandexServer, которому открыто все.

Листинг 10.3. Пример файла robots.txt

User-Agent: *

Disallow: /cgi-bin/

User-Agent: MyYandexServer Disallow:

Форматы индексируемых документов

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

Каждая секция DocFormat должна включать обязательную директиву MimeType. Также могут присутствовать необязательные директивы Extensions, Module, Symbol и Config. Директива MimeType задает произвольное имя документного формата, уникально идентифицирующее этот формат. Обычно в качестве идентификатора формата используется так называемый медиа-тип, значения которого специфицированы для большого количества форматов.

Директива Extensions задает расширения файлов данного формата. Если для получения содержимого документа используется файловая система, документы в файлах с заданными расширениями будут считаться имеющими медиатип, указанный в директиве MimeType. Тем не менее если для получения содержимого документа используется веб-сервер, возвращающий заголовок Content-type, в качестве медиа-типа используется значение этого заголовка. Пример секции DocFormat приведен в листинге 10.4.

Листинг 10.4. Пример секции DocFormat

<DocFormat>

MimeType text/html

Extensions.htm, html, asp

Config attr.cfg

</DocFormat>

Парсеры

Одно из важнейших свойств поисковой системы — возможность индексирования файлов произвольного формата. Это обеспечивается с помощью отдельных модулей — парсеров (еще их называют интерпретаторами форматов документов). Для каждого типа файлов применяется свой модуль. В платную версию поисковика включены парсеры для документов в форматах XML, RTF, PDF, MP3, FLASH, MS Word, MS Excel, MS PowerPoint, помимо входящих в стандартную поставку парсеров для форматов text/html и text/plain. Используя спецификацию, независимые разработчики могут разработать и иные парсеры, необходимые для используемых ими форматов данных, однако подключить их можно только к платной версии.

Из всех парсеров, поставляемых с программой, два являются конфигурируемыми. Это парсеры HTML и XML-документов. Остальные используются "как есть". В документации, входящей в комплект поставки, есть разделы, посвященные вопросам настройки парсеров под решение конкретных задач.

Внимание

На сайте Яндекса представлена программа mystem (http://company.yandex.ru/

technology/products/mystem/mystem.xml). Это — парсер, осуществляющий морфологический анализ текста на русском языке. Программа предназначена для некоммерческого использования.

У большинства типов документов есть своя внутренняя структура, определенные элементы которой несут свойственную лишь им смысловую нагрузку. В почтовых письмах это могут быть поля from, to, Subj, в вебдокументах — это заголовок, тело документа, ключевые слова. В теле могут присутствовать заголовки различных уровней, ссылки, картинки и т. д. Различные части структурированных таким образом документов в Яндексе называются зонами.

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

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

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

Данный текст является ознакомительным фрагментом.