Индексация и актуализация словаря БД

НАЧАЛО >> Руководство пользователя >> Индексация и актуализация словаря БД📄 Скачать в DOCX

Операции индексации доступны из карточки базы данных через кнопку Управление БД... в меню Индекс. Они предназначены для обслуживания словаря и инвертированного файла БД ИРБИС и выполняются через очередь задач, чтобы длительная операция не блокировала веб-интерфейс.

1. Создание словаря заново

Кнопка Создать словарь заново полностью запускает задачу Database/RecreateIndex. Операция пересоздает словарь выбранной БД и может занимать значительное время на больших базах.

Кнопка Создать заново каталожную часть словаря запускает задачу Database/RecreateIndexCatalog. Для провайдера DP_Irbis64Native она выполняет потоковую цепочку terms -> sort -> loaddict и соответствует режиму irbistool dict -c, то есть пересоздает только каталожную часть словаря.

Текущие ограничения Database/RecreateIndexCatalog:

режим FTOnly и обработка embedded fulltext БД еще не реализованы;
операция использует внутренний рабочий каталог ИРБИС 128 и не принимает произвольный путь к временным файлам;
результатом является отчет фоновой задачи с количеством строк терминов, строк сортировки, временем стадий и диагностикой ошибок;
отсутствие входных файлов промежуточных стадий считается ошибкой операции, даже если соответствующая отдельная команда irbistool возвращает exit code 0 и сообщает об ошибке только в stdout.

2. Отдельные стадии `terms`, `sort` и `loaddict`

Меню Индекс также содержит отдельные операции:

Сформировать термины каталожной части... - запускает Database/IndexTermsCatalog, аналог стадии irbistool terms -c;
Сформировать термины каталожной части параллельно... - запускает Database/IndexTermsCatalogParallel, Queue-прототип для параллельной read-only/map стадии terms -c;
Объединить части терминов каталожной части... - запускает Database/MergeIndexTermsCatalog и готовит единый рабочий каталог для сортировки после параллельной стадии;
Отсортировать термины каталожной части... - запускает Database/SortIndexTermsCatalog, аналог стадии irbistool sort -c;
Загрузить каталожную часть словаря... - запускает Database/LoadIndexTermsCatalog, аналог стадии irbistool loaddict -c.

Эти команды предназначены для диагностики, поэтапной проверки и восстановления индекса. Для обычной полной перестройки каталожной части словаря используйте Создать заново каталожную часть словаря: она выполняет все три стадии подряд.

При запуске отдельной стадии администратор указывает Идентификатор рабочего каталога. Для одной цепочки terms -> sort -> loaddict нужно использовать один и тот же идентификатор. ИРБИС 128 сам строит безопасный серверный путь рабочего каталога внутри области irbistool-index; произвольный путь к .ln1, .lk1 или другому серверному файлу из интерфейса не принимается.

Стадия terms создает chunk-файлы терминов и terms.manifest.json. Стадия sort требует результат terms в том же рабочем каталоге и создает terms-sorted.jsonl и sort.manifest.json. Стадия loaddict требует terms-sorted.jsonl, записывает новые индексные файлы и создает loaddict.manifest.json.

Очередь показывает прогресс стадий: terms обновляет состояние по проходу MFN, sort - по строкам сортируемого потока, loaddict - по строкам отсортированных терминов при загрузке словаря и по фактической записи индексных файлов N01/L01/IFP. Для полной операции Database/RecreateIndexCatalog прогресс агрегируется по стадиям terms -> sort -> loaddict.

Параллельная стадия Database/IndexTermsCatalogParallel делит диапазон MFN на несколько независимых child-задач Database/IndexTermsCatalog. Каждая child-задача только читает записи и пишет собственный рабочий каталог с terms.manifest.json и terms-*.jsonl; запись в N01, L01 и IFP не выполняется. Это безопасный прототип для больших БД, где подготовку терминов можно распараллелить без одновременной записи в один индекс.

После параллельного формирования нужно запустить Объединить части терминов каталожной части... с тем же идентификатором рабочего каталога. Эта стадия находит каталоги вида IndexRunId-part-*, копирует chunk-файлы в целевой каталог IndexRunId и создает единый terms.manifest.json. После этого обычная стадия Отсортировать термины каталожной части... работает с тем же IndexRunId.

Текущие ограничения параллельной стадии:

объединение частей создает дополнительную последовательную стадию копирования chunk-файлов;
стадия loaddict остается единственной критической стадией записи; базовый self-test проверяет восстановление файлов индекса, но не заменяет production-схему commit/rollback;
для запуска нужно не менее двух worker-потоков очереди (Queue MaxStarted >= 2);
на малых диапазонах накладные расходы Queue могут быть больше выигрыша от параллельного чтения.

Отсутствие входных файлов для sort или loaddict считается ошибкой операции. Это сознательное отличие от некоторых режимов irbistool.exe, где ошибка входного stage-файла может быть напечатана в выводе при нулевом коде завершения.

Перед запуском loaddict на рабочей БД нужна проверенная резервная копия или snapshot БД. Минимально должны быть восстановимы индексные файлы N01, L01 и IFP; для регламентных работ предпочтительна полная копия БД, потому что индекс должен соответствовать текущим MST/XRF. Для проверки регламента используется tools/DP_Irbis64NativeLoadDictRestoreSelfTest.php: тест работает на копии БД, запускает loaddict, восстанавливает N01/L01/IFP из backup и выполняет diaglnk; это не заменяет резервное копирование рабочей БД.

Перед запуском рекомендуется:

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

3. Экспорт инвертированного файла

Кнопка Экспортировать инвертированный файл запускает задачу Database/ExportInvertedFile. Для провайдера DP_Irbis64Native она соответствует команде irbistool exportif: читает текущий инвертированный файл БД и формирует текстовый файл .lk1 во внутреннем рабочем каталоге ИРБИС 128.

Операция не принимает произвольный путь вывода из интерфейса. Рабочий каталог формируется сервером, а в отчете фоновой задачи фиксируются путь к созданному .lk1, количество экспортированных терминов, строк/postings, размер файла, время выполнения и расход памяти. Для БД формата 2018+ при наличии embedded fulltext БД дополнительно формируется файл полнотекстового экспорта.

При запуске через очередь операция передает progress callback в provider. Native-экспорт обновляет heartbeat на стадиях подсчета терминов и записи .lk1 отдельно для каталожного и полнотекстового инвертированного файла, чтобы длительная задача не выглядела зависшей на больших БД.

Отчет задачи экспорта хранится в очереди дольше обычного, чтобы администратор успел проверить размеры и время выполнения. Для скачивания .lk1 используется контролируемая страница Database/DownloadExportInvertedFile: она повторно проверяет права на БД и строит путь только по имени БД, идентификатору запуска и типу файла catalog или fulltext. Перед новым запуском Database/ExportInvertedFile очищает старые каталоги результата этой БД по лимитам CleanupRetentionDays и CleanupMaxRuns; текущий запуск, _uploads и каталоги с именами вне whitelist не удаляются.

4. Актуализация словаря

Кнопка Актуализировать словарь открывает окно параметров и запускает задачу Database/RecIfUpdateAll. Для БД с провайдером DP_Irbis64Native эта операция использует метод ActualizeDatabase и соответствует сценарию irbistool actualif.

Рисунок 1 - Окно параметров актуализации словаря

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

Если параметры не заполнены, выполняется полный проход по БД: актуализируются записи, у которых установлены признаки неактуальности словаря или полнотекстовых данных.

Если указан диапазон или список MFN, выбранные записи актуализируются явно. Это повторяет поведение irbistool actualif для параметров -mf/-mt, -r и -l: запись может быть обработана даже тогда, когда до запуска она уже считалась актуальной.

При выполнении через очередь задача показывает прогресс по просмотренным MFN. Для больших БД это heartbeat длительного прохода: операция обрабатывает записи последовательно и не загружает MST/XRF, словарь или инвертированный файл целиком в память.

5. Параметры актуализации

Параметр	Назначение
Первый MFN	Начало диапазона записей. Аналог нижней границы `-mf` или начала диапазона `-r` в `irbistool actualif`.
Последний MFN	Конец диапазона записей. Если задан только первый MFN, обрабатывается одна запись.
Список MFN	Явный список номеров записей. Значения можно разделять пробелами, запятыми, точками с запятой или переводами строк.

Если одновременно указан список MFN и диапазон, приоритет имеет список MFN.

Поле Список MFN является безопасным интерфейсным аналогом содержимого файла для irbistool actualif -l: администратор передает сами номера MFN, а не путь к файлу на сервере. Это исключает запуск операции с произвольным серверным путем. Для очень больших списков MFN нужен отдельный безопасный upload, который сохранит загруженный файл во временную область и не позволит указать произвольный путь файловой системы.

6. Выполнение и контроль результата

После запуска задача появляется в очереди и открывается окно мониторинга. Для оценки длительности операции нужно учитывать полное время до завершения задачи, а не только время постановки задачи в очередь.

После завершения рекомендуется проверить:

статус задачи в очереди;
сообщения об ошибках;
доступность БД;
контрольные записи, которые входили в диапазон или список MFN;
состояние словаря по контрольным терминам или штатной диагностикой индекса.

7. Ограничения и безопасность

Операции индексации могут менять индексные файлы и служебные признаки записей. Не запускайте их на рабочей БД без понимания объема операции и способа восстановления.

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

Загрузка списка MFN из файла в интерфейсе не должна использовать прямой путь к файлу на сервере. Если требуется обработать большой список, нужен специально реализованный upload, который не позволяет администратору передать произвольный путь файловой системы сервера.