Актуализация и обратный индекс

НАЧАЛО >> Нативный провайдер данных DP_Irbis64Native >> Актуализация и обратный индекс📄 Скачать в DOCX

Обратный индекс связывает поисковые термины с MFN записей. DP_Irbis64Native поддерживает чтение существующего индекса и операции его обновления средствами PHP.

1. Когда нужна актуализация

Актуализация требуется после операций, которые меняют содержимое записей:

Если индекс не актуализирован, поиск и словарь могут не соответствовать фактическому содержимому MST.

2. Актуализация записи

При актуализации одной записи провайдер:

  1. читает текущую версию записи;
  2. получает набор терминов по FST;
  3. сравнивает новый набор с прежним состоянием;
  4. обновляет словарь;
  5. записывает postings в IFP;
  6. снимает признак неактуальности.

Функции RecIfUpdate, RecIfUpdateAll и ActualizeRecord используются для точечного или пакетного приведения индекса в актуальное состояние.

3. Пересоздание индекса

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

Пересоздание индекса должно выполняться в административном окне обслуживания, когда с базой не работают пользователи. Операция читает много записей, меняет словарь и IFP, поэтому требует резервной копии и контроля свободного места.

4. FST и инвертор

Индексирование выполняется по FST. Инвертор читает правила, извлекает термины из полей записи и передает их в слой работы со словарем. Если FST содержит ошибку, провайдер может прочитать запись, но не сможет корректно построить поисковые термины.

4.1. Метод индексирования IT=5

При актуализации карточек DP_Irbis64Native не формирует служебное значение "число слов в предложении" в пятом поле posting-а (nBook, IrbisPosting(..., 5)). Правила FST с методом индексирования IT=5 пропускаются инвертором и не создают новые термины.

Причина ограничения связана с производительностью актуализации: для карточки записи нет надежного разбиения на предложения, поэтому вся карточка фактически считается одним предложением. При любом изменении количества слов менялось бы значение пятого поля posting-а, и индексатор был бы вынужден удалить старые ссылки записи и заново записать новые даже тогда, когда набор поисковых терминов не изменился.

Это не отменяет обычную пословную индексацию и индексирование с префиксами по другим методам FST. При анализе postings стандартного индекса нужно использовать стабильные поля mfn, tag, occ и cnt; поле nBook для актуализируемых карточек не является пользовательским поисковым признаком.

При изменении FST нужно понимать, какие записи должны быть переиндексированы:

5. Согласованность файлов

Словарь и обратный индекс состоят из нескольких связанных файлов. Для основного словаря это N01, L01 и IFP: N01 хранит верхние уровни дерева терминов, L01 - листовые блоки с самими терминами, IFP - postings, то есть ссылки терминов на записи. Файлы N02 и L02 являются второй парой индексных и листовых файлов того же типа. Они не заменяют N01/L01, а описывают дополнительное словарное пространство, путь к которому также хранится в .par.

Изменение только одного файла из связанной группы может привести к потере терминов, неверным postings или ошибкам поиска. Поэтому операции актуализации должны выполняться только средствами провайдера или штатными инструментами ИРБИС64. Если обслуживается полнотекстовое пространство --TEXT, его словарь нужно рассматривать как отдельный набор файлов: состояние обычного словаря базы и состояние полнотекстового словаря могут расходиться.