НАЧАЛО >> Нативный провайдер данных DP_Irbis64Native >> Формат файла .ifp (Словарь ИРБИС64 - Ссылки / Постинги)📄 Скачать в DOCX
Файл .ifp (Inverted File Postings) является неотъемлемой частью инвертированного файла (словаря) системы ИРБИС64. В нем хранятся списки ссылок (постингов) на документы базы данных для каждого термина, найденного в листовых узлах словаря (.l01). Ссылки содержат номер записи (MFN) и точные координаты расположения термина внутри неё.
Файл представляет собой набор сегментов переменной длины. Переход к первому сегменту конкретного термина осуществляется по абсолютному 64-битному смещению (указателю), которое считывается из массива ключей файла листовых узлов .l01. Если ссылок для термина слишком много и они не помещаются в один сегмент, они разбиваются на связанный список сегментов (цепочку).
Как и в других файлах словаря, все бинарные числовые значения в файле записываются на диск в формате Big-Endian (старший байт по меньшему адресу).
Каждый сегмент состоит из заголовка и следующего за ним массива структур с координатами ссылок. Размер сегмента динамически адаптируется под объем данных: для небольших списков он занимает минимум места (кратно количеству записей 4*N), а для огромных списков применяются блочные аллокации (по 4, 8, 16, 32 Кб для массивов постингов в 2048-32000, 32000-64000, 64000-128000 ссылок и более соответственно).
Заголовок предваряет каждый блок ссылок и занимает 20 байт.
| Поле | Тип | Размер | Описание |
|---|---|---|---|
nxt |
TInt64 (struct) |
8 байт | 64-битное число, записанное в виде двух 32-битных частей: на диске сначала располагается LowWord (младшие 4 байта), а затем HiWord (старшие 4 байта). Представляет собой абсолютное смещение (адрес) следующего сегмента ссылок для данного термина. Значение знаковое: отрицательные числа (в дополнительном коде) выступают как системные маркеры.• -1 (IFP_LAST_SEGMENT) — последний (или единственный) сегмент в цепочке;• -2 (IFP_MAXFILESIZE_BLOCK) — маркер максимального блока для обрезки пустого места;• -1001 (IFP_BLOCK_SPECIAL) — специальный маркер резервируемого блока. |
totp |
int |
4 байта | Общее количество ссылок (постингов) для термина по всем связанным сегментам. Отрицательные значения логически не применяются (всегда >= 0). |
segp |
int |
4 байта | Количество ссылок, хранящихся непосредственно в текущем сегменте. Отрицательные значения логически не применяются (всегда >= 0). |
segc |
int |
4 байта | Вместимость (емкость) текущего сегмента. Определяет максимальное количество ссылок, которое он может вместить до необходимости перевыделения. Отрицательные значения логически не применяются (всегда >= 0). |
Массив структур ссылок располагается следом за заголовком (в количестве, равном значению segp). Сама структура записи различается в зависимости от версии базы данных.
Каждая ссылка занимает 16 байт (TifpItemPosting_2017).
| Поле | Тип | Размер | Описание |
|---|---|---|---|
pmfn |
int |
4 байта | Номер записи в базе данных (MFN). Отрицательные значения не используются (всегда > 0). |
ptag |
int |
4 байта | Метка поля, указанная в FST-правиле, по которому сформирован термин. Отрицательные значения не используются (всегда >= 0). |
pocc |
int |
4 байта | Номер повторения результата в данных базы. Отрицательные значения не используются (всегда >= 0). |
pcnt |
int |
4 байта | Порядковый номер слова в тексте (согласно формату ТВП). Отрицательные значения не используются (всегда >= 0). |
В современных версиях каждая ссылка расширена и занимает 32 байта (TifpItemPosting). Это необходимо для поддержки глубокой навигации по структуре полного текста (с точностью до слов в конкретном предложении на странице), а также поддержки многотомников.
| Поле | Тип | Размер | Внутреннее имя / Значение для ЭК | Значение для Полнотекстовых БД |
|---|---|---|---|---|
pmfn |
int |
4 байта | pmfn (Номер записи в ЭК) |
Номер записи (MFN в ПБД) |
ptag |
int |
4 байта | ptag (Метка поля) |
Номер записи 1-й страницы текста |
pocc |
int |
4 байта | pocc (Номер повторения) |
Номер записи бибописания текста в ЭК |
pcnt |
int |
4 байта | pcnt (Номер слова по формату) |
Номер слова на странице |
nbook |
int |
4 байта | nbook (Том в многотомнике) |
Служебное поле posting-а. В классической полнотекстовой схеме могло использоваться как число слов в предложении, но при актуализации карточек DP_Irbis64Native это значение не формируется. |
npage |
int |
4 байта | npage (Номер страницы) |
Номер страницы |
nprop |
int |
4 байта | nprop (Номер предложения) |
Номер предложения |
nword |
int |
4 байта | nword (Слово в предложении) |
Номер слова в предложении |
(Примечание: Назначения полей для версий >= 2018 приведены в соответствии с документацией API полнотекстового поиска. В коде C++ их внутренние имена сохранены универсальными).
При собственной актуализации карточек DP_Irbis64Native не заполняет пятое поле posting-а (nbook) количеством слов в предложении и не создает термины по FST-правилам с методом IT=5. Для карточек нет устойчивого разбиения на предложения: вся запись может восприниматься как одно предложение, а изменение общего числа слов приводило бы к массовому удалению и повторной записи ссылок в IFP. Поэтому для стандартного индекса актуальными координатами остаются pmfn, ptag, pocc и pcnt, а расширенные поля используются только когда они уже присутствуют в совместимом полнотекстовом индексе.
ptagДля обычной базы ptag является координатой словарного термина. Инвертор заполняет его из первой колонки FST, а поиск затем использует это значение для контекстных операторов и ограничений по меткам полей.
Если пользовательский сценарий должен считать совпадения в одних полях более важными или отбирать совпадения только из отдельных полей, эти поля должны попадать в словарь с различимыми ptag. Например, термины из заглавия и ключевых слов лучше формировать разными строками FST с метками соответствующих полей. Если один формат собирает данные из нескольких полей, но FST-строка имеет одну общую метку, postings будут хранить только эту общую метку и поиск не сможет различить исходные поля.
То, какая именно структура ссылок (16 или 32 байта) используется в конкретном файле .ifp, физически не указывается в самом словаре. Эта информация берется из управляющей записи (заголовка Tcntmst) главного файла документов .mst.
При открытии базы данных считывается резервное поле заголовка mfcxx1 (смещение 24 байта от начала .mst). Младшие 16 бит этого поля (маска 0xFFFF) содержат версию формата:
16 — стандартный формат ИРБИС64 (структура 16 байт, TifpItemPosting_2017).64 — расширенный формат ИРБИС64+ (структура 32 байта, TifpItemPosting).В зависимости от считанной версии, ядро системы устанавливает внутренний флаг контекста базы данных (например, Is2018Plus) и в дальнейшем отсчитывает нужный размер шага при обходе массива ссылок в сегментах.
Размер структуры ссылок определяется строго индивидуально для каждой конкретной базы данных в момент ее открытия:
--text): Создаются механизмами ИРБИС64+ специально для полнотекстового индексирования. Их файл .mst всегда имеет версию 64, а файл словаря .ifp всегда использует расширенную 32-байтную структуру. Именно в ней хранятся координаты расположения слов внутри прикрепленных текстов (страница, предложение, слово).16 и использует стандартную 16-байтную структуру. Если база была создана с нуля в ИРБИС64+ или администратор выполнил преобразование базы в новый формат (версия в .mst стала 64), её .ifp файл также перестраивается на 32-байтную структуру. Однако при стандартной индексации (по правилам FST) механизмы извлечения тома или страницы отсутствуют. Поэтому в основных базах дополнительные 16 байт расширенной структуры (поля nbook, npage, nprop, nword) на практике заполняются нулями — этот формат применяется лишь для системной совместимости с версией базы 64.Поиск терминов в файле .ifp всегда начинается с прыжка по смещению из .l01 и затем выполняется последовательным чтением массива TifpItemPosting в рамках текущего сегмента. Если значение nxt указывает на наличие продолжения, система совершает переход по этому смещению для загрузки всех остальных ссылок для текущего термина.