5.6. Внешние источники данных

5.6.1.1. Конфигурационный файл индексатора

Индексирование MySQL баз данных реализовано в Яndex.Server 3.4 посредством специального модуля связи с источником данных, который находится в файле ypmysql.dll для Windows и libydmysql.so для Unix. Поэтому для индексирования MySQL-данных в конфигурационном файле индексатора надо задать хотя бы одну секцию следующего вида (см. раздел Секция DataSource).

  <DataSource>
      Name    mysqldata
      Module  ypmysql.dll
      Config  mysql_datasrc.cfg
  <DataSource>

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

5.6.1.2. Конфигурирование источника данных

Основная секция конфигурационного файла источника данных должна содержать следующие директивы.

HTTP-заголовок может состоять из любых разрешенных данным протоколом модификаторов, но на текущий момент Яndex.Server 3.4 умеет обрабатывать только два их типа: Content-Type и Last-Modified.

• Content-Type может иметь те же значения, что и соответствующий HTTP-заголовок;

• Last-Modified задает любое число, по которому определяется, изменен документ или нет. Если это число больше числа, сохраненного для данного документа в индексе при предыдущем индексировании, документ считается измененным, если нет - неизмененным.

Как уже не раз упоминалось, для хранения всех обработанных документов Яndex.Server 3.4 использует один набор индексных файлов. Это же относится и к данным, полученным из SQL-баз. Они хранятся совместно со всеми остальными. Но, так как в отличие от стандартных HTML-страниц записи базы данных не имеют URL, то этот атрибут формируется искусственно по следующим правилам.

К имени или IP-адресу хоста, на котором находится SQL-сервер (задается ключом HostName - см. ниже) прибавляются значения полей, указанных в операторе SELECT (ключ UrlQuery), разделенные символом '/' (слеш). В результате этого получается уникальный идентификатор записи в стиле адресов Web, по которому ее однозначно можно определить (вот почему список значений, полученный в результате запроса в UrlQuery, должен состоять из неповторяющихся данных).

Например, ключам:

  HostName localhost
  UrlQuery SELECT id,ch_id,name FROM programs

  localhost/00000011/000000123/myprog

Для ускорения индексации все числовые поля при генерации URL'a расширяются слева нулями до максимальной ширины поля.

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

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

• если по каким-либо причинам воспользоваться первым способом индексации не удается, то можно организовать обход SQL-базы роботом в произвольном порядке. При этом курсор текущей записи будет перемещаться по базе произвольно, и необходимость в сортировке отпадает. Индексатор переходит в данный режим работы, если встречает в SQL-запросе ключ UrlQuery символ '('

    UrlQuery  SELECT concat(id,'/',ch_id,'/',name) FROM programs

Разница в производительности между оптимальным и неоптимальным способами индексирования на маленьких и средних сайтах будет незаметна, но на серверах, содержащих объемные базы данных, с подобными нюансами приходится считаться.

В процессе индексации значения полей оператора SELECT заносятся в переменные вида $n, где n - порядковый номер поля в операторе SELECT ключа UrlQuery начиная с 1:

  localhost/00000011/000000123/myprog
             $1         $2       $3

Для данного примера значение поля id будет содержаться в переменной $1, значение поля ch_id в переменной $2, а значение поля name в переменной $3.

Эти переменные можно свободно использовать при подготовке SQL-запроса для ключа DocQuery. Отсюда выражение id=$1, встретившееся ранее, означает, что у SQL-сервера будут запрошены записи с полем id, равным текущему значению переменной $1.

5.6.1.3. Механизм взаимодействия Яndex.Server 3.4 с SQL-сервером

Обобщим все вышесказанное и кратко опишем ключевые моменты механизма взаимодействия Яndex.Server 3.4 с SQL-сервером:

• индексация информации из базы данных организуется при помощи двух SQL-запросов, определенных в ключах UrlQuery и DocQuery. Используя ключ UrlQuery, индексатор имеет возможность получить список всех записей, подлежащих индексации, а используя DocQuery - конкретную запись из этого списка.

• Ключ DocQuery оформляется таким образом, чтобы возвращать данные в одном из стандартных форматов. Это необязательно должен быть HTML-документ, как в рассмотренных ранее примерах. Данные допустимо оформить в виде text/plain или можно использовать любой другой формат, известный индексатору (подробнее см. ниже).

• Индексатор получает информацию и обрабатывает ее обычным образом. В качестве ссылки на исходный документ в индексный файл записывается искусственный URL.

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

• В качестве средств для доступа к SQL-серверу и выдачи найденного документа могут быть использованы как скрипты, написанные администратором Яndex.Server 3.4, так и сам поисковый сервер, настроенный соответствующим образом:

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

  Пример.

  Для выдачи найденного документа используется CGI-скрипт message. Допустим, ключи HostName и UrlQuery для вашей базы выглядят следующим образом:

    HostName localhost
    UrlQuery SELECT id,name FROM programs

  тогда в настройках поискового сервера должна быть следующая запись:

    Redirect http://www.myhost.ru/cgi-bin/message?

  В этом случае URL для записи с id=1 и name=user1 на странице результатов поиска будет выглядеть следующим образом:

    http://www.myhost.ru/cgi-bin/message?/0001/user1

  Это значит, что при использовании своего CGI-скрипта для выдачи искомого документа он в качестве параметров получит строку /0001/user1, которую необходимо обработать и на ее основе сформировать корректный SQL-запрос к базе.

  Для тех случаев, когда работать со строкой /0001/user1 не очень удобно, существует альтернативный вариант задания ключа Redirect - с использованием переменных $n. Если ключ имеет вид:

    Redirect http://www.myhost.ru/cgi-bin/message?id=$1&name=$2

  будет сформирован так:

    http://www.myhost.ru/cgi-bin/message?id=0001&name=user1

  и скрипт message получит строку параметров стандартного для CGI формата. С данными в таком виде гораздо проще работать, особенно если приходится адаптировать уже существующие процедуры под новые возможности Яndex.Server 3.4.

• Эти изменения позволяют задействовать внутренние механизмы Яndex.Server 3.4, обычно используемые для получения подсвеченных документов. В результате поисковик будет сам формировать необходимые SQL-запросы к базе, получать требуемые данные и, пользуясь содержимым ключа DocQuery как шаблоном, генерировать результирующие документы.

5.6.1.4. Пример файла конфигурации для индексирования и поиска по MySQL-базе.

Содержимое файла mysql_datasrc.cfg может быть таким:

  KeepAlive   yes
  HostName    localhost
  BaseName    mydb
  User        search_user
  Password    search_user_pass
  UrlQuery    SELECT id,ch_id FROM programs
  DocQuery    SELECT concat( \
                    'Content-Type: text/html\n',\
                    'Last-Modified: ',UNIX_TIMESTAMP(m_time),'\n\n',\
                    '<HTML><HEAD>',\
                    '<TITLE>',user,'</TITLE>',\
                    '<META NAME="Description" Content="',pr_name,' ',pr_descr,'">',\
                    '</HEAD>\n',\
                    '<BODY>\n',content,'\n</BODY></HTML>'\
                    ) FROM programs WHERE id=$1
  ! где UNIX_TIMESTAMP(m_time) - время модификации записи в секундах;
  !     user, pr_name, pr_descr, content - индексируемые поля SQL-базы,
  !     из которых генерируется html-документ.

В данном примере для каждой записи MySQL-базы генерируется HTML-документ. Это видно по содержимому ключа DocQuery. В нем определен медиа тип text/html. Кроме того, обратите внимание на то, что для получения списка индексируемых записей в UrlQuery используется два поля базы данных (id и ch_id), а для формирования результирующего документа задействовано лишь одно из них (id=$1). На первый взгляд кажется, что второй параметр здесь лишний. И в данном случае это действительно так.

Однако часто встречаются ситуации, в которых без дополнительной информации из SQL-базы не обойтись. Например, на вашем сайте размещена программа телепередач, и вы организовали поиск по ней. Для наглядности страницу с результатами поиска вы хотите оформить так, чтобы рядом с названием передачи выдавалась иконка канала, на котором она будет идти. Имя этой иконки очень удобно передавать через дополнительный параметр (в $2). Подобное возможно, т.к. переменные вида $n (в которые заносятся текущие значения полей ключа UrlQuery) можно использовать не только для формирования внешнего вида исходного документа (в ключе DocQuery), но и при подготовке дизайна страницы результатов поиска.

Ранее мы неоднократно упоминали, что результирующий документ не обязательно должен являться HTML-страницей. Данные из базы могут быть представлены в любом другом формате. Вот, например, как можно представить найденную информацию в текстовом виде (медиа-тип text/plain):

  DocQuery  SELECT concat( \
            'Content-Type: text/plain\n',\
            'Last-Modified: ',UNIX_TIMESTAMP(m_time),'\n\n',\
            content) FROM programs WHERE id=$1

Таким образом, внешним представлением поступающих от SQL-сервера данных вы можете свободно управлять.

5.6.1.5. Секция Dump

Конфигурационный файл источника данных может содержать необязательную секцию Dump, предназначенную для автоматического создания группировочных файлов c2n и c2p. Эта секция содержит несколько директив, по числу файлов, которые надо создать.

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

Например:

  Dump.channels.c2n  SELECT id,name FROM channels
  Dump.channels.c2p  SELECT id,region FROM channels

5.6.2.1. Конфигурационный файл индексатора

Индексирование баз данных через интерфейс OLEDB реализовано в Яndex.Server 3.4 посредством специального модуля связи с источником данных, который находится в файле oledb.dll. Поэтому для индексирования OLEDB-данных в конфигурационном файле индексатора надо задать хотя бы одну секцию следующего вида (см. раздел Секция DataSource).

  <DataSource>
      Name: mydata
      Module: oledb.dll
      Config: sqldb.cfg
  <DataSource>

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

5.6.2.2. Конфигурирование источника данных

Основная секция конфигурационного файла источника данных должна содержать следующие директивы.

5.6.2.3. Конфигурирование шаблона документа

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

5.6.2.4. Конфигурирование группировочных соответствий

Конфигурационный файл источника данных может содержать необязательную секцию Dump, предназначенную для автоматического создания группировочных файлов c2n и c2p (см. обсуждение в разделе Группировочные атрибуты). Эта секция содержит несколько директив, по числу файлов, которые надо создать.

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

Пример:

  cat.c2n = SELECT catid, category FROM categories/catid/category
  cat.c2p = SELECT catid, owner FROM categories/catid/owner

5.6.2.5. Индексирование книжного магазина

  bookid      ;идентификатор книги
  authorid    ;идентификатор автора
  catid       ;идентификатор темы
  title       ;название книги
  description ;краткое содержание

  authorid    ;идентификатор автора
  author      ;имя автора
  biograph    ;биография автора

  catid       ;идентификатор темы
  owner       ;идентификатор темы верхнего уровня из этой же таблицы
  category    ;название темы

  <DataSource>
      Name: books
      Module: oledb.dll
      Config: sqldb.cfg
      Options: IndexNofollow UrlCaseFold
  </DataSource>

  Groups: cat

  <DocFormat>
      MimeType: text/html
      Config:   html.cfg
  </DocFormat>

  provider = SQLOLEDB.1
  datasource = BOOKDB
  catalog = bookshop
  userid = *****
  password = *****
  
  <!-- автоматически создадим файлы для группировочного атрибута -->
  <Dump>
  cat.c2n = SELECT catid, category FROM categories/catid/category
  cat.c2p = SELECT catid, owner FROM categories/catid/owner
  </Dump>
  
  <!-- определим шаблон документов для индексирования, каждый документ соответствует одной книге -->
  <book>
  urlquery = SELECT bookid FROM books ORDER BY 1
  keyfields = bookid
  docquery = SELECT b.catid, b.title, b.description, a.author, c.category \
             FROM books b, authors a, categories c \
             WHERE b.catid = c.catid AND b.authorid = a.authorid AND b.bookid = $1
  indexfields = catid, title, description, author, category
  template = c:\yandexsite\book.htm
  </book>

  <HTML>
  <HEAD>
  <META NAME="catid" CONTENT="$1">
  </HEAD>
  <BODY>
  <H1>$2</H1>
  <H2>$4</H2>
  <H3>$5</H3>
  <P>$3</P>
  </BODY>
  </HTML>

  <Zones>
      title H1
      author H2
      category H3
      description P
  </Zones>
  <Attributes>
      cat INTEGER/meta.catid
  </Attributes>

  description[сказка] && author[Пушкин]

5.6.3.1. Конфигурационный файл индексатора

Индексирование баз данных через интерфейс ODBC реализовано в Яndex.Server 3.4 посредством специального модуля связи с источником данных, который находится в файле libydodbc.so. Поэтому для индексирования ODBC-данных в конфигурационном файле индексатора надо задать хотя бы одну секцию следующего вида (см. раздел Секция DataSource).

  <DataSource>
      Name    mydata
      Module  libydodbc.so
      Config  sqldb.cfg
  <DataSource>

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

5.6.3.2. Конфигурирование источника данных

Основная секция конфигурационного файла источника данных должна содержать следующие директивы.

5.6.3.3. Конфигурирование группировочных соответствий

Конфигурационный файл источника данных может содержать необязательную секцию Dump, предназначенную для автоматического создания группировочных файлов c2n и c2p (см. обсуждение в разделе Группировочные атрибуты). Эта секция содержит несколько директив, по числу файлов, которые надо создать.

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

Пример:

  cat.c2n = SELECT catid, category FROM categories
  cat.c2p = SELECT catid, owner FROM categories

5.6.3.4. Пример файла конфигурации для индексирования и поиска по MySQL-базе с использованием драйвера MyODBC.

В конфигурационном файле индексатора задаем секцию DataSource следующего вида (см. раздел Секция DataSource).

  <DataSource>
      Name    mysql_datasrc
      Module  libydodbc.so
      Config  mysql_datasrc.cfg
  <DataSource>

Содержимое файла mysql_datasrc.cfg может быть таким:

  KeepAlive      yes
  DataSourceName MySQL
  BaseName       mydb
  User           search_user
  Password       search_user_pass
  UrlQuery       SELECT id,ch_id FROM programs
  DocQuery       SELECT pr_name, pr_descr, content, m_time FROM programs WHERE id=$1
  TimeStamp      m_time
  Template       doc.template
  MimeType       text/html

Файл doc.template шаблона документа имеет следующий вид.

  <HTML>
  <HEAD>
  <META NAME="pr_name" CONTENT="$1">
  <META NAME="Description" Content="$2">
  </HEAD>
  <BODY>
  <H1>$3</H1>
  </BODY>
  </HTML>