Техника актуализации

Navigation:  TCP/IP Сервер БД ИРБИС64 > Структура файлов БД ИРБИС64 >

Техника актуализации

Previous pageReturn to chapter overviewNext page

В этом разделе:

Создание новых записей

Модификация существующих записей

Удаление записей

Механизмы актуализации записи

- Старый

- Новый

 

Создание новых записей

Новые записи всегда добавляются в конец файла документов с позиции, которая определяется размером файла документов. Присваиваемый номер записи файла документов выбирается из поля NXTMFN управляющей записи.

При добавлении записи NXTMFN возрастает на 1. Кроме того, создается новая ссылка на эту новую запись в файле перекрестных ссылок с флагами –

BIT_NEW_REC  + BIT_NOTACT_REC. STATUS новой записи в файле документов имеет значение BIT_LAST_REC.

Флаг BIT_NOTACT_REC указывает факт, что новая запись должна быть затем проинвертирована.

 

Модификация существующих записей

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

STATUS последней версии записи в файле документов имеет значение BIT_LAST_REC+ BIT_NOTACT_REC, STATUS старой версии записи в файле документов обновляется и становится равен BIT_ALL_ZERO (0)+ BIT_NOTACT_REC. Кроме того, создается новая ссылка на эту новую версию записи в файле перекрестных ссылок с флагом – BIT_NOTACT_REC. Ссылка назад в новой версии записи – поля MFB_LOW, MFB_HIGH - указывает на предыдущую версию записи (не зависимо от того, была ли старая версия записи проинвертирована).

Флаг BIT_NOTACT_REC указывает факт, что новая запись должна быть затем проинвертирована.

После проведения инвертирования записи в отличии от ISIS ссылка назад НЕ становится равной 0, чтобы сохранить возможность ОТКАТА.

Флаг BIT_NOTACT_REC удаляется из файла перекрестных ссылок и файла документов.

 

Удаление записей

Удаление записи рассматривается как модификация  со следующими дополнительными параметрами:

В файле XRF в XRF_FLAGS добавляется флаг BIT_LOG_DEL и BIT_NOTACT_REC (после удаления записи требуется ее инвертирование).

В файле MST в STATUS добавляется флаг BIT_LOG_DEL.

 

 

Механизмы актуализации записи

 

Создан новый механизм актуализации записи (корректировка словаря в соответствии с изменениями записи) - отличающийся от старого механизма большим быстродействием.

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

Чтобы объяснить суть нового механизма актуализации, необходимо напомнить схему старого механизма.

 

Схема старого механизма актуализации записи

Она состоит в следующем:

рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);

обе копии записи подвергаются обработке (в оперативной памяти) в соответствии с таблицей инвертирования данной БД (<имя_БД>.FST). Обработка состоит в том, что копии записи форматируются по КАЖДОЙ строке таблицы инвертирования (см. структуру FST) и в соответствии с методами инвертирования создаются списки терминов. В результате - формируются два списка терминов: один - связанный с предыдущей копией записи, другой - с последней копией;

два списка терминов (после сортировки) сравниваются. В результате: а) термины, являющиеся общими для обоих списков отбрасываются (не рассматриваются), б) термины, оставшиеся в списке последней копии (т.е. те термины, которые присутствовали в списке последней копии и отсутствовали в списке предыдущей копии) ДОБАВЛЯЮТСЯ в словарь БД, в) термины, оставшиеся в списке предыдущей копии (т.е. те термины, которые присутствовали в списке предыдущей копии и отсутствовали в списке последней копии) УДАЛЯЮТСЯ из словаря.

Нетрудно понять, что данный механизм имеет существенный недостаток, связанный с нечувствительностью к тому, КАКИЕ и СКОЛЬКО полей записи подвергались изменению (корректировке). Т.е. если изменялись все или большинство полей записи (или точнее – большинство тех полей, которые участвуют в инвертировании), этот механизм эффективен; если же изменялось одно или несколько полей (а именно это имеет место на практике при работе с библиографическими БД) - механизм малоэффективен. И уж совсем "впустую" он работает в тех случаях, когда изменялись только те поля, которые не участвуют в инвертировании (т.е. те, по которым не создаются словари).

 

Проиллюстрировать это можно на следующем примере.

 

Пример:

При корректировке записи изменялось только поле 910 (экземпляры). В этом случае форматирование последней и предыдущей копий записи по строкам таблицы инвертирования, не имеющим отношения к полю 910, заведомо бессмысленно, поскольку сформированные в результате этого термины окажутся общими для обоих списков и будут отброшены. Имеет смысл использовать только те строки таблицы инвертирования, которые имеют отношение к полю 910. Но этого не происходит - старый механизм "тупо" обрабатывает ВСЕ строки таблицы инвертирования и тратит время на ненужное форматирование.

 

Таким образом, идея нового механизма актуализации лежит как будто на поверхности: определять, какие поля в записи изменялись (сравнивая последнюю и предыдущую копии записи) и отбирать из таблицы инвертирования только те строки, которые имеют отношение к изменившимся полям.

(Все именно так - только надо сразу видеть и "обратную сторону", т.е. недостатки нового механизма: в случае изменения всех или большинства полей записи впустую уже будет тратиться время на сравнение копий и отбор строк из таблицы инвертирования.)

Процесс сравнения копий (с целью выявления изменившихся полей) - очевиден и его реализация не вызывает никаких проблем. А вот задача отбора строк таблицы инвертирования, имеющих отношение к изменившимся полям, более "хитрая".(И даже более того - в силу изощренности языка форматирования ИРБИС эта задача алгоритмически строго говоря вообще неразрешима. Вот пример - разумеется, чисто теоретический - строки таблицы FST, по которой нельзя определить, к какому полю она относится:

100 0 ....&uf('AV',f(val(v100),0,0),'#1').....

понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)

И тем не менее, для решения "хитрой" задачи предлагается следующее.

 

Схема нового механизма актуализации записи

Вводится новая структура - дополнительная по отношению к таблице инвертирования. Будем называть ее

ТАБЛИЦА АКТУАЛИЗАЦИИ - IFS (именно такое расширение предлагается для соответствующего файла).

Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).

 

Пример:

Схематичный пример строки таблицы инвертирования:

100 0 .....v100......v200......v300....

Ей будет соответствовать следующая строка таблицы актуализации:

100,100,200,300 0 .....v100......v200......v300....

 

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

Таким образом, новый механизм актуализации состоит в следующем:

сравниваются последняя и предыдущая копии записи - в результате определяются метки изменившихся полей;

из таблицы актуализации отбираются строки, имеющие отношение к изменившимся полям и на их основе формируется временная (создаваемая налету для конкретной записи) таблица инвертирования;

отрабатывает "старый" механизм актуализации на основе временной таблицы инвертирования.

 

Необходимо отметить, что по понятным причинам при актуализации (т.е. сохранении) НОВОЙ записи (у которой нет никаких предыдущих копий), а также при УДАЛЕНИИ и РАЗУДАЛЕНИИ записи будет применяться старый механизм актуализации.

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

 

 Внимание:

Т.е. если в структуре БД присутствует таблица актуализации (<имя_БД>.IFS) , будет применяться новый механизм актуализации, в противном случае - старый механизм.

 

(Необходимо сразу отметить, что при полном создании словаря используется ТОЛЬКО таблица инвертирования - <имя_БД>.FST - т.е. этот файл остается ОБЯЗАТЕЛЬНЫМ в структуре БД, в отличие от таблицы актуализации <имя_БД>.IFS, которая может отсутствовать).

Теперь о том, каким образом создавать таблицу актуализации. Разумеется, нет большой трагедии в том, чтобы создавать и корректировать ее вручную на основе таблицы инвертирования - ведь таблица инвертирования это фундамент БД и меняется она отнюдь не каждый день. И именно так придется поступать на первых этапах применения нового механизма актуализации (конечно же в дистрибутиве 2012.1 будут предлагаться таблицы актуализации для всех стандартные БД ИРБИС). В будущем (м.б. и до выхода версии 2012.1) будет предложен инструмент для формирования таблицы актуализации на основе таблицы инвертирования. Но при этом надо иметь в виду, что каким бы точным ни был этот инструмент (а абсолютно точным он быть не может по приведенным выше причинам), все равно будет требоваться ручная постредакутра таблицы актуализации.

 

«

Следствием введения нового механизма актуализации является изменение следующих серверных исполняемых модулей:

irbis64.dll

server_64.exe

irbisa.exe

GenPft64.exe

IrbisGblAdmin.exe

Web-шлюзы

Полнотекстовые модули (Irbis64_FullTextAdministrator.exe и Irbis64_FullTextReader.exe)

(и что самое "неприятное" - они становятся НЕСОВМЕСТИМЫМИ с аналогичными модулями версий ниже 2012.1)

 

Добавлена возможность блокировать БД на ввод на время выполнения поиска. Управляется с помощью параметра BlockSearch, который принимает значения:

0 – (по умолчанию) не блокировать;

1 - блокировать.

Данный параметр имеет смысл применять (т.е. устанавливать значение 1) в случае, если идет интенсивная одновременная актуализация записей ЭК.

 

Введен режим отложенной актуализации, который управляется параметром Delayed_RecIfUpdate – принимает значения:

0 (по умолчанию) режим отключен;

1 – режим включен.

Включение данного режима позволяет ускорить работу при массовом и одновременном редактировании записей одной БД.

 

 


См. также:

Рабочие листы ВВОДА ДАННЫХ В ЭК (Инструкции Каталогизатора)

Рабочий лист ввода (АРМ Каталогизатор)

Профиль сервера ИРБИС 64