Re: Версия 2012.1
Пользователь:
Alio (IP-адрес скрыт)
Дата: 16, December, 2011 15:28
Серверная часть ИРБИС64.
Создан новый механизм актуализации записи (корректировка словаря в соответствии с изменениями записи) - отличающийся от старого механизма большим быстродействием.
Дальнейшие разъяснения будут интересны исключительно продвинутым администраторам ИРБИС, которым не лень разбираться в тонкостях "движка" СУБД ИРБИС.
Чтобы объяснить суть нового механизма актуализации, необходимо напомнить схему старого механизма. Она состоит в следующем:
- рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
- обе копии записи подвергаются обработке (в оперативной памяти) в соответствии с таблицей инвертирования данной БД (<имя_БД>.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-шлюзы
(и что самое "неприятное" - они становятся НЕСОВМЕСТИМЫМИ с аналогичными модулями версий ниже 2012.1)