# Способ хранения Cache
DataparkSearch - Полнофункциональная поисковая машина для Интернета и Интранета с открытым исходным кодом. Распространяется по лицензии GNU.
Keywords: shareware, freeware, интернет, unix, поисковик, поисковая машина, поиск, поиск информации, интранет, open source, opensource, search, searching, software, udmsearch, engine, indexing, system, web, ftp, http, cgi, php, SQL, MySQL, database, php3, FreeBSD, Linux, Unix, DataparkSearch, MacOS X, Mac OS X, Windows, 2000, NT, 95, 98, GNU, GPL, url, grabbing

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