DataparkSearch Engine 4.53: Справочное руководство
Пред. | Глава 5. Хранение данных | След.

# 5.2. Способ хранения Cache

## 5.2.1. Введение

В DataparkSearch реализован способ хранения `cache`, позволяющий быстро индексировать и искать среди миллионов документов.

## 5.2.2. Структура индексов слов при способе хранения `Cache`

Основная идея способа хранения слов cache заключается в хранении индекса слов и вспомогательной информации о документах непосредственно на диске, а не в SQL базе данных. Вся информация об URL (таблицы `url` и `urlinfo`) тем не менее продолжает храниться в SQL базе данных. Индекс слов разделён на несколько файлов, число которых может быть задано при помощи команды WrdFiles (по умолчанию - 0x300). Число файлов хранения дополнительной информации о документах задаётся командой URLDataFiles (по умолчанию - 0x300).

> Внимание: вы должны иметь одаковые значения для WrdFilesи URLDataFilesво всех файлах конфигурации.

Индекс слов находится в файлах, расположенных в поддиректории `/var/tree` относительно корневой директории установки DataparkSearch. Вспомогательная информация о документах храниится в файлах, расположенных в поддиректории `/var/url` относительно корневой директории установки DataparkSearch.

## 5.2.3. Утилиты для способа хранения `Cache`

При выборе способа хранения `cache` используютсся две дополнительные программы: cached и splitter.

cached - демон, получающий по сети информацию о хранимых словах от indexer и записывает её на ваш жёсткий диск. Этот демон может работать в двух режимах, как старый демон cachelogd, входивший в предыдущие версии и только записывающий получаемую информацию на диск, и в новом режиме, в котором объединены функции cachelogd и splitter.

splitter - программа создания индексов слов для быстрого поиска на основе записей, сделаных cached при работе в старом режиме. Эти индексы слов и используются в дальнейшем при обработке запросов на поиск.

## 5.2.4. Запуск способа хранения `cache`

Для запуска режима хранения `cache` проделайте следующее:

1. Запустите демон cached:

   `cd /usr/local/dpsearch/sbin`

   `./cached 2>cached.out &`

   Он будет писать некоторую отладочную информацию в файл `cached.out`. `cached` также создаст файл `cached.pid` в поддиректории `/var` относительно корневой директории установки DataparkSearch.

   `cached` может принимать соединения по TCP от нескольких различных машин. Теоритический предел одновременных соединений равен 128. В старом режиме `cached` записывает полученную от indexer информацию поддиректорию `/var/splitter/` относительно корневой директории установки DataparkSearch. В новом режиме он записывает информацию в поддиректорию `/var/tree/`.

   По умолчанию, `cached` запускается в новом режиме. Для запуска в старом режиме, т.е. только для получения и сохранения на диске информации, получаемой от indexer, запустите его с ключом `-l`.

   `cached -l`

   Или укажите команду LogsOnly yes в вашем `cached.conf`.

   Вы можете указать другой порт для `cached` без перекомпиляции. Для этого хапустите

   `./cached -p8000`

   где `8000` - номер порта по вашему выбору.

   Вы также можете указать другую директорию для записи информации (по умолчанию это поддиректория `/var`) выдав такую команду:

   `./cached -w /path/to/var/dir`

2. Сконфигурируйте `indexer.conf` как обычно, указав `cache` в качестве параметра dbmode команды DBAddr и `localhost:7000` в качестве параметра cached (см. Разд. 3.10.2>).

3. Запустите один или несколько indexer. Несколько indexer могут быть запущены одновременно. Вы можете запускать indexer с различных машин, но работающих с одним сервером `cached`. Это позволяет проводить ускоренное распределенное индексирование.

4. Сброс буферов cached и данных об url, а также создание лимитов по завершении процесса индексирования. Пошлите сигнал -HUP для `cached`. Вы можете использовать файл `cached.pid` для этого:

   `kill -HUP `cat /usr/local/dpsearch/var/cached.pid``

   Дождитесь окончания сброса буферов, прежде чем переходить к следующему шагу.

5. Создание индекса слов. Этот шаг не требуется, если `cached` запущен в новом, объединённом, режиме. Когда соберётся достаточное количество информации в поддиреткории `/var/splitter/`, можно создать индексы для быстрого поиска слов.Программа `splitter` предназначена для этого. Она устанавливается в поддиректорию `/sbin`. Индексы для поиска слов могут создаваться в любое время без остановки процесса индексирования.

   Создание индекса слов. Запустите `splitter` без каких либо ключей: `/usr/local/dpsearch/sbin/splitter`

   Он последовательно обработает все файлы из поддиректории `/var/splitter/` строя на их основе индекс слов для быстрого поиска. После этой обработки файлы в поддиректории `/var/splitter/` усекаются.

## 5.2.5. Использование нескольких splitter одновременно

splitter имеет два ключа: `-f [first file] -t [second file]`, задающих границы обрабатываемых файлов. Если эти параметры не указаны, splitter последовательно обрабатывает все приготовленные файлы. Вы можете ограничить обрабатываемое количество задав ключами -f и -t параметры в HEX нотации. Например, splitter -f 000 -t A00 создаст индекс слов только из фалёлов с диапазона с 000 по A00. Используя эти ключи можно запускать одновременно несколько splitter. Что обычно позволяет ускорить создание общего индекса. Например, этот шеловский скрипт запускает в фоне четыре splitter:

    #!/bin/sh
    splitter -f 000 -t 3f0 &
    splitter -f 400 -t 7f0 &
    splitter -f 800 -t bf0 &
    splitter -f c00 -t ff0 &

## 5.2.6. Использование скрипта run-splitter

В поддиректории `/sbin` находится скрипт `run-splitter`. Он помогает последовательно выполнить все шаги по построению индекса слов для быстрого поиска.

run-splitter имеет два параметра командной строки:

`run-splitter --hup --split`

или в короткой форме:

`run-splitter -k -s`

Каждый параметр запускает соответсвующий шаг создания индекса слов. `run-splitter` выполняет все шаги созданяи индекса в правильной последовательности:

1. Посылка сигнала -HUP к cached. Этому соответствует парамет `--hup` (или `-k`).

2. Запуск splitter. Этому соответсвует параметр `--split` (или `-s`).

В большинстве случаев достаточно просто запустить скрипт run-splitter со всеми параметрами `-k -s`. Раздельное использование этих параметров редко необходимо.

run-splitter имеет необязательные параметры `-p=n` и `-v=m` для задания соответсвенно паузы в секунда после обработки каждого буффера и указания выдачи сообщений. `n` - число секунд (по умолчанию 0), `m` - уровень выдачи (по умолчанию 4).

## 5.2.7. Поиск

Для использования search.cgi со способом хранения "cache", сконфигурируйте ваш шаблон `search.htm` как обычно, добавив "cache" в качестве значения параметра `dbmode` команды DBAddr

## 5.2.8. Использование лимитов при поиске

Для применения лимитов при поиске с использование способа хранения cache, необходимо добавить соответсвующие команды Limit в ваши `indexer.conf` (или `cached.conf`, если используется cached) и `search.htm` или `searchd.conf` (если используется searchd).

    Limit prm:type [SQL-Request [DBAddr]]

Для использования, например, лимитов по тэгу, категории и сайту, добавьте следующие строки в ваши файлы конфигурации:

    Limit t:tag
    Limit c:catategory
    Limit site:siteid

где `t` - имя CGI параметра (&t=) этого ограничения, `tag` - тип ограничения.

Вместо tag/category/siteid в примере выше вы можете использовать значения из следующей таблицы:

Таблица 5-1. Типы предопределенных лимитов способа хранения Cache

category | Лимит по категории.
tag | Лимит по тэгу.
time | Лимит по времени (с точностью до часа).
language | Лимит по языку.
content | Лимит по MIME-типу.
siteid | Лимит по url.site_id (по имени сервера).
link | Лимит по документам, ссылающимся на указаный url.rec_id.
hostname (устаревшее) | Лимит по имени сервера. Это устаревшая команда, вытесненная лимитом по site_id

Если для команды Limit указан второй, необязательный, параметр `SQL-Request`, то при построении индекса будет выполнятся заданный запрос к SQL-базе. Этот запрос должен возращать все возможные пары значение лимита и соответсвующее ему значение url.rec_id. Например:

    Limit prm:strcrc32 "SELECT label, rec_id FROM labels" pgsql://u:p@localhost/sitedb/

здесь prm - имя лимита и имя CGI-параметра, используемого для задания ограничения по этому лимиту; strcrc32 - тип используемого лимита, в данном случа - строка. Вместо strcrc32 возможно использовать следующие типы:

Таблица 5-2. Типы SQL-лимитов способа хранения Cache

hex8str | Шестнадцатеричная строка, или строка в base-26, аналогичная используемым в лимите по категории. В этом случае строится вложенный лимит.
strcrc32 | Строка символов, по которой расчитывается значение hash32, служащее ключом этого лимита.
int | Целое (4-байтовое) число.

Третьим, необязательным, пораметром `DBAddr` для команды Limit можно указать соединение к SQL-базе, отличной от базы, используемой для поиска.

В поисковом шаблоне `search.htm` или в файле конфигурации `searchd.conf` (если используется searchd) указывать необязательные параметры `SQL-Request` и `DBAddr` нужно, они используются только при построении лимита.

    Limit prm:strcrc32

Пред. | Начало | След.
Хранение данных | Уровень выше | К вопросу производительности DataparkSearch