НАЧАЛО >> Нативный провайдер данных DP_Irbis64Native >> Поиск и словарь📄 Скачать в DOCX
Поиск в DP_Irbis64Native основан на словаре и обратном индексе ИРБИС64. Провайдер читает термины из файлов словаря, получает postings из IFP и формирует список MFN для прикладных модулей.
Функции Search, SearchSrv, SearchMfn и RecSearch принимают поисковое выражение, разбирают его и получают список найденных MFN. Для прикладного пользователя это выглядит как обычный поиск ИРБИС 128, а на уровне провайдера выполняются операции со словарем и postings.
Типовой порядок:
Для выражений X (G) Y и X (F) Y без tag-квалификаторов провайдер использует compact-путь: результат формируется как BitList MFN, а полный массив postings не сохраняется в памяти. Это важно для широких термов и усечений, например K=$ (G) T=$. Если выражение состоит из цепочки простых (G)/(F) пар, каждая пара считается compact-путем, а итоговые MFN пересекаются как BitList.
Для широких пустых ./near-выражений с маской или усечением выполняется безопасная предварительная проверка глобального пересечения tag/occ. Если пересечения нет, результат заведомо пустой и provider не строит полный postings-набор.
Для непустых ./near-выражений без tag-квалификаторов provider использует несколько специальных путей. Если один термин широкий, а второй точный, postings точного терма держатся как малая координатная карта, а широкий термин читается потоково. Если оба терма широкие или выражение является цепочкой нескольких ./near-пар, postings раскладываются во временные bucket-файлы по MFN и сравниваются bucket за bucket. Такой путь сохраняет потоковую модель для больших БД: в память не загружается весь IFP, весь словарь или полный postings-набор широкого выражения.
Цепочки ./near обрабатываются как multi-term выражение, а не как последняя пара. Для . результат требует одинакового mfn/tag/occ и последовательных позиций с учетом индекса термина; для near результат требует общего окна близости внутри одного mfn/tag/occ. Это соответствует внутренней логике TrmPostCashProc в исходниках irbistool. Если исполняемый irbistool.exe возвращает пустой или схлопнутый результат для broad-chain выражения, такое поведение считается дефектом утилиты и не переносится в provider.
Если вызов передает ProgressCallback, поиск периодически отправляет heartbeat activity во время обхода широких словарных термов. Это нужно для фоновых операций вроде Database/ExportRecords: стадия поиска может быть заметной сама по себе, даже если итоговая выборка пустая. Если callback возвращает false, поиск прерывается и возвращает управляемую ошибку отмены.
Для просмотра словаря используются:
GetTermList - получает список терминов от заданной позиции;FindTerm - ищет конкретный термин;NextTerm и PrevTerm - переходят к соседним терминам;GetPostingList - возвращает postings для термина;GetMfnPostingList - возвращает список MFN по postings.Эти операции используются поисковыми страницами, автодополнением, фасетами и внутренними сервисами.
Каждая ссылка термина на запись хранит не только MFN, но и координаты термина внутри записи: метку поля, номер повторения и позицию. Метка поля (pTag) берется из первой колонки правила FST, по которому сформирован термин. Поэтому для поиска по важным полям нужно задавать в FST отдельные правила с осмысленными метками этих полей, а не собирать разные поля одним общим правилом.
Эта координата используется в контекстном поиске:
(G) оставляет совпадения, где термины находятся в одном поле;(F) оставляет совпадения в одном повторении поля;Для точечного ограничения термина по полям поддерживается уточнение последней частью термина: K=ИСТОРИЯ/200 или K=ИСТОРИЯ/200,210. Такое уточнение не меняет сам словарный термин, а фильтрует его postings по pTag. Если FST записала термин с общей служебной меткой, поиск не сможет отличить, из какого исходного поля был получен термин.
Функция GetFasets строит группировки по найденному набору записей. Для сортировки используются SortMfnByPref, SortMfnBySrw и SavePostingListForSort. Размер сортируемого результата ограничивается настройкой MAX_SORT_COUNT, чтобы длинные поисковые выдачи не приводили к чрезмерной нагрузке.
FreeSearch применяется для сценариев, где нужно искать не только по подготовленному поисковому выражению, но и по свободному тексту. Конкретный результат зависит от настроек индексации базы и доступных префиксов.
На объем операций влияют настройки:
MAX_POSTINGS_IN_PACKET - максимальный размер пакета postings;MAX_POSTINGS_IN_PACKET_WITH_FORMAT - размер пакета при поиске с форматированием;BlockSearch - режим блочного поиска;UpDownSearchResult - порядок обработки результата;MAXMFN - верхняя граница MFN.Если результат слишком большой, прикладной модуль должен выводить его постранично и не пытаться форматировать все записи сразу.
Поиск корректен только при согласованном обратном индексе. После сохранения, удаления, импорта или массовой корректировки база должна быть актуализирована. Если индекс не обновлен, запись может читаться по MFN, но отсутствовать в поисковой выдаче или оставаться в выдаче по старым терминам.