Оптимизация моделей интегративного поиска вузовских библиотечных порталов тема диссертации и автореферата по ВАК РФ 05.25.05, кандидат наук Соколинский Кирилл Евгеньевич

• Соколинский Кирилл Евгеньевич
• кандидат наук
• 2018

Оглавление диссертации кандидат наук Соколинский Кирилл Евгеньевич

Введение

Глава 1. Подходы к интегративному поиску на вузовских библиотечных порталах

1.1. Анализ поисковых технологий библиотечных вузовских порталов

1.2. Обзор библиотечных порталов ведущих российских и зарубежных вузов

1.3. Выводы

Глава 2. Анализ моделей интегративного поиска

2.1. Концепция распределённого поиска и её реализация

2.2. Проблемы распределённого поиска и критерии его эффективности

2.3. Оптимизация модели распределённого поиска

2.4. Концепция поиска по консолидированному индексу метаданных и её реализации

2.5. Проблемы формирования консолидированных поисковых индексов и критерии эффективности процесса

2.6. Оптимизация формирования консолидированного поискового индекса

2.7. Выводы

Глава 3. Исследование интегративного поиска в типовой системе для построения вузовских библиотечных порталов

3.1. Назначение и принципы реализации

3.2. Функциональные возможности

3.3. Компоненты и архитектура

3.4. Режим распределённого поиска

3.5. Экспериментальная оценка эффективности алгоритма распределённого поиска

3.6. Режим формирования консолидированного поискового индекса

3.7. Экспериментальная оценка эффективности алгоритма формирования консолидированного индекса

3.8. Выводы

Заключение

Список использованных сокращений

Список литературы

Приложение №1. Сравнительные характеристики сайтов библиотек ведущих вузов

Приложение №2. Организации и корпоративные проекты, использующие J-ИРБИС

Приложение №3. Свидетельства о государственной регистрации программ для ЭВМ и баз данных

Приложение №4. Акты внедрения и практического использования результатов диссертационного исследования

Приложение №5. Пример программного кода, реализующего трансляцию запросов стандарта САБ ИРБИС для Z39.50 сервера

Введение диссертации (часть автореферата) на тему «Оптимизация моделей интегративного поиска вузовских библиотечных порталов»

Введение

Актуальность темы. Совершенствование веб-технологий обусловливает необходимость постоянного анализа современных тенденций при разработке библиотечных сайтов. Новая парадигма развития интернета веб 2.0 отводит пользователю не просто роль потребителя, но и создателя информационных ресурсов. Традиционным становится учёт предпочтений при отображении результатов поиска. Распространение получают подсказки-рекомендации пользователю относительно предметов или тем, которые могут представлять для него интерес. Всё чаще для доступа к интернету применяются мобильные устройства и все большее значение приобретает кроссплатформенность1 сайтов. Поэтому большинство крупных коммерческих порталов2 уже адаптировано для смартфонов и планшетов.

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

Изменения российского законодательства, произошедшие в 2015-2016 году3, открыли библиотекам возможность без согласия правообладателя воспроизведения малообъёмных произведений, статей из журналов, докладов из сборников научно-образовательного характера. Новые правовые нормы создали стимул для частичной оцифровки наиболее важных текстовых материалов и развития сервисов электронной доставки документов.

В связи с изменениями в технологиях и снятием ряда законодательных преград меняются и расширяются функции библиотек. Особенно это характерно для библиотек вузов.

1 Кроссплатформенность - в данной работе, возможность использования более чем одной аппаратной платформы или операционной системы.

2 Портал -- в данной работе, крупный вебсайт или служба Интернета, предоставляющие пользователям информационные ресурсы и сервисы.

3 Гражданский кодекс Российской Федерации: часть четвертая. М.: Омега-Л, 2017. 624 с.

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

Преподавателям требуется широкий спектр научных публикаций на русском и иностранных языках. Для них большое значение имеет актуальная научная периодика (преимущественно поставляется крупными зарубежными компаниями), печатный научный фонд библиотеки. Такое разнообразие подписных и собственных, электронных и традиционных ресурсов делает актуальным вопрос о едином механизме навигации в них.

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

Интегративный поиск является универсальным подходом. Он применяется как для интеграции ресурсов в рамках одной организации (например, филиалов ЦБС), так и для создания крупных национальных проектов (например, НЭБ). Тем не менее, в вузовских библиотеках его использование не только имеет особое значение, в силу необходимости работы с широким спектром источников, но и свою специфику.

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

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

Можно выделить также характерные только для российских вузовских библиотек требования к поисковым системам. Федеральные государственные образовательные стандарты предписывают необходимость полного обеспечения учебного процесса литературой. Все издания, рекомендуемые в рабочих программах дисциплин, должны быть доступны в библиотеке вуза. Отсюда следует потребность приведения библиотечного фонда в соответствие с учебным планом. Как правило, это реализуется ещё на этапе комплектования: преподаватель, заказывая издание, определяет для какого контингента и по какой дисциплине оно рекомендуется. Использование этой информации и списков литературы в программах учебных дисциплин, вместе с действующим учебным планом, позволяет определять книгообеспеченность, вычислять необходимую экземплярность изданий и реализовывать дополнительные сервисы. Одним из таких сервисов является рекомендательный поиск. Под рекомендательным поиском в настоящей работе будет пониматься сервис, позволяющий студенту получить список литературы, рекомендуемой преподавателями по конкретным дисциплинам на текущий период обучения. Наряду с интегративным, рекомендательный поиск позволяет минимизировать временные затраты на отбор нужной литературы для студентов и обеспечить возможность контроля книгообеспеченности для преподавателей и методистов.

Тем не менее, на большинстве сайтов российских вузовских библиотек не учтены общие тренды развития веб-технологий, не реализованы функции интегративного и рекомендательного поиска. Пользователям приходится методом проб и ошибок ориентироваться в многообразии разрозненных поисковых систем. Зачастую это приводит к применению в ходе обучения и научной работы материалов, найденных на первых страницах результатов поиска в Google и Yandex. В результате библиотечные ресурсы и дорогостоящие подписные базы оказываются недостаточно востребованными. [42, 82]

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

Разработанность проблемы. Потребность в интеграции метаданных информационных ресурсов была осознана библиотечным сообществом ещё в 1960-е годы. Впервые каталоги библиотек учебных заведений были объединены в проекте Онлайнового компьютерного библиотечного центра (Online Computer Library Center, OCLC). Этот проект быстро приобрёл национальный, а затем и международный характер. [90, 122]

В СССР, в конце 1970-х годов, одним из первых сводных каталогов стал Российский сводный каталог по научно-технической литературе (впоследствии получил название Интегрированный сводный каталог научно-технической информации - ИСК НТИ). В 1990-х годах крупнейшим национальным ресурсом стал Сводный каталог библиотек России (СКБР), объединивший каталоги многих библиотек, подчинённых Министерству культуры РФ. [51, 33] Но эти проекты были ориентированы на национальную и отраслевую библиографию, поэтому мало затронули работу вузовских библиотек. Первым проектом, целенаправленно интегрировавшим вузовские ресурсы в России, стала ИС «Единое окно доступа к образовательным ресурсам», разработанная в 2008 году по заказу Министерства образования и науки РФ Государственным научно-исследовательским институтом информационных технологий и коммуникаций «Информика». В рамках проекта удалось интегрировать 30 тыс. полнотекстовых материалов, но он затронул лишь небольшую часть вузовских библиотек и не использовал автоматизированные технологии обмена данными. Более полного охвата библиотечных ресурсов удалось достигнуть в проекте «Информационной системы доступа к каталогам библиотек сферы образования и науки в рамках единого интернет-ресурса» (ИС ЭКБСОН), разработанным ГПНТБ России. Здесь впервые была учтена серая литература [87,88].

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

4 Портал -- в данной работе, крупный вебсайт или служба Интернета, предоставляющие пользователям информационные ресурсы и сервисы.

распространение получили системы EBSCO Discovery Service (компания EBSCO, США), Summon (компания ProQuest, США) и Primo Discovery Service, SaaS версия (Ex Libris Group, США). Эти системы представляют собой не часть библиотечного программного комплекса, а независимые сервисы, которые реализуются на серверах компаний-владельцев, и могут интегрироваться в сайты библиотек-пользователей. Электронный каталог или электронная коллекция библиотеки-пользователя участвуют в них как одна из составных частей. Обычно поисковые системы агрегаторов представлены в интерфейсе, адаптированном по дизайну к сайту пользователя. Такая схема в настоящее время стала самой распространённой в Российских и зарубежных университетах.

Крупнейшим некоммерческим проектом, ориентированным на агрегацию научной и учебной литературы стал проект Google Scholar. Он позволяет использовать алгоритмы Google для целей поиска научных ресурсов и вместе с тем применять критерии релевантности, характерные для научного сообщества (индексы цитирования). Проект даёт авторам возможность загружать электронные версии своих работ и библиографию, анализировать показатели цитируемости. Наряду с интеграцией метаданных, присутствующих в ведущих электронных каталогах, проект предоставляет доступ к коммерческим и открытым электронным ресурсам.

Другая, принципиально отличная схема интеграции метаданных, была реализована в проектах Karlsruher Virtueller Katalog (Виртуальный каталог Карлсруэ, Технологический университет Карлсруэ, Германия), АРБИКОН (Ассоциация региональных библиотечных консорциумов, Россия) и Библиопоиск. Электронные ресурсы в них объединяются лишь в момент поиска и физически могут храниться в разных источниках. [124, 45, 46, 44]

Таким образом, допустимо выделить два вида интегративного поиска: распределённый поиск, который осуществляется с использованием физически независимых БД метаданных, и поиск по консолидированному поисковому индексу5, когда данные сгруппированы в одной БД, а идентичные записи из разных источников объединены (выполнена дедубликация). Как концепция распределённого поиска, так и концепция поиска по консолидированному массиву

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

библиографических записей, нашли отражение в технологиях российских библиотечных порталов.

На сайте НБ МГУ им. М.В. Ломоносова с помощью оригинальной системы реализован поиск по электронному каталогу и коллекциям трёх ЭБС, на которые оформлена подписка. В НБ им. А.М. Горького СПбГУ реализован поиск с применением двух программных решений -Web-ИРБИС (разработанной Ассоциацией ЭБНИТ) и VuFind (разработана Университетом Вилланова, США). Первый позволяет искать в электронном каталоге библиотеки, второй в зарубежных ресурсах. НБ им. Н.И. Лобачевского КФУ даёт возможность получения первых результатов поиска из двух используемых в библиотеке систем агрегации (Summon и VuFind). Исходя из этих результатов, пользователь может определиться, в каком информационном массиве он будет продолжать поиск.

Большинство крупных университетских библиотек (например, Научная библиотека им Н.И. Лобачевского КФУ, Научная библиотека СПбГУ, Библиотечно-издательский комплекс СФУ) различными способами пытаются решить задачу реализации поиска, интегрирующего разрозненные библиографические массивы и метаданные полных текстов. В то же время отсутствуют модели реализации единой точки доступа ко всем ресурсам в масштабе университета (см. Приложение №1). Отсутствуют реализации рекомендательного поиска, предполагающего согласование поисковой системы с учебным планом.

В специальной литературе многократно освещались вопросы интеграции метаданных и электронных ресурсов. Широкий круг вопросов, связанных с организацией поисковых систем, был затронут в работах Я.Л. Шрайберга [87, 88, 89, 90], М.В. Гончарова [14], Ф.С. Воройского [13], А.Б. Антопольского [4,5,6,7,8], Н.Е. Каленова [19, 20], Б.Р. Логинова [34]. Общие вопросы архитектуры вузовских библиотечных порталов затрагивались в работах Н.В. Соколовой [73, 74], С.С. Достовалова [15], Е.Н. Струкова [72], M. Breeding [100], J. Gross [112].

Технические вопросы реализации распределённого поиска были детально проанализированы в работах К.А. Колосова [29, 30, 31], О.С. Колобова [31], Р.Т. Усманова [76, 77], О.С. Жижимова [16]. Проблемы теории и практики консолидации/связывания метаданных затрагивались в работах А.С. Карауша [22, 23], О.Н. Шорина [84, 85, 86], А.А. Князевой [25, 26, 27], Д.Н. Совы [57], А.В. Фронкина [79, 80], Д.Н. Рубцова [53], W.E. Winkler [134, 135, 136, 137, 138, 139, 140], T.N. Nerzog [125], E.H. Porter [128, 113], I.P. Fellegi [113], J. A. Hylton [118].

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

мере ввода запроса) и разработкой моделей вузовских библиотечных порталов, учитывающих российские образовательные стандарты.

Цель диссертации - обоснование универсальной модели вузовского библиотечного портала с использованием новых подходов к реализации интерфейса поисковой системы, интегративного и рекомендательного поиска.

Достижение этой цели потребовало решения следующих задач:

• обоснование понятия интегративного поиска;

• анализ существующих моделей построения вузовских библиотечных порталов;

• определение общих требований к функциональным возможностям вузовских корпоративных поисковых систем;

• исследование и описание моделей интегративного поиска и корпоративных электронных библиотек;

• обоснование новой модели распределённого поиска и новой модели формирования консолидированных поисковых индексов.

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

Теоретическая значимость работы заключается в: • разработке математической модели обработки сетевых сбоев в реальном времени;

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

• введении в научный оборот понятий интегративного поиска и ассимиляции кэша;

• разработке концепции типового вузовского библиотечного сайта на основе интегративного поиска;

• обосновании модели распределённого поиска с унификацией результатов и ассимиляцией кэша;

• обосновании модели формирования консолидированного поискового индекса с применением внешнего метабиблиографического индекса, учётом семантической значимости элементов и пороговой оценкой соответствия.

Практическая значимость заключается в разработке рекомендаций по созданию универсальной модели программного обеспечения вузовского библиотечного сайта с функциями распределённого поиска и возможностью построения поисковых индексов на основе распределённых источников метаданных. Сформулированы рекомендации по разработке архитектуры порталов для вузовских библиотек. На основе этих рекомендаций был реализован модуль J-ИРБИС 2.0, используемый более чем 90 вузами России и Украины (см. Приложение №2). Создано третье в России, по числу участников корпоративное объединение --ИРБИС-корпорация7, используемое более чем 15 тыс.8 библиотечных сотрудников.

Акты внедрения и список пользователей программных комплексов, разработанных в результате диссертационного исследования, приведены в Приложении №2 и Приложении №4.

В процессе работы над диссертацией были разработаны программы для ЭВМ и базы данных, прошедшие государственную регистрацию в Федеральной службе по интеллектуальной собственности Российской Федерации, что подтверждается Приложением №3.

На защиту выносятся следующие основные положения:

1. оптимизация интегративного поиска на сайте вузовской библиотеки требует применения как распределённого поиска, так и поиска по консолидированному поисковому индексу;

7 На 18.09.2016 -- 175 участников, предоставляющих свои записи. По количеству участников, предоставляющих записи, уступает только ИС ЭКБСОН и консорциуму АРБИКОН. Национальный информационно-библиотечный центр ЛИБНЕТ объединяет каталоги меньшего количества библиотек (87 библиотек на 17.12.16, по данным сайта http://www.nilc.ru/?p=commonlist).

8 На 10.02.2016 зафиксировано использование сервиса 15 263 пользователями.

2. распределённый поиск с отображением результатов по мере их получения от внешних источников позволяет значительно уменьшить время ожидания пользователя;

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

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

5. интегративный поиск является основой для эффективной реализации целого ряда сервисов, актуальных для вузовских библиотек (например, рекомендательного поиска, системы электронной доставки документов и др.).

Методы исследования - математическое и процедурное моделирование, статистический анализ, классификация, сравнительный анализ, метод нечёткого сопоставления строк, а также анализ и синтез информационных систем.

Объект исследования - порталы вузовских библиотек и система специализированных онлайновых сервисов для учебных заведений.

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

Апробация результатов исследования заключалась в публикации материалов исследования в периодических изданиях и докладах на конференциях и семинарах.

Результаты данного исследования представлены на конференциях:

1. «Крым 2010», «Крым 2011», «Крым 2012», «Крым 2013», «Крым 2014», «Крым 2015», «Крым 2016», «Крым 2017» -- «Библиотеки и ассоциации в меняющемся мире: новые технологии и новые формы сотрудничества» (г. Судак, Автономная республика Крым).

2. «ЛИБКОМ 2010», «ЛИБКОМ 2011», «ЛИБКОМ 2012», «ЛИБКОМ 2013», «ЛИБКОМ 2014», «ЛИБКОМ 2015», «ЛИБКОМ 2016», «ЛИБКОМ 2017» -- "Информационные технологии, компьютерные системы и издательская продукция для библиотек" (пос. Ершово (Московская область), г. Химки, (Московская область), г. Суздаль (Владимирская область)).

3. Выездное заседание Школы ИРБИС: Первая осенняя сессия (г. Санкт-Петербург, Россия, 2016)

4. Семинар «Настройка WEB ИРБИС и J-ИРБИС» (г. Баку, Азербайджан, 2010)

5. Семинар «АБИС ИРБИС: расширение возможностей системы для развития информационно-образовательной и телекоммуникационной среды региона» (г. Омск, Россия, 2008)

Публикации. По теме работы опубликовано 14 статей и тезисов докладов, из них 6 в журналах, рекомендованных ВАК России.

Глава 1. Подходы к интегративному поиску на вузовских библиотечных порталах

1.1. Анализ поисковых технологий библиотечных вузовских порталов

1.1.1. Форматы метаданных

Потребность в сборе и обработке библиографической информации побудила Библиотеку Конгресса США и Совет по национальной библиографии (Великобритания) в 1960-х годах начать разработку формата представления библиографических записей в машиночитаемой форме. Созданный в результате формат MARC стал основой для многих форматов и схем данных, в т.ч. одобренного IFLA формата UNIMARC. В процессе развития формата MARC появились десятки форматов данных, ориентированных на национальные правила каталогизации, одним из которых стал формат RUSMARC.

Несмотря на то, что формат RUSMARC позиционировался в качестве основного на территории России, по целому ряду причин он не смог выполнить функции единственного национального стандарта. Многие разработчики отечественных (MARC-SQL) и зарубежных (Aleph) САБ9 содействовали распространению формата USMARC, а впоследствии MARC21. Некоторые САБ (ИРБИС) начали использовать модификации распространённых стандартов (UNIMARC).

Сложность соблюдения MARC -форматов и правомерность использования различных подходов к описанию документов породила большое количество интерпретаций каждого из форматов [41]. Несмотря на то, что большинство российских САБ сегодня сертифицировано на соответствие RUSMARC, каждая САБ использует свою интерпретацию формата. Зачастую

9 Чтобы избежать разночтений, в данной работе для обозначения программного обеспечения, предназначенного для автоматизации библиотек, будет использоваться аббревиатура САБ, используемая в сообществе пользователей системы ИРБИС 64. По своему значению эта аббревиатура идентична более распространённой аббревиатуре АБИС.

имеют место ситуации, когда документы, выгруженные в RUSMARC из САБ, импортируются в ту же САБ уже в искаженном виде.

Ещё большие сложности вызывает следование коммуникативным форматам у ЭБС и издательств, которые предлагают библиотекам подписные ресурсы. Учитывая, что их программное обеспечение разрабатывалось не связанными с библиотечным делом группами программистов, обеспечение соответствия любому коммуникативному формату для них является технически сложной и экономически затратной задачей. Кроме того, программное обеспечение большинства ЭБС было рассчитано на использование всего 20-30-ти полей для описания документа, тогда как RUSMARC предполагает использование больше чем тысячи полей и подполей. Таким образом, записи ЭБС не только не позволяют сформировать полноценную запись в библиотечных коммуникативных форматах, но, как правило, не учитывают различия в способах описания различных типов документов. В связи с этим, например, большинство многотомных изданий описываются как однотомные. Встречаются ситуации, когда все записи номеров журналов оказываются полностью идентичными в связи с отсутствием в них сведений о годе издания и номере выпуска.

Таким образом, можно констатировать несколько проблем, связанных с форматами: использование на территории РФ множества версий форматов, неполная их поддержка со стороны САБ, неудовлетворительная поддержка форматов со стороны агрегаторов подписных ресурсов.

В связи с исключительной сложностью MARC-формата, OCLC и Национальный центр суперкомпьютерных приложений (National Center for Supercomputing Applications, NCSA) в 1995 году начали разработку более простого формата метаданных, ориентированного во многом на электронные ресурсы. Этот формат получил название Дублинское ядро (Dublin Core, DC). Он содержит только 15 элементов (версия 1.1 от 2013 года)[109]. Запись в формате дублинского ядра может формироваться на основе любой MARC-записи. Описания в формате Дублинского ядра могут легко стать частью метаданных веб-страниц, а также использоваться для организации семантических связей между страницами/ресурсами.

Список литературы диссертационного исследования кандидат наук Соколинский Кирилл Евгеньевич, 2018 год

библиографические

описания.

АРБИКОН До 3 30 секунд Результаты

(Ассоциация поиска выводятся

российских сразу же в форме

библиотечных последовательности

консорциумов) библ. описаний.

(https://arbicon.ru)

СИГЛА Неактивные < 3 секунд Выводится число

(проект Научной каталоги при выборе найденных

библиотеки МГУ и исключаются группы записей в каждом

компании системой при из 3-х серверов; каталоге

«Библиотечная просмотре 30-70 секунд до сразу же по мере

компьютерная сеть») результатов полного поступления

(http://www.sigla.ru) поиска вывода ответов от серверов.

при опросе Перейти к

от 4-х до просмотру

20-ти неактивных библиографических

серверов описаний

можно не дожидаясь

окончания вывода всех

результатов

Библиотека «Артека» До 3 серверов 6 секунд Выводятся

(http://bibliosearch.rU/a результаты поиска в

Пек) форме единого списка.

Библиографические

описания предельно

лаконичны (4 элемента,

представленные в

табличной форме).

2. Ограниченные возможности. Применение протокола Z39.50 для реализации распределённого поиска существенно ограничивает возможности поискового инструментария. И чем большее количество серверов с различным программным обеспечением участвует в поиске, тем более вероятно, что возникнет необходимость отказаться от отдельных поисковых возможностей.

3. Нестабильность распространённого ПО. Большинство Z39.50 серверов, используемых для распределённого поиска в России, не отличаются стабильностью работы [30]. Они являются частью трёхзвенной архитектуры и взаимодействуют с СУБД. Это определяет их зависимость от стабильности СУБД, САБ и процессов конверсии данных. В то же время более современный протокол SRU/SRW ещё не получил широкого распространения.

4. Необходимость ручной настройки системы поиска. Для приемлемого качества работы с серверами Z39.50 требуется эмпирически отслеживать их возможности по поддержке форматов, кодировок и представлений данных. Один и тот же универсальный сервер (например, ZooPARK, Zebra) предоставляет разные возможности при его использовании с различными САБ.

5. Проблемы разграничения прав доступа к электронным версиям. Доступ к электронным документам в удалённых источниках возможен лишь в том случае, если ссылки на них являются открытыми. Реализацию какого-либо авторизованного доступа стандартные протоколы, применяемые при распределённом поиске (Z39.50, SRU/SRW), не предусматривают. А специализированные протоколы (SAML) требуют для своего внедрения преодоления высокого технологического барьера.

6. Отсутствие универсальных технологий полнотекстового поиска. Z39.50 и все протоколы, на нём основанные, предусматривают полнотекстовый поиск, но информация о поддержке этих возможностей в конкретных программных реализациях российских Z39.50 серверов отсутствует. Разработка сервера, который бы обеспечивал не только выборку данных, но и отображение контекста, требует преодоления высоких технологических барьеров. И, несмотря на то, что многие решения (T-Libra, Библиопортал, J-ИРБИС 2.0) реализуют распределённый полнотекстовый поиск, в библиотечном сообществе пока отсутствуют его общепризнанные стандарты.

Таким образом, вопрос эффективности применения распределённого поиска может быть решен исходя из перспективы преодоления связанных с ним проблем.

2.2.2. Критерии эргономичности интерфейса

Анализ успешного опыта работы распределённых поисковых систем позволяет выделить условия востребованности, оптимальные характеристики интерфейса и архитектуры.

В первую очередь, это соответствие привычным для пользователя интерфейсным стандартам. Как показывает статистика, работая с библиотечными поисковыми системами, типичный пользователь хочет видеть поисковый интерфейс идентичный Google и Yandex -простой и понятный. Квалифицированный пользователь вправе получить более широкий перечень функций, но и он не готов считаться с проблемами поисковой системы, обусловленными её технической структурой. Идеальная система распределённого поиска должна быть частью привычного OPAC, а не автономной системой. Пользователь должен в единообразной форме получать данные из локальных баз и внешних систем.

Если типичные пользователи системы -- студенты, условием востребованности распределённого поиска будет его включение в интерфейс каталога или электронной библиотеки. Если пользователи - читатели районной ЦБС, то поисковая система должна быть включена в интерфейс сайта конкретной ЦБС.

Учитывая, что поисковые системы в интернете возвращают результаты в течение нескольких десятых долей секунды, выполнение запроса более чем в течение 60 секунд расценивается пользователем как зависание [30]. Поэтому исключительное значение приобретает реалистичная индикация прогресса, позволяющая заключить, в какой степени запрос был выполнен и сколько ещё предстоит ждать. В противном случае нетерпеливый пользователь будет перезагружать страницу. «Неопределённая» индикация процесса, сообщающая лишь о том, что система занята, не вызывает доверия.

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

1. Скорость отображения результатов;

2. Наличие автоматического отображения результатов по мере ввода запроса

пользователем;

3. Полнота охвата доступных пользователю ресурсов;

4. Простота и функциональность поискового интерфейса;

5. Реалистичность индикации прогресса.

2.2.3. Технические критерии эффективности

Можно выделить ряд технических характеристик системы, позволяющих ей обеспечивать приемлемый уровень надёжности и скорости. Учитывая разнообразие коммуникативных протоколов (Z39.50, SRU/SRW) и различных возможностей каждого сервера-источника записей, требуется обеспечить работу не только с предпочтительным для источника протоколом, но и с конкретным набором атрибутов, корректно поддерживаемым источником. Распределённая поисковая система должна обеспечивать поддержку различных кодировок и форматов метаданных. Например, система должна запрашивать записи в том формате, который является базовым для удалённой системы.

Помимо поддержки стандартизированных протоколов важна поддержка оригинальных протоколов/API интегрируемых систем (например, Summon, EBSCO, САБ ИРБИС). По своим возможностям эти протоколы, как правило, значительно превосходят универсальные в аспекте надёжности, скорости и качества предоставляемых данных. Исключение потребности в преобразованиях, интеграции с чужеродными системами, взаимодействие по оригинальным (native) протоколам всегда даёт значительные преимущества. Исчезает и крайне актуальная для библиотечного сообщества проблема соблюдения коммуникативных форматов, их различной интерпретации.

Одной из важных характеристик системы распределённого поиска является корректная обработка ошибок при поиске. Сбой на одном из серверов не должен приводить к искаженному отображению результатов поиска. В то же время, пользователь должен получать информацию о том, какие источники не участвовали в поиске.

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

1. Поддержка специализированных протоколов и форматов;

2. Учёт поисковых атрибутов, поддерживаемых источником;

3. Корректная обработка ошибок и ситуаций неработоспособности части источников.

Описанные выше критерии позволяют разработать универсальную модель

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

2.3. Оптимизация модели распределённого поиска

Предлагаемая автором настоящей диссертации оригинальная модель основывается на постулате, что поиск в локальных ресурсах является лишь одной из функций используемой библиотекой САБ. Соответственно, при поиске через OPAC существует потребность объединения результатов в локальных базах и внешних источниках. Допускается, что у пользователя есть возможность выполнять одновременный поиск не более чем в 100 источниках, и эти источники доступны через различные коммуникативные протоколы. Предполагается, что в качестве базовой системы автоматизации применяется одна из распространённых российских САБ (ИРБИС, MARC-SQL, Руслан), которые используют для формирования библиографических описаний по ГОСТ 7.1-2003 интерпретируемый язык.

Оптимизированная модель предполагает наличие следующих процессов:

1. Оценка оптимального размера группы запросов. Часть операций, связанных с поиском и обработкой результатов поиска, должна выполняться в параллельных потоках. Это позволяет более эффективно использовать ресурсы современных многопроцессорных серверов и одновременно обращаться к целому ряду источников. Но в то же время важно, чтобы суммарное количество поисковых процессов согласовывалось с вычислительными возможностями сервера.

Наиболее ресурсоёмкой составляющей процесса обработки является процесс конвертирования записей и формирования библиографических описаний: расформатирование. В большинстве САБ расформатирование реализуется средствами интерпретируемых (скриптовых языков), поэтому требует значительного количества процессорного времени. В каждом конкретном случае сложность библиографического описания определяет длительность расформатирования. Например, полное библиографическое описание17 в соответствии с ГОСТ 7.1-2003 формируется дольше, чем библиографическая ссылка в соответствии с ГОСТ 7.0.52008. Кроме того, если библиографическое описание формируется из нескольких составных элементов (например, предметные рубрики, полочный шифр и т.п.), ресурсоёмкость его

17 В данной диссертации под «библиографическим описанием» подразумевается структура библиографических данных, предусмотренная в ГОСТ 7.1 -2003, ГОСТ 7.0.5-2008 или более ранних. Под «библиографической записью» подразумевается набор данных (полей, подполей), из которых может быть сформировано библиографическое описание.

создания будет определяться совокупностью ресурсоёмкости создания всех составных элементов.

2. Сортировка источников. Определяет порядок выполнения запросов к ним. При условии, что скорость отклика источников одинакова и ранжирование не применяется, сортировка целиком определяет порядок отображения записей из разных источников. Сортировку допустимо выполнять исходя из полезности источника. Тогда чем более высокий рейтинг у источника, тем больше вероятность, что пользователь получит результат от него первым. Учитывая, что обычно источники неравнозначны (например, РГБ для российского читателя более доступна, чем Библиотека конгресса США с точки зрения получения литературы), это позволяет отображать результаты самых предпочтительных источников первыми. Сортировка по скорости отклика ориентирует поиск на максимизацию скорости вывода. В случае приоритетного опроса самых быстрых источников, появляется возможность предоставить первые результаты как можно более оперативно.

3. Группировка источников. Запросы должны выполняться асинхронно, так как это обеспечивает максимизацию скорости. Чтобы избежать перегрузок сервера, требуется разделение запросов на последовательно (синхронно) выполняемые группы.

Запросы должны группироваться исходя из порядка сортировки. Размер группы определяется ресурсоёмкостью запроса. В рамках группы порядок запросов, за счёт асинхронного выполнения, не отражается на итоговом результате. Но номер группы, в которой находится запрос, полностью определяет положение результатов его выполнения в общем результате поиска.

Практика ИРБИС-Корпорации показала, что группировка 50 запросов позволяет избежать перегрузок системы и, при этом поиск выполняется достаточно быстро.

4.Трансляция запроса. Синтаксис запросов к удаленным источникам, как правило, отличается от базового синтаксиса запросов САБ. Поэтому требуется трансляция (конвертация) сформированного ОРАС запроса.

Трансляция всегда должна выполняться индивидуально для каждого удалённого сервера-источника, так как, даже при использовании одного и того же протокола для всех источников, набор поддерживаемых атрибутов может существенно отличаться. Кроме ограничения по атрибутам поиска, требуется учитывать архитектурные ограничения серверов-источников. К таким неявным ограничениям относится, например, количество терминов в запросе, объединённых оператором «ОЯ». К ним же можно отнести и недопустимость определённых сочетаний атрибутов. Таким образом, трансляция не всегда позволяет

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

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

5.Выполнение группы запросов на поиск и извлечение записей. Из группы запросов, определённой в рамках предыдущих этапов, должны формироваться независимые процессы поиска и обработки полученных данных. Количество этих процессов будет соответствовать количеству запросов в группе. Каждый запрос должен независимо от других обращаться к серверу, преобразовывать и кэшировать полученные в результате поиска данные.

6. Блокировка неактивных серверов-источников. Эпизодическая недоступность отдельных серверов в результате их неработоспособности, перегрузки или проблемами с каналами связи - неизбежное явление при распределённом поиске. Типовое решение этих проблем с помощью периодического запуска сканеров-роботов увеличивает время, в течение которого пользователи будут предпринимать попытки обращения поисковой системы к проблемным серверам. В то же время, как показывают многие исследования [28,30,76], именно недоступность серверов является главным фактором, провоцирующим задержки при распределённом поиске.

Как правило, поисковая система ожидает отклика от сервера-источника максимально возможное время, отведённое на запрос (timeout). В результате один сбойный сервер обычно является причиной существенного замедления выполнения группы запросов. Поэтому блокировка сервера-источника оправдана немедленно после обнаружения первой проблемы. Многие проблемы доступности сервера носят эпизодический характер, поэтому блокировка должна быть временной. После истечения определённого срока диагностика сервера-источника должна повторяться и при повторном неудовлетворительном результате блокировка должна устанавливаться уже на больший промежуток времени. Оправданным является экспоненциальное или близкое к нему увеличение времени блокировки при каждом новом обращении к серверу. Если сбой обусловлен перегрузкой сервера, то последующие обращения через короткий промежуток времени могут дать результат. Если сбой связан с изменением адреса сервера или прекращением его работы, то после определённого тестового периода промежутки, через которые выполняются новые обращения, должны существенно возрастать. Аппроксимация результатов статистического анализа ошибок, возникающих при обращении к

серверам в ИРБИС-Корпорации, позволила автору построить математическую модель задержек, выраженную формулой t = (i4) Здесь: t - время задержки;

i - количество неудачных попыток обращения к серверу. Применение формулы иллюстрирует график на рисунке 2.

Время, мин.

120000 100000 80000 60000 40000 20000 0

Неудачные обращения

Рисунок 2: Модель изменения периодов обращения к серверу по мере увеличения количества ошибок

Снятие блокировки может также осуществляться средствами программы-робота. В этом случае тестирование источника не отражается на выполнении скорости запросов пользователей.

7. Конверсия записей. Конверсия обеспечивает унификацию формата и представления записей. Это позволяет выполнить расформатирование с помощью единого для всех записей алгоритма. Распределённые поисковые системы, как правило, работают с одним из двух представлений записи - ISO 2709 и XML. Наиболее распространёнными в России форматами являются RUSMARC, UNIMARC, MARC21 и Дублинское ядро. Но в ряде случаев сервера-источники возвращают записи в собственных, оригинальных форматах (например, специальные упрощенные форматы, используемые в САБ ИРБИС). Преобразование записей в системе,

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

8. Формально-логический контроль конвертированных записей. В библиотечных каталогах часто появляются записи, не соответствующие минимальным требованиям качества. Это могут быть, например, записи в кодировке, отличной от кодировки каталога в целом, пустые записи, которые ещё не завершены сотрудниками и др. Они должны фильтроваться, так как не представляют интереса для пользователей.

9. Исключение неактуальных элементов. Полученные из удаленных источников записи, как правило, бывают избыточными с точки зрения состава имеющихся в них данных. Сведения об экземплярах, сведения об учебном назначении, признак "автор-сотрудник" и другие подобные элементы не представляют интереса для пользователей корпоративных проектов, поэтому оправдано их удаление.

10. Дополнение записей. Правильное отображение записи часто требует корректных данных в кодированных полях (маркер записи, поля 1ХХ MARC форматов и др.). Но в тех организациях, где САБ не контролирует правильность заполнения полей, они очень часто вводятся с ошибками. Поэтому в ходе унификации записей оправдана корректировка этих данных или их искусственное формирование.

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

11. Формирование библиографических описаний. Автоматическая трансформация набора библиографических данных в библиографическое описание (расформатирование) по ГОСТ 7.1-2003 является ресурсозатратным процессом и часто сопровождается ошибками. Любая ошибка при заполнении полей записи может негативно сказаться на процессе. Кроме того, формирование качественного библиографического описания пока вызывает сложности у многих разработчиков САБ. Поэтому данный этап допустимо заменить простой генерацией набора подписей к полям.

Тем не менее, если сегодня библиотеками заполняется до 1000 элементов библиографической записи (полей и подполей), предусмотренных коммуникативными форматами, редукция записи к 15 элементам Дублинского ядра нецелесообразна. Кроме того, многие пользователи электронных каталогов и библиотек применяют поисковые системы в научных и учебных целях, поэтому нуждаются в полных библиографических описаниях.

12. Кэширование и агрегация в реляционной БД. Кэширование или временное хранение наиболее часто востребованных данных реализуется в информационных системах тогда, когда требуется увеличить скорость получения данных. В описываемой модели распределённого поиска кэш выполняет ещё и функцию агрегации результатов, полученных от отдельных поисковых процессов. Поэтому кэширование является неотъемлемым элементом системы.

Стандартное кэширование индифферентно к содержимому кэшируемой информации. Любая совокупность данных порождает новую дискретную единицу в хранилище кэширующего сервера, доступ к которой реализуется по уникальному ключу. Библиографические записи могут кэшироваться таким образом, но при этом неизбежно перманентное увеличение хранилища и снижение его эффективности. Это особенно вероятно при выполнении множества родственных запросов, результаты которых обычно отличаются на 10-20%.

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

Под ассимиляцией кэша в настоящей работе подразумевается формирование нового кэша, на основе существующего, без новых обращений к библиографическим БД. Ассимиляция кэша может выполняться в тех случаях, когда в системе кэширования присутствуют результаты выполнения более конкретных, по отношению к текущему, запросов. Широкая формулировка запроса (например, "Пушкин") всегда включает целый ряд более конкретных (например, "Пушкин Евгений Онегин"). Это свойство реляционного кэша особенно важно с точки зрения эффективности поиска, выполняемого перманентно при вводе запроса. По мере ввода запроса пользователем формируется не один, а целый ряд похожих запросов. Например: «ист», «история», «история Рос», «история России».

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

Ещё одним фактором, определяющим целесообразность использования внешней реляционной базы, является масштабирование системы, которое может быть реализовано путём выделения независимых аппаратных мощностей для SQL сервера. Кэширование в реляционную БД позволяет выполнять нестандартные выборки из кэша. Например, возможность выделения результатов запроса результатов поиска, связанных с конкретным сервером-источником или его базой. Таким образом, если первый пользователь выполнял запрос по базам А и Б, а второй пользователь решил выполнить запрос только в базе А, то он получит результат значительно быстрее за счёт кэширования.

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

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

13. Ранжирование результатов для целей отображения. Сортировка или ранжирование является опциональным элементом процесса (по умолчанию порядковый номер записи будет определяться скоростью получения и обработки той партии записей, в которой она находится).

Возможности сортировки на уровне приложения-клиента (в роли которого выступает система распределённого поиска) являются достаточно ограниченными. Так как любая сортировка предполагает выгрузку всего сортируемого массива в полном объёме, то это фактически означает поиск, преобразование и кэширование всех записей, найденных по запросу. Поэтому объёмы сортировки целесообразно ограничить таким количеством записей, которое может просматриваться пользователем. Вероятность просмотра пользователем 1000 страниц результатов существует, но она крайне мала. Статистика свидетельствует, что большинство пользователей ограничиваются первыми тремя страницами результатов, поэтому, чтобы сохранить вычислительные мощности и уменьшить до приемлемого уровня время вывода результатов целесообразно использование сортировки лишь на небольших объёмах записей (например, до 200 записей).

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

При условии поддержки сервером-источником индекса релевантности существуют условия для выполнения сортировки (ранжирования) по этим индексам с использованием алгоритма Борда [28].

14. Отображение результатов. Отображение результатов и индикация прогресса при отключённом режиме сортировки должны осуществляться по мере получения новых данных. В случае включения пользователем режима сортировки отображение записей можно выполнять только при полном завершении сканирования всех серверов-источников.

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

Полный опрос источников, несмотря на длительность, необходим для формирования у пользователя адекватного представления о количестве результатов поиска. Например, при наличии 100 записей их просмотр имеет смысл, а при наличии 10 тыс. записей целесообразно уточнение запроса. Кроме того, как уже отмечалось выше, полный опрос источников позволяет реализовать превентивное кэширование и избежать запросов к источникам при переходе по страницам результатов распределённого поиска, многократно ускоряя, таким образом, процесс навигации.

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

Традиционная модель Оптимизированная модель

Кэширование отсутствует или выполняется с использованием файловой системы Кэширование осуществляется в реляционную БД с нормализацией данных

Кэширование осуществляется в Кэширование осуществляется в

рамках синхронно работающего процесса рамках асинхронных процессов

Результаты поиска могут отображаться только после полного завершения процесса Результаты поиска могут отображаться по мере получения новых данных от источников

В качестве базового применяется синтаксис запросов удалённых серверов (как правило 239.50 или SRU\SRW) В качестве базового используется синтаксис запросов локального ОРАС, который преобразуется к синтаксису запросов удалённых серверов

Распараллеливание поисковых запросов осуществляется с использованием встроенных возможностей протокола Распараллеливание осуществляется с помощью серии поисковых запросов, запускаемых независимыми процессами

Запросы к различным источникам выполняются одновременно Запросы к различным источникам выполняются порциями, соответствующими настройкам пользователя и возможностям сервера по их обработке

Система кэширования предполагает извлечение данных только если они были получены по идентичным запросам Система кэширования позволяет осуществлять выборку записей не только по идентичным, но и по более детализированным чем идентичные запросам

Уровень загрузки аппаратных ресурсов не контролируется Уровень загрузки аппаратных ресурсов определяется настройками пользователя и ресурсоёмкостью выполняемых операций

2.4. Концепция поиска по консолидированному индексу метаданных и

её реализации

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

распределённого поиска. Но развитие и удешевление вычислительной техники, появление бесплатных высокопроизводительных СУБД стимулирует вузовские библиотеки в последнее десятилетие к всё более активному её использованию.

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

Одним из первых электронных сводных каталогов, работа над которым началась ещё в 80-е годы, был Российский сводный каталог научно-технической литературы (РСК НТЛ). В рамках этого проекта записи передавались агрегатору (ГПНТБ России) в виде файлов в MARC-совместимых форматах и приводились к UNIMARC. Нередко из-за несоответствия записей формату такая конвертация была сопряжена со значительными трудностями. Кроме того, в этом СК начала использоваться технология дедубликации с помощью библиографических сверток18 записей - т.е. путём сравнения текстовых строк, сформированных из полей сравниваемых записей19. (см. Рисунок 3) Такой подход в дальнейшем получил большое распространение, став едва ли не эталонным на длительный срок. В то же время, были выявлены и его существенные недостатки. Технология проверки на дублетность при свёртке не могла гарантировать высокую точность дедубликации. Возникала потребность в ручном контроле качества. [49]

Радикальной попыткой преодолеть сложности конвертирования и обмена записями стала концепция СКБР. Она оставляла гораздо меньше свободы для участвующих в наполнении каталога библиотек: рядовые участники (кроме двух национальных библиотек) обязывались выполнять каталогизацию в едином интерфейсе САБ OPAC Global. [51] В случае использования САБ отличной от OPAC Global, библиотеки должны были проводить каталогизацию дважды - в собственной САБ и в OPAC Global, поэтому, учитывая высокую

18 Здесь и далее понятие «библиографической свертки» используется для обозначения различных форм хэширования основных библиографических данных. Такое значение этого понятия принято, например, в документации САБ ИРБИС 64 [ 75].

19 Здесь и далее под «полем записи» подразумеваются типичные структурные единицы описания документов, а не конкретные поля форматов семейства MARC.

трудоёмкость, технология СКБР едва ли может тиражироваться и получить распространение в условиях, когда отсутствует возможность административного влияния на участников.

Примером реализации идентичной технологии, но уже на локальном уровне, может выступать Электронный каталог периодических изданий (в рамках Корпоративной сети библиотек Санкт-Петербурга). Однако здесь процесс изначально был облегчён тем, что участники каталога не создавали запись в СК, а лишь копировали её туда. Это позволило избежать разработки специализированного ПО, но потребовало значительных инфраструктурных инвестиций.

Иной подход использовался при формировании отдельных каталогов в рамках АРБИКОН (например, RUSLANet). В консорциуме сбор записей и их дедубликация выполнялись полностью автоматически. Единственное требование, которое предъявлялось к участникам - это обеспечение возможности работы с их каталогами по протоколу Z39.50. Применение общепризнанного протокола для предоставления записей стало прогрессивным шагом. Появилась возможность автоматической поддержки актуальности СК путём периодического опроса серверов библиотек-участников. Но в то же время потребовались значительные усилия для того, чтобы обеспечить работу Z39.50 серверов в соответствии с профилем (набором требований) АРБИКОН. Не существует САБ, поддерживающих все предусмотренные стандартом протокола атрибуты и одинаково трактующих формат RUSMARC.

Принципиально новый путь сбора данных, практически противоположный предшествующим, был реализован в ИС ЭКБСОН. Здесь практиковалось уже не приведение библиотек-участниц к стандартам СК, а наоборот адаптация системы сбора данных СК к стандартам библиотек-участниц. В рамках проекта были разработаны провайдеры/коннекторы ко многим распространённым библиотечным системам, и за счёт технически эффективного механизма сбора записей процесс создания СК значительно упростился. Итогом этого проекта стал самый репрезентативный СК в РФ (больше 10 млн. записей). В то же время требования к скорости сбора и дедубликации данных определили необходимость использования близкой к традиционной технологии формирования СК (по библиографической свертке).

Примером использования ранее мало распространённых принципов дедубликации стал проект Национальной Электронной Библиотеки (НЭБ). Здесь впервые в качестве протокола для получения записей стал использоваться OAI-PMH и формат MODS. В основу подхода к дедубликации были положены разработанные для задач сравнения персональных данных (описаны в источниках: 113, 53, 118) принципы дедубликации записей, базирующиеся на презумпции несовершенства записей и настраиваемых алгоритмах сравнения (с применением

меры Жаккара). Для оптимизации скорости дедубликации применялась группировка (кластеризация) подобных записей, выделенных по году издания или ISBN [84].

Тем не менее, ограничением этого подхода является игнорирование специфических возможностей MARC-записей и искусственная редукция этих записей к более простым форматам (MODS) с потерей данных. Оптимизация алгоритма строится в основном на проработке операции сравнения строк из двух элементов -- автора и заглавия. Множество других существенных для дедубликации элементов (например, номер тома) не учитывается или учитывались в составе строки заглавия, что существенно снижает точность. Эта опора на строку из связанных элементов сближает подход с традиционными методами дедубликации по библиографической свертке, которые описывались ранее.

Таким образом, несмотря на различия в масштабе, принципы реализации крупных проектов, описанных выше, и проектов вузовских корпораций остаются близкими.

2.5. Проблемы формирования консолидированных поисковых индексов

и критерии эффективности процесса

Развитие новых технологий впервые сделало реальной возможность автоматизированного сбора данных для консолидированных поисковых индексов, частным случаем которых являются СК. Предпосылкой для этого стало резкое сокращение САБ, представленных на рынке, и потенциальная возможность разработки полного набора коннекторов/провайдеров. Но такой «технологический» подход еще не получил распространения.

Консолидация записей чаще всего ограничивается объединением сигл фондодержателей. Обогащение одной эталонной записи вызывает сложности в связи с неоднородностью записей и отсутствием эффективных алгоритмов консолидации. Также существует большее количество проблем, связанных с распространённой технологией дедубликации по библиографической свертке (см. Рисунок 3). Она остаётся существенным препятствием для автоматического создания качественных поисковых индексов с минимумом дублетных или ошибочно консолидированных записей.

Автор: Кузьмина Л. М.

Заглавие: Конструктор Сухой. Люди и самолеты

ISBN: 5-203-01472-8

Количество страниц: 383

Год издания: 1995

Рабочий лист: PAZK

4

КузьминаКонструкторСухойлюдиисамолеты 19953835-203-1472-8

Автор Заглавие Год Стр ISBN

Рисунок 3: Формирование библиографической свертки для дедубликации (упрощенная схема)

Технология дедубликации по свертке чувствительна к любым погрешностям в библиографических записях. Также к ошибкам могут приводить незаполненные поля. В то же время обеспечение единообразия записей затруднительно не только в корпоративных объединениях, но даже в рамках каталогов одной библиотеки. Поэтому при создании любого поискового индекса ошибки приходится рассматривать как данность.

Чтобы подтвердить сказанное, достаточно рассмотреть пример с одним из самых формализованных полей - «Год издания». На первый взгляд, оно предельно однозначно: должно включать лишь четыре цифры и заполняться одинаково. Но ГОСТ 7.1-2003 предписывает указывать «Год издания» в квадратных скобках, если он напечатан не на титульном листе и определён каталогизатором. Также ГОСТ допускает, если отдельные цифры года не известны, указывать вместо них знак вопроса. Такие правила могут выполняться каталогизатором или игнорироваться из соображений практичности и целесообразности (в некоторых САБ для упрощения поиска). Если один сотрудник не решится самостоятельно определять год издания и укажет «Б.г.», второй может заполнить поле как «[198?]», третий указать выявленный им год целиком в квадратных скобках [1982], а четвёртый вообще не заполнить это поле.

Логично предположить, что записи, в которых поле «Год издания» заполнено некорректно (например, для поля «Год издания» это 4 цифры, где первая цифра не больше двух), легко игнорировать при дедубликации, подвергая каждый вариант заполнения формально-логическому контролю. Но для технологии библиографической свертки это не так. Если в одной из записей поле будет заполнено правильно (в соответствии со схемой), а в других нет, то свертки окажутся различными и, следовательно, записи будут признаны различными.

Ещё более сложный комплекс проблем возникает при различном заполнении полей «Заглавие» и «Автор». Для многих каталогизаторов существенной проблемой является определение заглавия и сведений, относящихся к заглавию. Ошибки при описании нормативных документов допускаются даже опытными сотрудниками. А в заглавиях журналов название журнала, номера серии и названия серии зачастую конструируются каталогизаторами достаточно произвольно.

Поле «ISBN/ISSN» могло было бы использоваться как основной инструмент для дедубликации, однако значительная часть публикаций, с которыми работают во многих локальных корпоративных проектах (университетские публикации, публикации регионов, дореволюционные издания) не имеет этих идентификаторов. ISBN/ISSN зачастую используются неправомерно, (для различных изданий одной книги) или произвольно (когда издательство проставляет ISBN другой книги). Поэтому в России ISSN/ISBN не придаётся большого значения и соответствующие поля зачастую не заполняются даже в записях научных библиотек.

Ещё одной проблемой являются опечатки, которые имеют место даже в ключевых полях. Совершенно одинаковые внешне записи могут с технической точки зрения различаться, так как вместо кириллической была использована латинская буква «С». Эти буквы соответствуют одной клавише клавиатуры и часто подменяют одна другую.

Таким образом, распространённая сегодня технология дедубликации по свертке является ограниченной. Она не может решить задачу создания поисковых индексов потенциально возможного при использовании автоматического режима качества.

Анализ используемых технологий и их ограничений позволяет очертить совокупность характеристик, которым должна соответствовать современная система формирования СК, ориентированная на потребности университетских сообществ:

1. совместимость с различными технологиями работы библиотек-партнёров;

2. низкая стоимость и низкие эксплуатационные издержки;

3. простота использования и настройки;

4. высокое качество дедубликации;

5. высокая скорость создания поискового индекса;

6. гибкость и расширяемость базовых функциональных возможностей.

2.6. Оптимизация формирования консолидированного поискового

индекса

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

Эффективность процесса создания сводных каталогов неотъемлемо связана с процессом автоматизированного получения данных из внешних источников и их обработки. Опыт создания ИС ЭКБСОН подтверждает, что ключевую роль в формировании консолидированного индекса играет не стандартизация записей в библиотеках-источниках, а их унификация на уровне системы сбора данных. Последняя должна быть как можно более универсальна и толерантна к возможным отклонениям от стандарта или проблемам временной неработоспособности серверов-источников. Поэтому предлагаемая здесь модель извлечения данных должна осуществлять процессы 1-10, описанные ранее в параграфе 2.3 -- «2.3. Оптимизация модели распределённого поиска».

В то же время, ключевым процессом, определяющим качество создания консолидированного индекса, является дедубликация записей. Основной составляющей этого процесса является проверка идентичности вновь добавляемых в поисковый индекс записей и записей уже имеющихся в поисковом индексе. По мере увеличения размеров индекса количество операций сопоставления записей также увеличивается в геометрической прогрессии. Поэтому сопоставление всех записей с вновь добавляемой представляется невозможным, а использование библиографической свёртки, как было показано выше, не обеспечивает достаточной надёжности технологии. Кроме того, как правило, поисковый индекс с библиографическими свёртками формируется в БД параллельно с другими поисковыми индексами, которые не применяются для дедубликации и ориентированы на читателей. Формирование этих индексов существенно замедляет добавление записей и поиск по БД.

Решением данной проблемы, предлагаемым автором, является создание полностью автономного поискового индекса, включающего лишь данные необходимые для задачи дедубликации. Индекса, специально ориентированного для поиска по всей совокупности элементов, а также для поиска по отдельным элементам. Такой индекс с упрощёнными поисковыми образами библиографических записей можно назвать метабиблиографическим.

Анализ проблем дедубликации (например, [80]) при использовании библиографических сверток позволяет предложить новый алгоритм дедубликации. Ключевую роль в этом алгоритме играет работа с метабиблиографическими образами, а не с библиографическими записями. В нём предусмотрена следующая последовательность операций.

1.Формально-логический контроль записи. Выполняется, чтобы определить соответствие записи минимальным требованиям. В случае, если запись по каким-то причинам не содержит базового набора элементов, она вообще не анализируется и рассматривается как бракованная. Например, не может быть записи без поля «Заглавие».

2.Формально-логический контроль полей. До того, как проверять запись на дублетность, каждое существенное для дедубликации поле должно проходить формальный контроль на корректность содержимого.

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

Вторым этапом может быть хэширование. Все текстовые поля преобразуются к хэшам. Особенностью этих хэшей является то, что сравнение двух хэшей (цифр), полученных из полей разных записей, позволяет не только определить идентичность закодированных в них строк, но и выявить незначительные отличия этих строк путём использования простых математических операторов (равно, больше или меньше). Если стандартное (например, по алгоритму Левенштейна) определение подобия двух строк, отличающихся одной опечаткой, обычно требует больших вычислительных ресурсов (необходимо посимвольно сравнивать эти строки), то при такой технологии для сравнения достаточно лишь одной математической операции. Каталогизатор может добавить лишнюю букву, пропустить одну букву, или заменить одну букву другой - все эти типичные ошибки обрабатываются. Кроме того, алгоритм позволяет различить полную идентичность и подобие строк, за счёт чего появляется возможность более точно диагностировать дублетность на следующих этапах.

Наряду со свёртками полей метабиблиографический образ содержит служебные данные, которые не имеют прямой связи с библиографией - адрес записи в БД и её «индекс качества». За счёт них реализуется возможность извлечения записи и выбора наилучшей записи.

4. Запись метабиблиографического образа. Как следует из описания алгоритма, создание метабиблиографического образа - достаточно ресурсоёмкая процедура. Поэтому её результат сохраняется и используется многократно. Когда в каталог добавляется новая запись, её вновь созданный метабиблиографический образ сравнивается с образом, уже подготовленным и сохранённым ранее.

Сохранение образа, в зависимости от размеров каталога, может выполняться либо в реляционной базе, либо в оперативной памяти. Применение внешнего хранилища снимает с процесса дедубликации целый ряд ограничений, заложенных в САБ, структуре поисковых индексов и алгоритмах их формирования. Во-первых, это избавляет от необходимости формирования ненужных с точки зрения дедубликации индексов и, следовательно, ускоряет процесс. Во-вторых, даёт возможность использования для формирования метабиблиографического образа алгоритмы, которые значительно сложнее стандартных алгоритмов создания индексов. В-третьих, позволяет избежать продолжительных и неоправданных операций записи новых данных обычно в относительно медленно работающую библиографическую СУБД.

5. Поиск дублетов по свертке метабиблиографической записи. Поскольку технология поиска по свертке остаётся самой быстрой, этот метод в описываемом алгоритме также должен применяться в первую очередь. Он даёт исключительно высокий эффект, так как позволяет определить соответствие более чем в 95% случаев. В то же время его недостатки легко нивелируются на следующем этапе.

6. Определение рейтинга соответствия. В том случае, если запись не была найдена по метабиблиографической свертке, начинает выполняться основной алгоритм. Его первым шагом является отбор минимально похожих записей, по небольшому набору полей, ошибки в которых маловероятны. Среди этих полей могут быть, например: «Вид записи», «Номер тома» и ISBN. Чем больше этих полей, тем выше будет скорость и тем ниже качество дедубликации.

После выполнения первичного поиска, каждый метабиблиографический образ из подмножества, полученного в результате первичного отбора, должен сопоставляться с образом базовой записи. При этом выделяется две степени соответствия: полная идентичность и подобие. Для буквенных полей подобными могут считаться поля с одной ошибкой. Для цифровых полей допустимая погрешность определяется индивидуально, также в цифровой форме. Например, погрешность в количестве страниц может достигать +-5 страниц. А для поля «Год издания» погрешность в принципе не предусмотрена.

В алгоритме должно учитываться значение каждого поля для диагностики дублетности. Значение совпадения полей «Год издания» и «ISBN», с этой точки зрения, совершенно различно.

Если же «Год издания» не совпадает, можно предположить, что записи представляют разные издания одной книги.

Такие характеристики, как «соответствие», «неполное соответствие», «несоответствие» сопоставлены с определённым (отрицательным или положительным) количеством баллов, в сумме которых (индексе соответствия) оценивается степень идентичности записей. Индекс соответствия в цифровой форме выражает степень идентичности записей. Записи признаются дублетными в том случае если индекс превышает определённую пользователем пороговую величину (например, 100).

Максимальная чувствительность алгоритма требуется при формировании корпоративных электронных библиотек. В этом случае может использоваться применяемый некоторыми агрегаторами электронных ресурсов (Summon, например) принцип «контент важнее публикации». Он постулирует: что поскольку для пользователя важен текст, а не печатная публикация, то «Евгений Онегин» 2010 года имеет такое же значение, что и «Евгений Онегин» 2011 года20. Поэтому для студента технического вуза, например, нет смысла формировать отдельные библиографические записи на эти публикации. Достаточно одной схематичной записи и одного текста. Такой подход сегодня мог бы быть продуктивным в университетах. Распространённые учебники насчитывают по 20 переизданий, часто стереотипных, каждое из которых обладает с точки зрения студента практически одинаковой ценностью, поэтому оцифровывать все издания не имеет смысла. В таких случаях единственной функцией системы формирования поискового индекса является корректная дедубликации исходя из «Автора» и «Заглавия».

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

20 Необходимо отметить, что такой подход не может претендовать на всеобщность и универсальность. Существуют различные редакции «Евгения Онегина», они снабжались различными предисловиями и примечаниями.

признаку. Это может быть авторитетность источника, размер записи, количество полей или совокупность нескольких характеристик. В каждом случае записи присваивается абстрактный цифровой «индекс качества», который в дальнейшем определяет её право выступать базовой записью.

Алгоритм должен предусматривать возможность настройки объединения для любых выбранных пользователем полей и подполей. Как минимум таких типов должно быть три.

Первый тип - «замена», когда одно значение неповторяющегося поля должно быть заменено на другое. Такой тип операции приемлем, например, для поля «Аннотация» когда аннотация более авторитетной организации (в соответствии с оценкой библиотеки, формирующей консолидированный поисковый индекс) должна заменять аннотацию менее авторитетной.

Второй тип - «добавление», когда повторяющееся поле дополняется ещё одним оригинальным повторением. Такой тип может использоваться, например, для поля «Ключевые слова», если важно сформировать наиболее полный поисковый образ документа.

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

8. Агрегация полных текстов (при их наличии) - важная задача, которая часто возникает при формировании консолидированных поисковых индексов. Агрегация полных текстов может реализоваться как для целей поиска, так и для целей создания сводных электронных библиотек. Выгрузка полных текстов источников потенциально возможна при наличии: 1) открытых ссылок на источники для выгрузки по протоколам HTTP или FTP; 2) при поддержке сервером источником одного из API выгрузки документов (например, API, реализованных в модулях САБ ИРБИС). В последнем случае применение API необходимо для аутентификации пользователя.

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

Таблица 4 Сравнение традиционной и оптимизированной модели формирования консолидированного поискового индекса

Традиционная модель Оптимизированная модель

Для дедубликации используется формируемый поисковый индекс Для дедубликации используется независимый поисковый индекс

Дедубликация выполняется в один шаг, с использованием библиографической свёртки Дедубликация выполняется в два шага с использованием как библиографической свёртки, так и поэлементного сравнения записей

Сравнение текстовых полей в целях дедубликации происходит исходя из их текстового контента Сравнение текстовых полей в целях дедубликации выполняется исходя из цифровых алкодов. Это позволяет выявлять частичное соответствие полей и определять отрицательный или положительный рейтинг соответствия.

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

2.7. Выводы

Анализ двух основных подходов к интегративному поиску: распределённого поиска и поиска по консолидированному индексу -- позволил выявить ограниченность каждого из них и предложить в настоящей работе оригинальные модели, при которых эта ограниченность может быть нивелирована.

Способом повышения эффективности поиска является отображение результатов поиска по мере получения новых данных и достоверная индикация прогресса. Минимизировать количество вводимой пользователем информации и снизить вероятность ошибок позволяет режим отображения результатов по мере ввода запроса.

Указанные требования к потребительским характеристикам поисковой системы позволили автору обосновать в настоящей работе необходимость использования нового подхода к распределённому поиску, включающему следующие принципы:

1. распараллеливание не только процессов поиска, но и процессов обработки полученных записей;

2. отображение не только релевантного, но и ассимилированного (полученного в результате выполнения более узких запросов) кэша;

3. контроль за состоянием серверов по ходу выполнения поисковых запросов с параллельной блокировкой неработоспособных серверов.

Диссертантом также была предложена и обоснована новая концептуальная модель формирования консолидированного поискового индекса, предполагающая:

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

2. создание автономного метабиблиографического поискового индекса, используемого исключительно для целей дедубликации и консолидации;

3. применение трёхступенчатого алгоритма дедубликации с возможностью настройки различных уровней чувствительности и учётом сематической значимости элементов.

Использование описанных выше моделей отражает потребности интегративного поиска на вузовских библиотечных порталах. Комбинация из двух моделей позволяет эффективно работать с разными типами источников и создаёт условия для реализации основанных на интегративном поиске сервисов.

Глава 3. Исследование интегративного поиска в типовой системе для построения вузовских библиотечных

порталов

3.1. Назначение и принципы реализации

На основе сформулированных ранее положений были выведены универсальные принципы и модели построения поисковых систем вузовских библиотечных порталов. Для целей практического тестирования этих моделей в рамках настоящего исследования была разработана универсальная программная платформа построения вузовских библиотечных сайтов и электронно-библиотечных систем -- J-ИРБИС 2.0. Технически J-ИРБИС 2.0 является модулем САБ ИРБИС 64. Одним из условий создания модуля было снижение технологического барьера для интеграции вузовских электронных ресурсов и реализации новых технологий на вузовских библиотечных порталах. Предусматривается возможность установки и базовой настройки модуля сотрудником библиотеки, не являющимся программистом или системным администратором. J-ИРБИС 2.0 инсталлируется как любое Windows приложение и предоставляет визуальный интерфейс настройки.

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

Можно выделить следующие области использования модуля:

1. реализация функций OPAC;

2. реализация функций ЭБС;

3. интеграция систем (см. Рисунок 4)

Сервисы

Система регистрации ВКР

Электронная библиотека

Электронная доставка документов

V

Пользов

Портал библиотеки

Сервисы

Библиопрезентации

Средства интеграции с АСУ вуза

Система поиска в электронном каталоге (ОРАС)

Система автоматизации библиотек

Корпоративные каталоги и Подписные полнотекстовые БД электронные библиотеки

Рисунок 4: Пример структуры портала на основе 1-ИРБИС 2.0

БД учебного плана и Электронные каталоги контингента студентов и картотеки

Для реализации поисковых функций в .1-ИРБИС 2.0 в предусмотрена возможность использования сводно-распределённой модели интегративного поиска.

3.2. Функциональные возможности

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

1. поиск с выводом результатов по мере ввода запроса;

2. поддержка устройств с сенсорным вводом - телефонов, планшетов и информационных киосков;

3. параметрирование формата отображения библиографических описаний на уровне отдельных элементов (полочный шифр, аннотация, систематические индексы и т.п.);

4. комментирование публикаций и их оценка по пятибалльной шкале;

5. отображение обложек, полученных из интернета по ходу поиска средствами сервисов Google;

6. выполнение одновременного поиска в нескольких базах данных (локальных и внешних) с объединением результата и единообразным представлением записей;

7. реалистичная индикация прогресса при выполнении поискового процесса;

8. автодополнение при заполнении полей поисковой формы на основе словарей;

9. печать на принтере, сохранение в файл или отправка по E-mail библиографических списков;

10. получение списков рекомендуемой преподавателями литературы в конкретный момент обучения с учётом учебного плана;

11. постраничный просмотр PDF и браузерный просмотр мультимедийных файлов;

12. показ слайд-шоу для демонстрации новых поступлений на информационных панелях и в отдельных блоках интерфейса;

13. поддержка подсистемы описания и подключения полного текста выпускных квалификационных работ.

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

1. автоматическая инсталляция новых версий и обновлений модуля без изменения настроек пользователя и дизайна;

2. поддержка визуального интерфейса панели управления;

3. поддержка виртуальных баз;

4. поддержка индивидуализированных поисковых форм для всех баз;

5. разграничение прав доступа на уровне БД и отдельных полнотекстовых документов.

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

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

Особенностью J-ИРБИС 2.0, тесно связанной с концепцией интегративного поиска, является поддержка не только физических, но и логических ("виртуальных") баз. Они отображаются в интерфейсе так же, как физические, но при этом включают логически выделенные из внутренних и (или) внешних источниках массивы записей. Например, виртуальная база «Электронная библиотека» может фактически обеспечивать выборку всех записей нескольких локальных и удалённых баз, к которым подключены электронные версии.

Модуль поддерживает различные модели организации интегративного поиска. Он может применяться для полностью автоматизированного создания сводных каталогов [62], а также использоваться для реализации распределённого поиска. Распределённый поиск в J-ИРБИС 2.0 является функцией ядра поисковой системы.

Реализация полнотекстового поиска в модуле тесно связана с поиском библиографическим. Синтаксис полнотекстовых запросов здесь является подмножеством синтаксиса запросов библиографического поиска. Это нивелирует различия между поисками и позволяет выполнять их как независимо, так и вместе. Поскольку не существует унифицированных протоколов распределённого полнотекстового поиска [37], J-ИРБИС 2.0 реализует эту технологию лишь для серверов на базе САБ ИРБИС 64. TCP/IP сервер ИРБИС 64 выполняет традиционные для полнотекстового поиска функции, включающие ранжирование текстов и страниц по релевантности, выделение условного контекста страницы, связывание с библиографическими описаниями и многие другие.

Модуль предусматривает возможности разграничения прав на способы использования документов. Здесь реализован постраничный просмотр PDF и браузернное проигрывание мультимедийных файлов без права выгрузки. Для каждого PDF файла могут быть заданы следующие параметры:

1. доступность только для конкретной категории пользователей (например: преподаватель, сотрудник библиотеки, студент, аспирант и др., сформулированные библиотекой);

2. доступность только в локальной сети организации;

3. доступность полной выгрузки;

4. доступность постраничного просмотра или проигрывания в браузере;

5. доступность копирования текста в режиме постраничного просмотра;

6. доступность печати.

Режим постраничного просмотра автоматически оптимизируется в зависимости от того, на каком устройстве он используется.

Использование корпоративных электронных коллекций может быть осуществлено различными путями. Например, путём использования относительно простой технологии перенаправления пользователя по ссылке, предоставленной владельцем ресурса. Но если в корпорации библиотек, работающих в САБ ИРБИС64, действуют единые правила, разрешающие доступ к документам как локальным, так и удалённым пользователям, существует возможность реализации защищенного просмотра.

Условием доступа к ресурсам является аутентификация пользователя по локальной БД читателей (т.е. по БД на сервере распределённого поиска). При этом определяется категория пользователя и соответствующие ей права доступа. В случае, если условия доступа в локальной системе и удалённой системе (сервере-источнике) идентичны, пользователь получает доступ к удалённому документу. Если категория пользователя не совпадает ни с одной из тех, которые указаны в записи удалённого сервера, доступ к документу запрещается.

В случае предоставления прав на чтение документа найденный пользователем файл извлекается средствами удалённого сервера и копируется на локальный сервер. Здесь формируется его временная копия, которая в режиме on-line преобразуется в защищенный вид и отображается пользователю. При этом ресурсоёмкая операция формирования полного защищенного образа документа не требуется.

Аналогичный режим может использоваться при выполнении поиска в локальных базах и при работе с полнотекстовыми документами, подключёнными к записям.

3.3. Компоненты и архитектура

3.3.1. Программная платформа

J-ИРБИС 2.0 - это программный пакет, включающий Apache, MySQL, PHP и CMS Joomla! с набором расширений. Специфические функции, ориентированные на потребности библиотек, реализованы в компонентах, плагинах и модулях CMS Joomla! Тем не менее, поисковая система относительно независима и может использоваться автономно от CMS.

В качестве независимых расширений CMS выступают также:

1. плагин сквозной авторизации в CMS Joomla! и библиотечной подсистеме;

2. компонент, плагины и модули статистики;

3. плагин и модуль сенсорного интерфейса;

4. компонент и модуль библиослайдера.

Интерфейс J-ИРБИС 2.0 построен на основе технологии AJAX с использованием библиотеки JQuery и фреймворка JQueryUI. Результаты поиска и опциональные элементы библиографического описания загружаются динамически без перезагрузки страницы.

3.3.2. Интерфейс

Интерфейс J-ИРБИС 2.0 выступает не только средством отображения результатов поисковой системы, он детерминирует архитектуру системы поиска. Средствами front-end программирования (Java Script) во многом контролируется логика поискового процесса.

Технология вывода результатов по мере ввода запроса (перманентный поиск) обусловила специфику технологии кэширования. Потребность в информировании читателя о ходе выполнения запроса определила необходимость достоверной индикации прогресса. Представление записей как гибкого (кастомизируемого) набора элементов потребовало изменения традиционного взгляда на библиографическое описание как на унитарный элемент.

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

Рисунок 5: Пример типового интерфейса J-ИРБИС 2.0

Основные индикаторы отражают количество полученных и обработанных порций записей. Дополнительный индикатор показывает, что в текущий момент выполняется HTTP запрос на получение данных.

Отображение записей параметрируется пользователем и администратором системы на уровне отдельно взятой записи и на уровне результатов поиска в целом.

Здесь, как и во многих OPAC, предусмотрена возможность выбора пользователем форматов отображения записей (полный, краткий, с подписями). Но при этом, по умолчанию, часть объёмных элементов каталожной карточки (аннотация, предметные рубрики, ключевые слова и др.) не отображается. Они добавляются в библиографическое описание по запросу пользователя (при нажатии кнопки в библиографическом описании). В то же время, если пользователь нуждается в детализированных библиографических описаниях постоянно, он может настроить для собственных нужд профиль отображения записей. Требуемый набор данных фиксируется системой и используется при каждом обращении пользователя к сайту.

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

Если пользователю А потребовалось представить набор элементов A1, а пользователю Б представить набор элементов Б1, то А между этими наборами будет получена в результате преобразования кэшированной ранее записи. Исходная запись извлекается из кэша, система анализирует, какие элементы описания требуется дополнительно сформировать, формирует их, добавляет элементы в кэш, а затем запись выводится пользователю.

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

Для каждой БД может быть предусмотрен специфический набор форм поиска с индивидуальным перечнем полей. Потребность в этом обусловлена частым разделением БД по типу содержащегося в них контента (например, журналы, диссертации, статьи). Если пользователем выбрано несколько разнородных баз, будут использоваться универсальные формы. Если выбрана база с конкретным контентом, будет использоваться форма,

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

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

3.3.3. Извлечение, обработка и агрегация данных (провайдеры данных)

Общим элементом как системы распределённого поиска, так и системы поиска по консолидированному массиву является инструментарий для извлечения и обработки записей. В случае с распределённым поиском он применяется в момент выполнения поиска. В случае с поиском по консолидированному массиву - для сбора данных.

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

Серверы (библитеки-источники) О

Идентификатор библиотеки л Тип подключения Адрес сервера Порт сервера Логин Пароль Полное название библиотеки Краткое название библиотеки Порядок обращения Таймаут подключения

1 iserver&4 localhost 6666 1 1 ИСК НТЛ Поте 2000 А

21 IZ39 rsl.gbs.spb.ru 210 Библиотека для слепых (СПб) Библиотека слепых 6000

22 iz39 aleph.rsl.ru 9909 Российская государственная библиотек РГБ 2000

23 IZ39 z3950.loc.gow 7090 Библиотека конгресса США Библ.конгресса 2000

24 iz39 z3950.Knigafund.ru 9999 Электронно-библиотечная система Кни ЭБС Книгафонд 2000

25 IZ39 nDmgu.ru 210 Научная библиотека МГУ НБ МГУ 2000 V

< щ ф + / В 0 Просмотр! -6 изб

tr

Базы исто нников и их X эрактеристики 0

Имя базь (техническое) Название базы (полное) Окончание паузы обращений Количество проблемных обращений Запрос, формирующий виртуальную базу Идентификаторы интегрируемь Специальный гр

RSK ИСКНТИ 2016-03-03 21:30:11 Редактировать Редактировать

knigafund ЭБС Книгафонд 2016-08-07 20:09:49 Редактировать Редактировать

book НБ МГУ 2015-06-16 05:22:33 Редактировать Редактировать

plain Библиотека для слепых (СПб.) 2016-06-21 13:29:08 Редактировать Редактировать

rsl01 Российская государственная биб! 2016-05-14 03:01:47 Редактировать Редактировать

voyager Библиотека конгресса 2014-09-16 11:09:17 Редактировать Редактировать V

< i l Ф + / M ® > Просмотр 1 - 6 и 6

Рисунок 6: Таблицы баз и таблицы серверов

Для каждой БД может быть установлен свой набор форматов представления записей или поисковых форм переопределяющих стандартные.

На основе комбинации данных из таблицы источников и таблицы БД строится представление об источниках, используемое провайдерами (коннекторами). Провайдеры (коннекторы) в J-ИРБИС 2.0 интегрированы с системой конвертирования и унификации данных, поэтому наряду с получением данных выполняется преобразование их формата и кодировки. Провайдеры поддерживают форматы RUSMARC, UNIMARC, USMARC, корректно обрабатываются кодировки UTF-8, Windows 1251, ISO-8859-1.

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

Результатом работы любого провайдера является массив объектов записей (объект типа jRecord), включающих как набор полей, так и определённые профилем пользователя элементы библиографических описаний (полочный шифр, аннотация, предметные рубрики и т.д.). При необходимости, чтобы уменьшить объём кэша, из записей извлекаются интегрированные версии обложек. Они сохраняются в виде файлов в специальном хранилище.

В J-ИРБИС 2.0 предусмотрено несколько провайдеров:

1. провайдер для доступа к ИРБИС TCP/IP серверу;

2. провайдер для доступа к модулю Web-ИРБИС;

3. провайдер для доступа к Z39.50 серверам.

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

3.4. Режим распределённого поиска

Алгоритм распределённого поиска в J-ИРБИС 2.0 основан на работе трёх асинхронных процессов: процесса отображения (далее Output), процесса распределённого поиска и контроля (далее Broadcast Search), процесса поиска в конкретном источнике и кэширования (далее Single Search) (см. Рисунок 7). Интегрирующим звеном между процессами выступает поисковая

сессия (далее Session), которая в отличие от обычной PHP сессии, блокируется лишь на время осуществления записи. В остальное время работа с ней ведётся в режиме чтения.

Запрос

усп

ен?

Рисунок 7: Принципиальная схема процесса распределённого поиска

Broadcast Search - процесс, который запускается сразу после инициализации поиска и завершается после опроса всех серверов-источников. При включённом режиме поиска, инициализируемого автоматически, по мере ввода запроса пользователем, это происходит через незначительные промежутки времени (по умолчанию - одна секунда) после того как пользователь прекращает ввод запроса и делает паузу. Если пользователь начинает ввод нового запроса, не дождавшись завершения предыдущего, AJAX запрос прерывается и начинается выполнение нового процесса. Но прерванный процесс поиска продолжает выполняться на сервере, осуществляя кэширование данных, которые могут быть востребованы в дальнейшем.

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

J-ИРБИС 2.0 добавляет к стандартным поисковым возможностям САБ ИРБИС 64 (усечение, объединение логическими операторами, морфологическое расширение и др.) ряд дополнительных опций. Например, нормализацию данных об авторах, реконструкцию ISBN (если последний вводится некорректно), опцию разбивания фраз на термины и исключения неинформативных элементов (предлоги, союзы и т.д.).

Три таблицы БД используются для целей кэширования записей и хранения технической информации о результатах выполнения запросов. В специальной таблице фиксируются сведения об источнике, запросе, общем количестве найденных записей по запросу и количестве извлечённых записей.

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

Если полностью соответствующий запросу кэш не найден, предпринимается попытка выборки родственных запросов. Например, при поиске по термину "история", такими запросами будут "история России", "история Франции" и т.п. Кэш родственных запросов

предоставляется пользователю в первую очередь. Это позволяет сразу работать с результатами поиска или уточнить запрос. Поисковый процесс на время получения кэша по родственным запросам (далее «ассимилированного кэша») не прерывается, так как презюмируется, что пользователя заинтересуют полные результаты поиска.

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

Распределённый поиск реализуется путём запуска группы параллельных запросов к локальному WEB-серверу средствами расширения c URL. Каждый из процессов получает в качестве исходных данных адресную информацию определённого физического сервера, а также начальный и конечный номер записи, которые требуется выгрузить. Процессы поиска возвращают Broad Search в качестве результата лишь информацию о количестве полученных данных или возникших при выполнении запроса ошибках. Записи, являющиеся результатами поиска, кэшируются Single Search автономно от Broad Search.

Single Search - процесс, который инициируется Broad Search для выполнения наиболее ресурсоёмких операций поиска, извлечения, конвертирования и кэширования записей. Процесс предполагает работу только с одним источником, поэтому его выполнение начинается с выбора провайдера данных.

Процесс не только фиксирует ошибки, но и обрабатывает их. Ошибки интерпретируются как критические или эпизодические. В случае возникновения ряда эпизодических ошибок, обусловленных, например, перегрузкой сервера, запрос повторяется в исходном виде. После этого, если результат так и не был получен, а ошибка повторилась, сервер блокируется. Критические ошибки приводят к немедленной блокировке сервера. Если сервер оказался доступен, а счётчик блокировок имеет ненулевое значение, он обнуляется.

Информация о статусе сервера представлена двумя полями таблицы БД источников -полем "Дата окончания блокировки" и полем счётчиком "Количество неудачных обращений". Каждое неудачное обращение увеличивает значение счётчика. Дата окончания блокировки увеличивается экспоненциально, исходя из количества неудачных обращений. Таким образом, решается как вопрос временных сбоев, так и продолжительной неработоспособности сервера.

Output - процесс, инициируемый на уровне поискового интерфейса в браузере, который выполняется рекурсивно с момента запуска Broad Search и до его завершения. Роль данного

процесса заключается в выводе кэшированных в реляционную БД записей и текущего статуса выполнения запроса исходя из данных Session - специальной сессии поискового сеанса.

Основная функция Output - генерация искусственных пауз, позволяющих обеспечить компромисс между скоростью вывода данных, оперативностью индикации прогресса и нагрузкой на БД.

В зависимости от требований клиента в ходе выполнения Output записи могут выводиться в порядке их кэширования или в режиме сортировки. Тем не менее, сортировка реализуется только в ситуации, когда это оказывается целесообразно с точки зрения эффективности поиска. По умолчанию сортировка выполняется не более чем для 200 записей в режиме просмотра и не более чем для 2 тыс. записей в режиме печати.

3.5. Экспериментальная оценка эффективности алгоритма

распределённого поиска

3.5.1. Тестирование эффективности кэширующей системы

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

Для целей определения сравнительной эффективности кэша тестирование велось с подключением одной базы электронного каталога в режиме распараллеливания запросов. В результате каждой поисковой операции формировалось 2 параллельных запроса, выполняющих поиск, извлечение, расформатирование (в соответствии с ГОСТ 7.1-2003) и кэширование записей. Каталог включал 45 тыс. библиографических записей. Для моделирования была использована последовательность из 7 тыс. запросов, зафиксированных статистическим модулем J-ИРБИС 2.0 Санкт-Петербургского государственного университета телекоммуникаций в 2015 году.

Поисковая система функционировала на сервере следующей конфигурации: виртуальная машина на основе Intel Xeon E5450 CPU 3GHz, RAM 6 000 Mb, Virtual Disc 400 Gb.

Рисунок 8: Скорость вывода при использовании стандартного и ассимилированного кэша

Рисунок 9: Скорость вывода без ассимиляции кэша

Рисунок 10: Скорость вывода без кэширования

Диаграммы на рисунках 8-10 демонстрирует эффективность добавления дополнительных режимов кэширования. Они показывают, как по мере увеличения количества запросов в режимах, предполагающих кэширование, уменьшается время, затрачиваемое на поиск/вывод результатов. Скорость поиска для каждой группы запросов по 500 записей определялась по наиболее типичному значению (медиане).

Диаграммы демонстрируют достаточно высокую эффективность простого кэширования и меньшую, но заметную эффективность ассимилирующего кэширования. При условии преобладания запросов с морфологическим расширением, когда изменение любого символа даёт принципиально новую форму запроса, эффективность ассимилирующего кэширования ниже потенциальных значений. В то же время демонстрируется высокая эффективность кэширующей системы в целом. При условии, что объём кэша составляет около 10 тыс. записей, она доходит до 1000 %.

Среднюю эффективность использования кэша демонстрирует диаграмма на рисунке 11. Кэширование позволяет повысить скорость отображения результатов на 700%

Рисунок 11: Различие в скорости при использовании кэширующей системы

3.5.2. Тестирование эффективности технологии первичного вывода

Анализ изменения скорости поиска за счёт вывода результатов при получении новых данных проводился как в режиме локального электронного каталога (при выполнении поиска по одной библиографической базе общим объёмом 60 тыс. записей), так и в корпоративном режиме, когда одновременно запрос выполнялся по пяти открытым источникам (см. Таблица 3).

Таблица 5 Источники записей

Название источника Адрес

1. РСК НТЛ г8к.§рп1;Ь.т:80/г8к

2. Научная библиотека МГУ пЬш§ц.ги:210/Ьоок

3. Электронный каталог библиотеки Конгресса z3950.loc.gov: 7090^оуа§ег

4. Электронный каталог Библиотеки для слепых и слабовидящих (СПб.) п81^Ь8.8рЬ.ги:210/р1ат

5. Электронный каталог РГБ а1ерЬ.ге1.ги:9909/ге101

9

8 8,10715

СЕКУНДЫ

□ Средняя скорость первичного вывода при локальном поиске

□ Средняя скорость завершения процесса при локальном поиске

□ Средняя скорость первичного вывода при распределённом поиске

□ Средняя скорость завершения процесса при распределённом поиске

Рисунок 12: Различие в скорости первичного и финального вывода

Как показывает диаграмма на рисунке 12, если при локальном поиске различие в скорости первичного вывода и вывода итоговых результатов незначительны (особенно если в поиске участвует одна физическая БД), то при распределённом поиске оно достигает увеличения в 14 раз или 7.4 сек. Эффективность технологии оказывается тем выше, чем больше

различия в скорости отклика самого медленного и самого быстрого сервера. Таким образом, предложенный подход к выводу результатов при выполнении распределённого поиска может считаться исключительно эффективным.

3.6. Режим формирования консолидированного поискового индекса

В ряде случаев ограничения, описанные в разделе 2.2.1 настоящей диссертации, являются серьёзным препятствием для организации интегративного поиска. Поэтому вместо или вместе с распределённым поиском часто применяется поиск по консолидированному поисковому индексу. Для этого записи выгружаются из удалённых источников и консолидируются.

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

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

После конвертирования средствами ИРБИС TCP/IP сервера, для записи создаётся метабиблиографический образ.

3.6.1. Фильтрация, формально-логический контроль и предварительная

обработка записей

Инициация создания КПИ пользователем

Получение записи из каталога библиотеки-источника

Извлечение следующей записи'

Да

Поиск дублетов по свертке метабиблиографической записи Создание метабиблиографического образа Фильтрация полей, не соответствующих требованиям качества