DataparkSearch 4.26 Руководство: Поисковая машина
Пред. | Глава 5. Хранение данных | След.

# К вопросу производительности DataparkSearch

Способ хранения cache - самый быстрый в DataparkSearch. Используйте его, если хотите получить максимальную скорость поиска.

## Рекомендация использовать searchd

Если вы планируете использовать синонимы, стоп-слова или данные ispell, рекомендуется воспользоваться демоном searchd (См. Разд. Поддержка SearchD ). Демон searchd при запуске загружает эти данные и держит их в памяти. Это позволяет сократить среднее время выполнения запросов на поиск.

## Рекомендация использовать файловую систему в памяти (mfs)

Если вы планируете использовать cache mode и имеете достаточно оперативной памяти на вашем компьютере, вы можете разместить директорию `/usr/local/dpsearch/var` на файловой системе в памяти компьютера (mfs). Это ускорит как индексирование, так и поиск.

Если памяти недостаточно, что поместить в ней `/usr/local/dpsearch/var` целиком, вы можете разместить на mfs любую из директорий `/usr/local/dpsearch/var/tree`, `/usr/local/dpsearch/var/url` или `/usr/local/dpsearch/var/store`.

## Производительность MySQL

Пользователи MySQL могут задать опцию `DELAY_KEY_WRITE=1` для таблиц DataparkSearch. Это позволит быстрее обновлять индексы, т.к.они не будут записываться на диск пока файл не будет закрыт. `DELAY_KEY_WRITE` целиком исключает обновление индексов на диске.

С этой опцией индексы хранятся только в памяти и записываются на диск в последнюю очередь, по команду FLUSH TABLES или по завершению mysqld. Запись одновлённых индексов на диск может занимать минуты и нетерпеливые пользователи могут прибить сервер командой `kill -9` и этим разрушить индексные файлы. Другим неудобством является необходимость запуска `myisamchk` для этих таблиц перед стартом mysqld для проверки, на случай, если `mysqld` был убит до этого.

По этим причинам мы не включили эту опцию в структуру наших таблиц по умолчанию. Т.к. вся информация в индексах может быть восстановлена из данных, находящихся в таблицах, вы не потеряете данные, используя опцию `DELAY_KEY_WRITE`. Но используйте её на свой страх и риск.

## Оптимизация после индексирования

Этот раздел был добавлен Randy Winch `<gumby@cafes.net>`

У меня есть мысля о производителности, которая может заинтересовать некоторых из вас. Я использую `RH 6.2` с обновлением ядра `2.2.14-6.1.1` (поддерживает файлы свыше 2 гигабайт) и `mysql 2.23.18-alpha`. Я проиндексировал весь наш сайт используя mnoGoSearch 3.0.18:

              mnoGoSearch statistics

        Status    Expired      Total
       -----------------------------
           200     821178    2052579 OK
           301        797      29891 Moved Permanently
           302          3          3 Moved Temporarily
           304          0          7 Not Modified
           400          0         99 Bad Request
           403          0          7 Forbidden
           404      30690     100115 Not found
           500          0          1 Internal Server Error
           503          0          1 Service Unavailable
       -----------------------------
         Total     852668    2182703

Я оптимизировал данные, выгрузив их в файл используя `SELECT * INTO OUTFILE`, отсортировал их при помощи системной процедуры сортировки по полю `word (CRC)` и затем загрузил их обратно в базу данных, используя процедуру, описанную в mysql online manual.

Производительность великолепна. Мой любимый тест - поиск "John Smith". Оптимизированная база показала результат в 13 секунд. База до оптимизации показывала примерно 73 секунды.

    Search results: john : 620241 smith : 177096
    Displaying documents 1-20 of total 128656 found

Пред. | Начало | След.
Способ хранения Cache | Уровень выше | Поддержка SearchD