МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ РАЗРАБОТКА И АНАЛИЗ ГЕТЕРОГЕННОЙ БАЗЫ ДАННЫХ НА ОСНОВЕ СУБД ORACLE И MONGO DB

Save this PDF as:
 WORD  PNG  TXT  JPG

Размер: px
Начинать показ со страницы:

Download "МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ РАЗРАБОТКА И АНАЛИЗ ГЕТЕРОГЕННОЙ БАЗЫ ДАННЫХ НА ОСНОВЕ СУБД ORACLE И MONGO DB"

Транскрипт

1 Министерство образования и науки Российской Федерации федеральное государственное автономное образовательное учреждение высшего образования «Санкт-Петербургский политехнический университет Петра Великого» Институт компьютерных наук и технологий Кафедра «Компьютерные интеллектуальные технологии» Проект допущен к защите Директор ИКНТ, проф., д.т.н. Заборовский В.С. 201_ г. МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ РАЗРАБОТКА И АНАЛИЗ ГЕТЕРОГЕННОЙ БАЗЫ ДАННЫХ НА ОСНОВЕ СУБД ORACLE И MONGO DB направление: «Математическое обеспечение и администрирование информационных систем» программа подготовки магистров «Разработка и администрирование систем управления базами данных» Выполнил: Филитович Владимир Александрович Подпись Руководитель: доцент, к.т.н., Сабинин Олег Юрьевич Подпись Санкт-Петербург 2017

2 РЕФЕРАТ Магистерская диссертация содержит 72 с., 13 рис., 29 источника, 2 прил. Тема: Разработка и анализ гетерогенной базы данных на основе СУБД Oracle и MongoDB. Ключевые слова: гетерогенная система баз данных, SPARQL, формат RDF, документно-ориентированная модель данных, поршневые расходомеры, EC2, федеративные базы данных. Объектом исследования являются гетерогенные распределенные системы баз данных. Цель работы разработать архитектуру и запустить в работу промышленную гетерогенную систему баз данных, а также проверить ее работоспособность на тестовой схеме. В процессе работы проводились экспериментальные исследования аналогичных систем, а также системы, сконструированной рамках работы. В результате исследования была создана архитектура и прототип универсальной гетерогенной системы, позволяющей интегрировать между собой базы данных, поддерживающие разные модели данных. Основные конструктивные и технико-эксплуатационные показатели: универсальность и сравнительная простота системы Степень внедрения в рамках работы была разработана архитектура системы, также в работу предприятия был внедрен ее прототип. Эффективность установок определяется их работы с помощью метрики, учитывающей среднее количество обработанных статей на оператора, была отобрана фокус-группа для двухмесячного тестирования (производительность фокус-группы выросла на 8.4%)

3 СОДЕРЖАНИЕ РЕФЕРАТ... 2 ВВЕДЕНИЕ АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ Определение и классификация гетерогенных систем Разбор задач, требующих использования гетерогенных баз данных Проблемы проектирования и реализации гетерогенных систем Обзор и анализ современных средств разработки гетерогенных систем Формулировка целей и задач выпускной работы АНАЛИЗ ОСОБЕННОСТЕЙ СОЕДИНЕНИЯ SQL И NOSQL СУБД Особенности MongoDB Исследование существующих аналогов Система ADDS компании Amoco Система DATAPLEX компании General Motors Corporation IMDAS Национальный институт стандартов и технологий (NIST) Интерфейсы приложений системы и функциональные требования Разработка архитектуры гетерогенной SQL-NoSQL системы НАСТРОЙКА ГЕТЕРОГЕННОЙ СИСТЕМЫ Обоснование выбора облачного сервиса для гетерогенной системы Особенности настройки D2RQ для Oracle Настройка AllegroGraph для MongoDB Модели данных в приложениях Компоненты и настройка сервера-медиатора Оценка снижения трудозатрат компании-заказчика ЗАКЛЮЧЕНИЕ СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ Приложение Приложение

4 ВВЕДЕНИЕ Сегодня существует множество стандартов, протоколов и технологий и во многом создание современных систем заключается в грамотном подборе и интеграции имеющихся решений. Безусловно, остается и место разработке индивидуальных модулей для обеспечения корректного взаимодействия компонентов производимых систем. В этой работе рассматривается и решается задача создания такой комплексной системы, как гетерогенная база данных, объединяющая в себе две принципиально различные базы Oracle и MongoDB, придерживающие разных парадигм представления и хранения данных. В первой главе будет разобрано понятие гетерогенных баз данных, пояснены трудности их разработки, представлены задачи, для которых они актуальны, а также произведен обзор средств их разработки. Во второй главе проведен детальный сравнительный анализ существующих подобных систем, и сделаны выводы исходя из опыта пользователей об эффективности их архитектур. В третьей главе расписана реализация архитектуры системы, предлагаемой для решения задачи, поставленной в рамках этой работы. 4

5 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ В этой главе будут рассмотрены основные проблемы, возникающие в процессе разработки и развертывания гетерогенных систем баз данных, и перечислены некоторые инструменты их решения. Также в главе будут указаны определения и ключевые понятия, необходимые для понимания рассматриваемой области. 1.1 Определение и классификация гетерогенных систем Системы гетерогенных баз данных (HDB) это вычислительные модели и программные реализации, которые обеспечивают гетерогенную интеграцию распределенных баз данных для представления пользователю единого унифицированного интерфейса запросов [17]. Базы данных, входящие в состав системы, могут не поддерживать единую модель данных или являться продуктами разных вендоров. Распределенная система баз данных (distributed database)- это база данных или система гомогенных баз данных, компоненты которой хранятся в нескольких физических местах, а обработка распределяется между несколькими вычислительными узлами. Непрерывная интеграция это практика разработки программного обеспечения DevOps, при которой разработчики регулярно объединяют изменения программного кода в центральном репозитории, после чего автоматически выполняется сборка, тестирование и запуск [8]. Понятие непрерывной интеграции чаще всего применяется к стадии сборки или интеграции процесса выпуска ПО и включает в себя как компонент автоматизации (например, сервис непрерывной интеграции или сборки), так и компонент культуры разработки. Главная задача непрерывной интеграции быстрее находить и исправлять ошибки, улучшать качество ПО и сокращать 5

6 временные затраты на проверку и выпуск новых обновлений ПО. При непрерывной интеграции часто используются репозитории и системы контроля версий, например Git. Непрерывная доставка это практика разработки программного обеспечения DevOps, когда при любых изменениях в программном коде выполняется автоматическая сборка, тестирование и подготовка к окончательному выпуску [5]. Непрерывная доставка расширяет практику непрерывной интеграции за счет того, что все изменения кода после стадии сборки развертываются в тестовой и/или в рабочей среде. При правильном внедрении непрерывной доставки у разработчиков всегда есть готовый к развертыванию собранный экземпляр ПО, прошедший стандартизированную процедуру тестирования. При непрерывной доставке каждое изменение программного кода проходит сборку, тестируется и затем отправляется в подготовительную (тестовую или имитационную) среду. Перед развертыванием в рабочей среде можно использовать несколько параллельных стадий тестирования [18]. На последнем шаге, если подготовительная стадия прошла успешно, разработчик разрешает развертывание обновления в рабочей среде. Этот процесс отличается от непрерывного развертывания, при котором развертывание в рабочей среде происходит автоматически, без явного подтверждения разработчика. Документоориентированная модель данных предназначена для хранения иерархических структур данных (документов) и обычно реализуется с помощью подхода NoSQL, также применяется при создании документоориентированных СУБД [6]. В основе лежат документные хранилища (document stores), имеющие древовидную структуру. Структура дерева начинается с корневого узла и может содержать несколько внутренних и листовых узлов. Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, что позволяет даже при достаточно сложной структуре находить место (путь) искомых данных. API для поиска позволяет находить по запросу документы и части документов. В отличие от хранилищ 6

7 типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память. Гетерогенные системы могут включать в себя ряд различных типов гетерогенности: Различные аппаратные средства (физические компоненты хостов) [2]. Разные аппаратные средства могут использовать разные представления данных, например, различные коды символов или различные представления для чисел с плавающей запятой. Различные операционные системы. Также как и отличающиеся аппаратные средства, разные операционные системы могут влечь за собой различие в представлении данных. Cвязи требуют шлюзов, и их может быть трудно реализовать из-за различных возможностей, которые имеются в наличии [1]. Например, один протокол может снизить прерывание сеанса вне диапазона, а другой нет. Разное программное обеспечения баз данных (от разных вендоров). Различные производители СУБД могут использовать разные языки определения данных и манипулирования данными, даже если они используют одну и ту же модель данных. Различные модели данных. Различные модели данных могут представлять сложный перевод схемы и проблему перевода запроса, особенно если важна производительность. SPARQL (Protocol and RDF Query Language) является языком запросов RDF, то есть семантическим языком запросов к базам данных, способным извлекать данные, хранящиеся в Resource Description Framework (RDF), и манипулировать ими [5]. Он стал стандартом рабочей группы RDF по доступу к данным (DAWG) консорциума World Wide Web Consortium и признан одним из ключевых технологий семантической сети. Федеративные базы данных термин получил распространение благодаря исследователям профессору Амите Шету и доктору Полу Ларсону. 7

8 Они определяют Федеративную базу данных как набор взаимодействующих компонентных систем, которые являются автономными и, возможно, гетерогенными [2]. Три важных компонента FDBS автономия, гетерогенность и распределение. 1.2 Разбор задач, требующих использования гетерогенных баз данных Перечислим и поясним несколько задач, для решения которых полезно использовать распределённые гетерогенные системы: Распределение и автономность бизнес-единиц. В современных организациях подразделения, отделы или команды часто удалены географически друг от друга на большие расстояния (и, возможно, на международном уровне) [3]. Зачастую каждое подразделение имеет право создавать свои собственные информационные системы, над которыми они могут иметь контроль, и эти подразделения хотят получать локальные данные без задержек. Бизнес-слияния и поглощения часто создают такую среду. Обмен данными. Даже в случае умеренно сложных бизнес-решений требуется совместное использование данных между бизнес-единицами, поэтому должно быть удобно консолидировать данные по локальным базам данных по требованию. Стоимость передачи данных и надежность. Стоимость доставки больших объемов данных по сети или обработки большого объема транзакций из удаленных источников может быть высокой. Часто более экономично хранить данные и приложения рядом с тем местом, где они нужны. Кроме того, зависимость от передачи данных может быть рискованной, поэтому хранение локальных копий или фрагментов данных может быть надежным способом поддержки необходимости быстрого доступа к данным по всей организации. Многообразие сред, используемых поставщиками приложений. Сегодня многие организации приобретают прикладное программное 8

9 обеспечение от нескольких разных поставщиков. Каждый из этих продуктов «лучший из лучших» и предназначен для работы с собственной базой данных и, возможно, с различными системами управления базами данных. Возможно, для части из них, можно настроить гетерогенную базу данных чтобы обеспечить функциональность, которая позволит работать различным приложениям. Восстановление базы данных. Репликация данных на отдельных компьютерах это одна из стратегий обеспечения быстрого восстановления поврежденной базы данных и доступа пользователей к данным при восстановлении основного сайта. Репликация данных на нескольких компьютерных узлах является естественной формой распределенной базы данных. Удовлетворение транзакционной и аналитической обработки. Требования к управлению базами данных различаются для приложений OLTP и OLAP. Тем не менее, одни и те же данные являются общими между двумя базами данных, поддерживающими каждый тип приложения. Технология распределенных гетерогенных баз данных может быть полезной при синхронизации данных на платформах OLTP и OLAP. 1.3 Проблемы проектирования и реализации гетерогенных систем В этом разделе будут перечислены основные проблемы проектирования, возникающие при построении распределенной гетерогенной системы. Проектирование системы. Проблема заключается том, каким образом база данных и приложения, которые запускаются и работают с ней, должны размещаться на серверах [4]. Существуют две основных варианта размещения данных: секционирование (нереплицированные данные) и реплицированные. В многораздельной схеме база данных делится на несколько непересекающихся разделов. Двумя основными проблемами проектирования 9

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

11 каждого элемента данных сходились к одному значению, называется взаимной согласованностью. Имеются два основных метода решения этой проблемы: пессимистичный и оптимистичный. При пессимистичном синхронизируют выполнение пользовательских запросов до начала выполнения[10]. При оптимистичном выполняют запросы, а затем проверяют, не нарушило ли их выполнение структуру и целостность базы данных. Два фундаментальных примитива, которые могут использоваться с обоими подходами, это блокировка, которая основана на взаимном исключении доступа к элементам данных, и отметке времени, где заказы на выполнение транзакций упорядочиваются на основе временных меток. Управление взаимоблокировкой (Deadlock). Конкуренция среди пользователей за доступ к набору ресурсов (в данном случае данных) может привести к взаимоблокировке, если механизм синхронизации основан на блокировке. Надежность СУБД. Одними из потенциальных преимуществ гетерогенной системы является повышенная надежность и доступность. Это, однако, не является данностью, и не настроено автоматически. Важно реализовать механизмы для обеспечения согласованности базы данных, а также для обнаружения сбоев и восстановления системы после них [27]. Смысл гетерогенной системы заключается в том, что когда происходит сбой и различные компоненты становятся или неработоспособными, или недоступными, базы данных на рабочих станциях остаются согласованными и обновленными. Кроме того, когда система или сеть восстанавливается после сбоя, гетерогенная система должна иметь возможность восстанавливать и накатывать или откатывать изменения до состояния до отказа. Это может быть особенно сложно в случае, когда система разделены на две или более групп, между которыми нет связи. Репликация. Если база данных реплицирована (частично или полностью), необходимо реализовать протоколы, обеспечивающие 11

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

13 директории (или директорий), а также стратегии, которые могут быть использованы для управления ими. Одна и та же информация (т.е. Структура фрагмента и его адрес) используется процессором запросов для определения стратегии оценки запроса. С другой стороны, шаблоны доступа и использования, определенные процессором запросов, используются в качестве входных данных для алгоритмов распределения данных и фрагментации. Точно так же размещение каталогов и их содержимое влияют на обработку запросов. Репликация фрагментов при их распространении влияет на стратегии контроля параллелизма, которые могут быть использованы. Некоторые алгоритмы управления параллелизмом не могут быть легко использованы с реплицированными базами данных. Аналогично, шаблоны использования и доступа к базе данных будут влиять на алгоритмы управления параллелизмом. Если среда требует интенсивного обновления, необходимые меры предосторожности сильно отличаются от тех, которые применяются в среде только для запросов. Между проблемой контроля параллелизма, проблемой управления взаимными блокировками и проблемами надежности существует сильная взаимосвязь. Этого следовало ожидать, поскольку при классификации их обычно называют проблемами управления транзакциями. Алгоритм управления параллелизмом определяет, требуется ли отдельное средство управления взаимоблокировкой. Если используется алгоритм, использующий как инструмент блокировку, то будут возникать взаимные блокировки. В противном случае нужно использовать отметки времени (timestamps). Механизмы надежности включают в себя как локальные методы восстановления, так и распределенные протоколы надежности. В этом смысле они оба влияют на выбор методов управления параллелизмом и строятся поверх них. Методы обеспечения надежности также используют информацию о размещении данных, поскольку наличие дубликатов копий данных служит гарантией для обеспечения надежной работы. Наконец, необходимость в протоколах репликации возникает, если распространение данных связано с 13

14 репликами. Как указывалось выше, между протоколами репликации и методами контроля совпадений существует сильная взаимосвязь, поскольку обе имеют дело с согласованностью данных, но с разных точек зрения. Кроме того, протоколы репликации влияют на методы распределенной надежности, такие как протоколы фиксации. 1.4 Обзор и анализ современных средств разработки гетерогенных систем Ниже будут перечислены программные продукты, среды разработки, сервисы и приложения, используемые для разработки и модернизации гетерогенных систем. Амазон Веб-службы (Amazon Web Services или AWS) представляют собой безопасную платформу облачных сервисов, которая предоставляет вычислительные мощности, доступ к хранилищам, базам данных, услугам доставки контента и другим функциональным возможностям, помогающим в масштабировании и развитии бизнеса. Веб-службы иногда называются облачными службами или удаленными вычислительными службами [29]. Amazon Elastic Compute Cloud (EC2) центральный сервис инфраструктуры Amazon Web Services, предоставляющий виртуальные сервера (Amazon EC2 Instance) и другие вспомогательные возможности (такие как балансировщик нагрузки), основной целью которых является конфигурирование и запуск вычислительных серверов [26]. Amazon EC2 позволяет создавать виртуальные машины (в терминологии Amazon «instance») с любым из предустановленных образов ОС (Amazon Machine Image, AMI) или со своим собственным образом ОС. Доступные AMI: Ubuntu, Windows Server 2003/2008 R2, Cent OS, Fedora, OpenSUSE и другие ОС. AWS предоставляет возможность выбора вычислительной мощности развертываемого в облаке EC2-инстанса. Доступны следующие типы EC2-14

15 инстансов: Micro Instances, Standard Instances, High-Memory Instances, High-CPU Instances, Cluster Compute Instances, Cluster GPU Instances. Кроме размера EC2-инстансов, AWS предоставляет возможность выбора географического региона, в котором EC2-инстанс запускается. Доступны следующие регионы: US East, US West (Oregon), US West (Northern California), EU, Asia Pacific (Singapore), Asia Pacific (Tokyo), South America. Docker это инструмент, который упрощает создание, развертывание и запуск приложений с помощью контейнеров (containers). Контейнеры позволяют разработчику упаковывать приложение со всеми необходимыми ему частями, например библиотеками и другими зависимостями, и поставлять его как один пакет [13]. Таким образом, благодаря контейнеру разработчик может быть уверен, что приложение будет работать на любом другом Linux-компьютере, независимо от каких-либо настраиваемых параметров, которые может иметь машина, и которые могут отличаться от машины, используемой для написания и тестирования кода. В некотором смысле Docker немного напоминает виртуальную машину. Но в отличие от виртуальной машины, вместо того чтобы создавать целую виртуальную операционную систему, Docker позволяет приложениям использовать то же самое ядро Linux, что и система, на которой они запущены. Это значительно повышает производительность и уменьшает размер приложения. Также Docker используется для тестирования работоспособности приложений и сборок. Chef инструмент управления конфигурацией, написанный на Ruby и Erlang. Он использует чистый Ruby, домен-специфический язык (DSL) для написания «рецептов» (recipes) конфигурации системы [15]. Шеф используется для упрощения задачи настройки и обслуживания серверов компании и может интегрироваться с облачными платформами, такими как: Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, Microsoft Azure и Rackspace для автоматического создания и настройки новых машин. Шеф-повар содержит 15

16 решения для небольших и крупных систем с функциями и ценами для соответствующих диапазонов. Пользователь пишет «рецепты», которые описывают, как Chef управляет серверными приложениями и утилитами (такими как Apache HTTP Server, MySQL или Hadoop) и как они должны быть настроены. Эти рецепты (которые могут быть сгруппированы вместе как «кулинарная книга» для упрощения управления) описывают ряд ресурсов, которые должны находиться в определенном состоянии: пакеты, которые должны быть установлены, службы, которые должны быть запущены, или файлы, которые должны быть записаны. Эти различные ресурсы могут быть настроены на конкретные версии программного обеспечения для запуска и могут гарантировать, что программное обеспечение установлено в правильном порядке на основе зависимостей. Шеф удостоверяется, что каждый ресурс правильно настроен, и исправляет любые ресурсы, которые не находятся в желаемом состоянии. Jenkins 2.0 это многофункциональное приложение для непрерывной интеграции (continuous integration) и непрерывной доставки (continuous delivery), которое повышает производительность системы [7]. Jenkins используется для создания и тестирования программных проектов. Эта программа облегчает разработчикам интеграцию изменений в проекте, а пользователям получение свежей сборки. Она также позволяет постоянно поставлять программное обеспечение, предоставляя мощные средства для определения конвейеров сборки и интеграции с большим количеством технологий тестирования и развертывания. Дженкинс был первоначально разработан как проект Хадсон. Создание Хадсона началось летом 2004 года в Sun Microsystems. Он был впервые выпущен на java.net в феврале 2005 года. В 2011 году переименован в Jenkins. Существует множество доступных плагинов для интеграции Jenkins с большинством систем контроля версий и больших баз данных. Многие инструменты сборки поддерживаются при помощи соответствующих плагинов. 16

17 Плагины также могут изменить внешний вид Jenkins или добавить новые функции. Terraform это инструмент для безопасного и эффективного создания, изменения и управления версиями инфраструктуры. Terraform может управлять существующими популярными поставщиками услуг, а также настраивать собственные решения [19]. Файлы конфигурации описывают Terraform компоненты, необходимые для запуска одного приложения или всего вашего центра данных. Terraform генерирует план выполнения, описывающий что он будет делать для достижения желаемого состояния, а затем выполняет его для построения описанной инфраструктуры. По мере изменения конфигурации Terraform может определить, что было изменено, и создать планы поэтапного выполнения, которые могут быть применены. Сложные наборы изменений могут быть применены к инфраструктуре с минимальным человеческим взаимодействием. С ранее упомянутым планом выполнения и графиком ресурсов можно точно знать, что Terraform изменит и в каком порядке, избегая многих возможных человеческих ошибок. 1.5 Формулировка целей и задач выпускной работы Основные проблемы проектирования гетерогенных баз данных и подходы к их решению: Наличие различий в аппаратных средствах (физические компоненты хостов). Разные аппаратные средства могут использовать разные представления данных, например, различные коды символов или различные представления для чисел с плавающей точкой [20]. Для решения этой проблемы необходимо разработать подход к трансформации и передаче данных без потери их целостности. 17

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

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

20 2 АНАЛИЗ ОСОБЕННОСТЕЙ СОЕДИНЕНИЯ SQL И NOSQL СУБД В этой главе будут рассмотрены особенности и отличия NoSQL СУБД, а именно MongoDB, от базы данных, построенной на реляционной модели, а именно Oracle DB. Так же будет показано, как эти особенности влияют на процесс объединения их в единую гетерогенную систему. 2.1 Особенности MongoDB Формат документа MongoDB. Документы в MongoDB моделируются посредством формата JSON (JavaScript Object Notation), но фактически хранятся в BSON (Binary JSON). Вкратце, это означает, что документ MongoDB является словарем пар ключ-значение, где значение может быть одним из нескольких типов: Примитивные типы JSON (например, число, строка, логическое значение) Примитивные типы BSON (например, datetime, ObjectId, UUID, regex) Массивы значений Объекты, состоящие из пар «ключ-значение» Null Ниже приведен пример словаря химических соединений. Элемент "Synonyms" ассоциирован с массивом. Информацию в документе можно хранить следующим образом: { "NegwerNo" : "1", "CASNo" : " ", "MolecularFormula" : "CCl2F2", "ChemicalName" : "Dichlorodifluoromethane", 20

21 "Synonyms" : [ "Arcton 6", "Cognoscin", "Dentocool", "Freon 12", "Frigen 12", "Genetron 12", "Provotest", "Recool" ] } Тот же объем данных в формате, поддерживаемым Oracle DB, будет выглядеть так: { NegwerNo CASNo MolecularFormula ChemicalName Synonyms CCl2F2 Dichlorodifluoromethane Arcton CCl2F2 Dichlorodifluoromethane Cognoscin CCl2F2 Dichlorodifluoromethane Dentocool CCl2F2 Dichlorodifluoromethane Freon CCl2F2 Dichlorodifluoromethane Frigen CCl2F2 Dichlorodifluoromethane Genetron CCl2F2 Dichlorodifluoromethane Provotest CCl2F2 Dichlorodifluoromethane Recool } Из приведенного примера видно, что без приведения данных к единому стандарту не обойтись, так как при дублировании в гетерогенную модель данные должны быть нормализованы разделением на две таблицы. При обращении к ним должен быть применен оператор JOIN. Документы MongoDB имеют ограничение жесткого размера 16 МБ. Это отличает MongoDB от базы данных Oracle, в которой размер файла не ограничен ничем кроме объёма имеющейся памяти. Проблема с объемом оперативной памяти в MongoDB заключается в том, что оперативная память обычно является самым важным ресурсом на сервере. В частности, база данных MongoDB кэширует часто используемые документы в оперативной памяти, и чем больше эти документы, тем меньше будет их помещаться. Чем меньше документов в ОЗУ, тем больше вероятность того, что на сервере произойдёт сбой страницы для извлечения документов, и, в конечном счете, ошибки страниц приводят к случайному вводу-выводу диска. 21

22 2.2 Исследование существующих аналогов В этом разделе представлено краткое описание выборки систем, которые были разработаны или разрабатываются для использования в производственных целях. Для каждой системы даются два общих типа информации: 1. Характеристики системы возможности системы 2. Компоненты системы и их функции Система ADDS компании Amoco Проект был начат как ответ на проблему интеграции баз данных, распределенных по всей корпорации. Приложения, разрабатываемые в компании, требовали данных из нескольких источников. Было решено, что имеющиеся базы данных не обеспечивали эффективных средств для доступа к данным из разных систем или управления ими [9]. Поэтому проект ADDS должен был служить для упрощения доступа к распределенным данным и управления ими в Amoco. Разработка велась для реляционных баз данных IMS, RIM, DB2 компании IBM и базы данных INGRES компании Actian Характеристики ADDS-системы ADDS обеспечивает единообразный доступ к существующим гетерогенным распределенным базам данных [25]. Система ADDS основана на реляционной модели данных и использует расширенный язык запросов реляционной алгебры. Подмножество стандартного языка ANSI SQL также поддерживается. В терминологии Шета и Ларсона, ADDS представляет собой 22

23 тесно связанную федеративную систему, поддерживающую несколько федеративных схем. Локальные схемы базы данных отображаются в несколько схем федеративной базы данных, называемой Composite DataBase (CDB). Сопоставления хранятся в словаре данных ADDS. Словарь данных полностью реплицируется на всех устройствах ADDS, чтобы ускорить обработку запросов. Обычно для каждого приложения определяется CDB. Однако несколько приложений и пользователей могут совместно использовать определения CDB. Пользователи должны иметь права доступа к определенным CDB и реляционным представлениям, определенным для CDB. CDB поддерживают интеграцию иерархических, реляционных и сетевых моделей данных. В настоящее время поддерживаются локальные СУБД: IMS, SQL/DS, DB2, RIM, INGRES и FOCUS [11]. Могут быть определены семантически эквивалентные элементы данных из разных локальных баз данных, а также соответствующее преобразование данных для элементов данных. Пользовательский интерфейс состоит из интерфейса прикладных программ (API) и интерактивного интерфейса. API состоит из набора вызываемых процедур, которые обеспечивают доступ к системе ADDS для прикладных программ. Программы используют API для отправки запросов на выполнение, доступа к схеме извлеченных данных и доступа к извлеченным данным по строкам. API предоставляет программистам прозрачный доступ к распределенным базам данных и СУБД Архитектура системы ADDS Многоуровневая архитектура системы ADDS показана на рисунок 2.1 Глобальные транзакции представляют собой прикладные программы, состоящие из одного или нескольких глобальных запросов и/или обновлений глобальной базы данных [21]. Один запрос может ссылаться на данные из нескольких источников. Глобальный интерфейс транзакций (GTI) проверяет 23

24 синтаксическую правильность пользовательских запросов и строит глобальный план выполнения. Рисунок 2.1 Многоуровневая архитектура системы ADDS Глобальный диспетчер данных (GDM) определяет местоположение данных, на которые ссылается глобальная транзакция из определения в словаре данных. GDM также управляет всеми промежуточными данными, которые получены от Глобального менеджера транзакций (GTM) во время выполнения транзакции. GTM управляет выполнением глобальных транзакций и распределяет серверы для обработки глобальных подтранзакций. GTM использует двухфазную стратегию распределения серверов, чтобы гарантировать атомарность глобальных транзакций. Все серверы остаются выделенными для глобальной транзакции до завершения транзакции. Это означает, что все 24

25 локальные элементы данных, на которые ссылается глобальная транзакция, остаются заблокированными до завершения транзакции. Локальные транзакции, не имеющие общих элементов данных с глобальными транзакциями, не затрагиваются. GTM на разных сетевых узлах обсуждают ресурсы сервера, когда необходимо, чтобы транзакция, представленная на одном узле, имела доступ к данным на других узлах. Серверы выполняют локальную проверку безопасности, а затем переводят подзапросы на язык локальных СУБД. Серверы также выполняют преобразование данных при извлечении локальных данных и переносе данных в GTM для дальнейшей обработки. Алгоритм управления параллелизмом «граф-сайт»("site graph")[breitbart et al. 1987,1989a Томпсон 19871] был использован на начальном этапе по поддержке транзакций обновления в ADDS. Этот общий алгоритм гарантирует сериализуемое выполнение глобальных транзакций с разрешенными локальными транзакциями и отсутствие глобальных взаимных блокировок [Gligor and Popescu-Zeletin ] При очень высокой активности, однако, слишком много глобальных транзакций прерываются. Чтобы уменьшить прерывание транзакций и увеличить пропускную способность, ADDS был модифицирован для использования алгоритма двухфазной блокировки с таймаутами, чтобы гарантировать свободу от глобальных взаимных блокировок. Протокол двухфазной фиксации используется для записи результатов глобальных транзакций в локальные базы данных. Хотя он больше не используется для управления параллелизмом, граф сайта является важным инструментом для обеспечения согласованности глобальной базы данных во время обработки фиксации и восстановления [Breitbart et al. 1989b]. Используемый таким образом алгоритм «граф-сайт» обеспечивает приемлемую производительность. 25

26 2.2.2 Система DATAPLEX компании General Motors Corporation Многие различные системы управления базами данных и файловые системы используются в обрабатывающей промышленности из-за разнообразных требований к управлению данными. Исторически сложилось так, что не было эффективных средств для совместного использования этих разнородных баз данных. Отсутствие эффективного обмена данными приводит к неэффективной инженерной, производственной и хозяйственной деятельности. Дублированные данные в разных местах часто приводят к несогласованности данных. Разработка велась для реляционных баз данных Ingres Database компании Actian и базы данных IMS компании IBM Характеристики системы DATAPLEX DATAPLEX позволяет запросам и транзакциям извлекать и обновлять распределенные данные, управляемые различными системами данных, таким образом чтобы местоположение данных было прозрачным для запрашивающих. В этой среде различные системы управления данными могут работать в разных операционных системах, которые могут быть связаны различными протоколами связи. Реляционная модель данных используется в качестве глобальной модели данных. Поскольку разные модели данных используются, в отличие от структурных данных систем баз данных, по-разному, определение данных для каждой коллективной базы данных в гетерогенной распределенной системе баз данных преобразуется в эквивалентное реляционное определение данных или концептуальную схему. Концептуальная схема реализуется как набор перекрывающихся реляционных схем, по одному для каждого местоположения. Связи в каждом месте представляют собой объекты данных, которые должны быть доступны пользователям в этом месте. Следовательно, 26

27 концептуальные схемы не являются ни централизованными, ни реплицируемыми. Таким образом, в терминологии Шета и Ларсона, DATAPLEX тесно связанная федеративная система, поддерживающая множество федеративных схем. Использование общей модели данных облегчает задачу обеспечения единого пользовательского интерфейса. Среди нескольких реляционных языков запросов SQL был выбран как единый пользовательский интерфейс, потому что SQL широко используется и для него был разработан стандарт ANSI. Поддерживаются как интерактивные SQL-запросы, так и встроенные SQLпрограммы Архитектура системы DATAPLEX Вышеупомянутые стратегии формируют архитектуру DATAPLEX. На рисунке 2.2 показаны система DATAPLEX и другие элементы в гетерогенной распределенной системе баз данных. Функции DATAPLEX выполняются четырьмя основными модулями, описанными здесь. Модуль Контроллер(Controller) планирует вызовы остальных модулей и обрабатывает входы и выходы модулей. 27

28 Рисунок 2.2 Многоуровневая архитектура системы DATAPLEX Модули пользовательского интерфейса и интерфейса приложений предоставляют АПИ(API) для запросов, вводимых в DATAPLEX. Пользовательский интерфейс отображается для пользователей в виде командной строки или в форме запроса. Интерфейс приложения привязан к скомпилированному перед выполнением приложению. Модуль протокола распределенной базы данных (DDBP) обеспечивает связь между программным обеспечением DATAPLEX в местах расположения пользователей и данных. Для адаптации DDBP к ним могут применяться различные протоколы связи. Модуль SQL Parser проверяет синтаксические ошибки операторов SQL. Модули Распределенный разборщик запросов и Оптимизатор распределенных запросов готовят распределенные запросы к исполнению с помощью модуля Менеджер словаря данных. Модули интерфейса «Переводчик» и «Локальная 28

29 СУБД» обеспечивают интерфейсы для локальных систем баз данных для выполнения локальных подзапросов, а процессор реляционных операций DATAPLEX пользователя объединяет результаты с локальных сайтов, чтобы обеспечить окончательный результат запроса. Диспетчер словаря данных находит местоположение данных, на которые ссылается запрос, и определяет тип запроса. Существует три разных типа запросов: запрос местоположения пользователя, удаленный однопользовательский запрос и распределенный запрос. Запрос на местоположение пользователя и удаленный одиночный запрос являются особыми случаями распределенного запроса. Чтобы обрабатывать распределенный запрос, Распределенный разборщик запросов раскладывает распределенный запрос на набор локальных запросов и запрос пользовательского местоположения, который объединяет результаты из других местоположений. (Локальный запрос ссылается на данные из одного места, которое может быть удаленным). Местоположение пользователя (источника), отправляющего локальные SQL-запросы в DATAPLEX-данные (целевые) [23], DATAPLEX определяет, используя Модуль протокола распределенной базы данных. Переводчик находит информацию о запросе из таблицы переводов, которая записывает различия имен данных и структур данных между концептуальной схемой и локальной схемой. Переводчик преобразует локальный запрос SQL в запрос (или программу) на локальном языке манипулирования данными (DML), используя информацию о переводе. Интерфейс Local DBMS отправляет переведенный запрос в локальную СУБД и получает локальный результат. Локальный результат находится в форме отчета, подобной отношению, независимо от структуры данных, используемой локальной СУБД [12]. Оптимизатор распределенных запросов исходного DATAPLEX планирует оптимальный план сокращения данных, используя статистическую информацию целевого DATAPLEX. План сокращения данных представляет собой последовательность полусоединений, 29

30 которая состоит из операций локального сокращения данных и перемещений данных между компьютерами. По завершении выполнения плана сокращения данных уменьшенные локальные результаты отправляются в исходный DATAPLEX. Там Процессор реляционных операций источника DATAPLEX объединяет локальные результаты путем обработки запроса пользователяместоположения. Для обработки запроса на распределенный запрос обновления создается набор локальных поисковых запросов для определения конкретных данных, подлежащих обновлению, а также набор запросов обновления, по одному для каждого отношения, подлежащего обновлению. Координатор распределенных транзакций обеспечивает двухфазную блокировку для ссылочных данных в локальных СУБД, которые задействованы. После того, как определенные данные, подлежащие обновлению, идентифицируются обработкой части извлечения, обрабатываются локальные запросы на обновление, включающие двухфазную фиксацию для обеспечения атомарности обновлений, а затем блокировки для ссылочных данных освобождаются. Существуют также модули Security Manager и Error Handler. Все модули DATAPLEX не зависят от локальной системы данных, за исключением модулей «Переводчик» и «Локальная СУБД». Таким образом, любая система данных может быть сопряжена с DATAPLEX, развивая эти два модуля для системы. Эта архитектура является модульной и представляет собой открытую архитектуру, функциональность и производительность которой могут быть постепенно увеличены IMDAS Национальный институт стандартов и технологий (NIST) В современных производственных системах первостепенное значение имеют два аспекта: 30

31 Промышленная автоматизация компьютерные системы, контролирующие и мониторинг системных процессов. Computer Integrated Manufacturing (CIM) прямой обмен данными между системами управления производством и инженерными и административными системами, которые их поддерживают [14]. В большинстве промышленных объектов управляющие, инженерные и административные системы работают с компьютерными системами и системами баз данных разных производителей. Они содержат независимо разработанные базы данных с логическими и физическими различиями в представлении одних и тех же объектов реального мира. Эти существующие системы представляют собой крупные инвестиции и поддерживают реальное производство. Невозможно заменить или значительно перепроектировать их. Интегрированная система управления производственными данными (IMDAS) была разработана для поддержки прототипа среды CIM Автоматизированного производственного исследовательского центра NBS (AMRF) Национального института стандартов и технологий (NIST), испытательного стенда для автоматизации производства небольших партий и измерения в процессе. Цель состояла в том, чтобы предоставить доступ из многих систем ко многим источникам производственных данных, сотрудничая с существующими приложениями в существующих базах данных, позволяя при этом новым и модифицированным прикладным программам получать доступ к данным по мере необходимости, изолированным от случайных различий в местоположении, представлениях и механизмах доступа Характеристики системы IMDAS В терминологии Шета и Ларсона, IMDAS тесно связанная федеративная система с единой глобальной схемой. Интегрирующая модель данных это модель семантической ассоциации (SAM), модель данных семантической сети, способная представлять сложные структуры и отношения, 31

32 а также многие ограничения целостности, обнаруженные на производственном предприятии. Схема фрагментации отображает глобальную модель в основные базы данных, поддерживая горизонтальное и вертикальное разбиение заданного класса объектов [16]. Существующие системы баз данных оканчиваются модулями IMDAS, поддерживающими внутреннюю форму обмена запросами, которая представляет собой расширенную алгебру обобщенных отношений, соответствующую смоделированным объектным классам, и соответствующую форму обмена данными, выраженную в Абстрактной синтаксической нотации (Abstract Syntax Notation). Этот общий интерфейс легко отображается на ненавигируемые реляционные базы данных. Библиотека подпрограмм, поддерживающих его, сводит к минимуму усилия, связанные с интеграцией новых систем данных и баз данных. Пользовательская фраза обрабатывает запросы на SQL-подобном языке, адаптированном к модели. Запрос передается в IMDAS в строковой форме, а не в скомпилированном виде, чтобы разрешить доступ контроллерам, запрограммированным на нестандартных языках. Этот механизм может поддерживать интерактивный интерфейс, хотя он еще не создан. IMDAS поддерживает как распределенные обновления (управление транзакциями), так и распределенные поисковые запросы (управление запросами). Однако схема фрагментации в настоящее время не поддерживает репликацию, что является существенным ограничением системы Архитектура IMDAS Самый низкий уровень архитектуры (Архитектура IMDAS показана на рисунке 2.3) включает в себя репозитории данных: базы данных, файлы памяти контроллеров, управляемые коммерческими СУБД, файловые системы, собственные серверы приложений это существующие системы данных, от которых зависит IMDAS. Каждая компьютерная система на предприятии имеет 32

33 основной сервер данных (BDAS), который обеспечивает интерфейс между локальными менеджерами хранилищ и интегрированной системой данных. Он содержит интерфейсные процессы, которые обеспечивают стандартные интерфейсы для локальных СУБД. BDAS и СУБД являются элементами, которые выполняют манипуляции с данными. Рисунок 2.3 Архитектура системы IMDAS Распределенные серверы данных (DDAS) выполняют функции обработки запросов и управления транзакциями. Каждый DDAS предоставляет интерфейс запросов ко всем прикладным программам в кластере компьютерных систем, которые являются его сегментом предприятия, и логически объединяет коллекцию хранилищ данных, управляемых BDAS в этом кластере, в соответствующий сегмент глобальной базы данных [22]. Управление данными осуществляется с помощью DDAS. 33

34 Главный сервер данных (MDAS) необходим, когда имеется более одного DDAS. Он объединяет отдельно управляемые сегменты в глобальную базу данных и управляет транзакциями, пересекающими сегментные (то есть DDAS) границы. MDAS не «управляет» полностью распределенной системой, это скорее утилита, используемая распределенными серверами для разрешения глобальной модели и обеспечения контроля параллелизма для транзакций, которые включают в себя несколько DDAS. Модульная архитектура IMDAS позволяет создавать несколько «распределенных архитектур систем данных» из одних и тех же компонентов. Система с одним DDAS и одним BDAS является по существу централизованной системой, тогда как система с одним DDAS и несколькими BDAS является распределенной системой с централизованным управлением. Система с несколькими DDAS это распределенная система с распределенным управлением. Прикладная программа выдает транзакцию IMDAS в строковой форме на языке манипуляции данными. Обработчик запросов DDAS в этом кластере преобразует транзакцию, расширяя представления, зависящие от приложения, в стандартные операции над концептуальными обобщенными отношениями. Если результирующий запрос может быть выполнен полностью в сегменте DDAS, он передается менеджеру транзакций DDAS. В противном случае он отправляется в MDAS. В любом случае обработчик запросов сообщает об окончательном статусе пользовательской программе, когда транзакция завершена. Диспетчер транзакций DDAS, используя схему фрагментации, описывающий распределение своего сегмента глобальной модели, отображает запрос в набор подзапросов, каждый из которых работает с элементами глобальной базы данных, управляемой отдельной СУБД. Алгоритм отображения учитывает возможности целевой СУБД. Операции, которые превосходят возможности СУБД-хранилища, направляются в достаточно дееспособную СУБД с временными обобщенными отношениями, указанными 34

35 для хранения данных, которые будут обрабатываться. Это также механизм интеграции информационных блоков из нескольких СУБД. Подзапросы затем отправляются пострадавшим BDAS, используя оптимистичные обязательства в случае обновления, потому что многие СУБД не имеют никаких функций обязательств вообще. То есть индивидуальные субтранзакции фиксируются независимо от предположения, что все будут совершены. Менеджер транзакций использует механизм блокировки, чтобы гарантировать, что одновременный доступ на чтение/запись или запись/запись в одну и ту же основную «базу данных» будет предотвращен. В этом контексте «база данных» представляет собой смоделированный набор информации, который является (возможно, подходящим) подмножеством данных, управляемых одной СУБД. Транзакции, «конфликтующие» на этом уровне, сериализуются управляющим менеджером транзакций, что приводит к распределенному контролю параллелизма. Затрагиваемый BDAS получает подзапросы из DDAS в форме обмена, указывая операции, которые должны выполняться в локальных репозиториях данных, а также источники и адресаты связанных данных. BDAS преобразует подзапрос в форму, соответствующую назначенной СУБД, и передает ее в эту СУБД, конвертируя любые данные, участвующие между формой СУБД и формой обмена данными, и сообщает о завершении DDAS. Сам BDAS обращается к любым ссылочным локальным данным, которые не управляются файлами DBMS или общей памятью [Libes 1985; Mitchell and Barkmeyer 1984] преобразование между пользовательским представлением и формой обмена IMDAS. BDAS также осуществляет доступ к требуемым удаленным данным путем связи с удаленным BDAS, перемещая данные непосредственно от производителя к потребителю без учета пути управления. (Например, если в DDAS-1 указано, что данные будут отправляться с BDAS-1 на BDAS-2, данные будут передаваться напрямую из BDAS-1 в BDAS-2 без прохождения через DDAS-1). 35

36 MDAS по сути является менеджером транзакций DDAS со схемой фрагментации, которая описывает распространение глобальной модели через DDAS, а не через СУБД [24]. Он принимает транзакции и отчеты о состоянии отдельных процессоров запросов DDAS. Он отправляет подзапросы и получает отчеты о состоянии от отдельных менеджеров транзакций DDAS. Поскольку MDAS является клоном диспетчера транзакций DDAS, его можно создать на любой станции, имеющей DDAS, и, следовательно, ее можно легко заменить в случае сбоя. 2.3 Интерфейсы приложений системы и функциональные требования Задачей отдела, для которого разрабатывается система, является извлечение методологически определенных данных из научных статей и их каталогизация. Для последнего используется схема OracleDB, предоставленная стороной заказчика, представляющая собой набор таблиц, соответствующих каждому из возможных типов информации (фактов), которые могут быть извлечены из статей. Извлекаемые данные являются различными физическими показателями химических соединений, которые исследуются в статьях. Эти факты, в свою очередь, должны быть привязаны к химическим соединениям из официальных химических каталогов. 36

37 Рисунок 2.4 Интерфейс приложения для обработки статей Стороной заказчика предоставлено приложение (графический интерфейс приложения приведен на рисунке 2.4), которое используется сотрудниками отдела для обработки научных статей и регистрирования информации о найденных фактах посредством заполнения форм (примеры форм приведены на рисунке 2.5), соответствующим различным типам фактов. Каждая форма имеет фиксированный набор полей, соответствующий колонкам таблиц базы. Прежде чем заводить факт оператор должен идентифицировать химическое соединение, используя официальные каталоги, и завести информацию о нем в приложение. 37

38 Рисунок 2.5 Формы регистрации фактов и привязка к соединению Для автоматизации данного процесса, процесса идентификации и привязки химического соединения, было разработано приложение-справочник (графический интерфейс приложения приведен на рисунке 2.6), объединяющее несколько каталогов химических соединений. Приложение использует MongoDB для хранения информации о соединениях ввиду невозможности задания жесткой схемы, описывающей всевозможные характеристики объектов без избыточности. Интерфейс позволяет пользователям с правами администратора заводить новые химические соединения и редактировать имеющиеся, а все обычные пользователи системы могут осуществлять поиск по любому полю, а также по химической структуре. 38

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

40 из OraceDB и MongoDB. Архитектура, позволившая это реализовать, подробно описана в следующей главе. 2.4 Разработка архитектуры гетерогенной SQL-NoSQL системы Используя опыт представленных выше систем, был сделан вывод, что наилучшим образом себя проявили системы DATAPLEX и ADDS, тогда как система IMDAS не была удачной, и проект был закрыт в 2007 году. Исходя из этого, за основу архитектуры были взяты системы DATAPLEX и ADDS. Но так как эти системы, хоть и были гетерогенными, базы данных поддерживали реляционную модель данных, а значит, SQL-подобный язык. В рассматриваемом случае это не так, и исходя из особенностей, перечисленных в пункте 2.1, было принято решение использовать язык SPARQL как языкпосредник, осуществляющий запросы к гетерогенной распределенной системе. В этом разделе сначала будет представлен глобальный взгляд на архитектуру системы, а затем каждый компонент в гетерогенной распределенной системе баз данных. Архитектура, как показано на рисунке 2.7, содержит три основных слоя. Первый уровень включает пользовательские интерфейсы, и в нем пользователь может отправлять один или несколько запросов через графический интерфейс пользователя (1) на уровень сервера-посредника. 40

41 Рисунок 2.7 Архитектура системы Сервер-посредник (медиатор) находится на втором уровне архитектуры (изображён на рисунке 2.8). Это промежуточная система, содержащая глобальную схему, которая описывает данные по всей сети, и используется для поддержки и координации распределенного управления транзакциями. Медиатор предназначен для интеграции компонентов любой базы данных. На этом уровне хранятся четыре важных компонента: Разборщик запросов (Query Parser), Распределитель запросов, Оптимизатор запросов (Optimizer) и Координатор транзакций. Как только запрос пользователя получен посредником, запрос будет отсканирован и проанализирован в графической структуре SPARQL. Если ошибка не обнаружена, сгенерированные транзакции, соответствующие запросу, отправляются в Decomposer распределенного запроса (2), который может интерпретировать запрос, полученный от интерфейса пользователя, и создает контекст распределенного запроса, содержащий несколько транзакций и их объединений (т.е. JOIN). Затем Query 41

42 Optimizer принимает все распределенные транзакции (3) и генерирует оптимальные подзапросы для построения оптимального плана выполнения запроса SPARQL. Оптимизация таких подзапросов является ключевым фактором, влияющим на производительность всей системы. Для каждой распределенной транзакции координатор распределенных транзакций (4) просматривает соответствующую схему распределенной базы данных, в которой отношение доступа к транзакции находится из определения адресов конечных точек. Однако запросы SPARQL требуют явного определения URI конечных точек. Система позволяет выполнять запросы без необходимости указывать конечные точки назначения. После этого координатор транзакций генерирует навигационную информацию в форме SPARQL для всех подтранзакций в соответствии с ассоциациями между ними, а затем отправляет их отдельно на соответствующий гетерогенный сервер базы данных (5). Третий уровень архитектуры содержит два гетерогенных распределенных сервера баз данных: реляционную базу данных OracleDB и NoSQL базу данных MongoDB. Чтобы инкапсулировать детали компонентов баз данных, свободные RDF-обертки, такие как D2RQ и AllegroGraph, помещаются в периферийные части распределенных систем баз данных. Поэтому, когда SPARQL-запрос поступает на гетерогенные распределенные серверы баз данных, запрос напрямую не обращается к распределенной базе данных. Вместо этого он содержит графические шаблоны, привязанные к виртуальному набору данных RDF. Кроме того, RDF-обертки также участвуют в оптимизации запросов. Затем соответствующая RDF-оболочка генерирует запрос SPARQL в локальный запрос к СУБД локальных схем (6). Результат выполнения локальной транзакции возвращается в ту же оболочку (7), а затем локальный результат преобразуется в единый формат (например, XML или JSON) и собирается сервером Mediator Server (8). 42

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

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

45 вложенном объединении циклов после того, как был получен полный набор результатов меньшего размера. Этот режим порядка соединения называется «Присоединение посредника». Он выполняет объединения в посреднике после сравнения промежуточных наборов результатов из источников данных, и только меньший набор результатов будет возвращен посреднику. Такой подход порядка соединения используется в используемом оптимизаторе запросов для обработки больших наборов результатов, и это резко сократит затраты на передачу. Координатор распределенных транзакций Координатор распределенных транзакций используется в архитектуре для управления оптимальными распределенными субтранзакциями. Он обнаруживает и обрабатывает постоянные записи транзакций и управляет связью с базами данных. Конечная точка SPARQL Конечная точка SPARQL позволяет пользователям отправлять запросы посредством машинного интерфейса к базе знаний, такой как тройное хранилище через язык SPARQL. Результаты возвращаются в машинных форматах, таких как XML и JSON. В разбираемом случае четыре разных RDF- Wrappers на сервере распределенной базы данных можно рассматривать как четыре конечные точки SPARQL. Сопоставление реляционных данных с RDF Существуют подходы для отображения реляционных данных в RDF, такие как Triply, R2O и RDBToOnto. В этом исследовании был выбран подход D2R для упрощения интеграции реляционной базы данных и поиска информации без репликации данных в специализированное хранилище RDF. Сервер D2R использует язык отображения D2RD для автоматического создания файла сопоставления между определенными схемами реляционных баз данных и схемами RDF. Этот файл сопоставления преобразует все таблицы из реляционной базы данных в классы RDF и используется для идентификации 45

46 ресурсов, а также для доступа и создания значений свойств в формате RDF из содержимого базы данных. Сервер D2R позволяет приложениям запрашивать реляционные базы данных с использованием языка запросов SPARQL по протоколу SPARQL. Как только SPARQL-запросы поступают от посредника, они преобразуются в SQLзапросы посредством сопоставления и выполняются реляционной базой данных с отображением D2RQ. Наконец, результаты запроса будут представлены в форматах XML и JSON и интегрированы в глобальные результаты. Отображение данных NOSQL в RDF До сих пор мало внимания уделялось интеграции данных NOSQL и RDF. AllegroGraph является одним из немногих инструментов, которые могут помочь отображать данные NOSQL в RDF. Сервер AllegroGraph разработан для соответствия стандартам W3C для RDF, поэтому его можно использовать в качестве базы данных RDF. Подобно D2R для реляционных баз данных, сервер AllegroGraph предоставляет механизм сопоставления, и он позволяет связать данные запроса и данные на основе документа в MongoDB с помощью SPARQL. 46

47 3 НАСТРОЙКА ГЕТЕРОГЕННОЙ СИСТЕМЫ 3.1 Обоснование выбора облачного сервиса для гетерогенной системы Облако Amazon Elastic Compute Cloud (EC2) является новаторским решением для быстрого изменения аппаратных средств и конфигурации, а также для временных вычислительных задач. В центре внимания этого пункта обзор эффективного использования Elastic Compute Cloud. Кроме того, анализируется, является ли EC2 надежной и эффективной конфигурацией хранения и является ли EC2 подходящим или конкурентным для многих приложений. Сравнение тематических исследований ссылается на измерение и передачу эффективности конфигураций EC2. Облако это модель общего источника конфигурируемых ресурсов, таких как серверы и хранилища, которые быстро масштабируются. Его также можно назвать последовательным, крупномасштабным и общедоступным собранием вычислительных ресурсов, систем хранения и сетевых ресурсов [26]. Elastic Compute Cloud это инфраструктура, в которой экземпляры серверов могут стартовать при быстром запуске образа Amazon Machine Image (AMI) с различными операционными системами, включая Linux, Windows и другие. EC2 использует заданный размер машины для тех экземпляров, которые ограничены какими-либо условиями. Примером может быть ситуация, когда требуется больше памяти для изображения из-за ограничений базы данных и двенадцать больших экземпляров должны быть созданы для обслуживания одного. EC2, которое, как утверждается, является инновационным решением для: быстрого изменения аппаратных средств и конфигурации; временных потребностей в вычислениях, которые снижают затраты на запуск; 47

48 создания более надежных конфигураций, чем стандартный физический жесткий диск и базовая конфигурация серверов. Сравнение тематических исследований используется для анализа и представления результатов. Конфигурация изменяется со временем использования EC2. EC2 предназначен для быстрой масштабируемости с использованием инструментов, которые в прошлом требовали сложной архитектуры системы и крупных инвестиций в аппаратные средства. EC2 позволяет сделать следующее: быстро увеличить или уменьшить пропускную способность как показано на рисунке 3.1, сотни экземпляров сервера могут быть быстро созданы или закрыты; приложения могут быть автоматически увеличены или уменьшены с помощью программируемого управления конфигурацией; масштабирование может быть выполнено в соответствии с потребностями, и AMI могут вводится в эксплуатацию и выводится из эксплуатации по мере необходимости; автоматическое масштабирование использует управляемую правилами систему для кодирования логики, которая добавляет и удаляет экземпляры EC2. Использование оборудования может быть настроено на увеличение или уменьшение с учетом спроса или использования веб-сайта. Это можно сделать в нескольких зонах доступности [28]. разместить экземпляры в различных зонах доступности, чтобы обеспечить защиту типа RAID от сбоя. 48

49 Рисунок 3.1 Конфигурация EC2 В интересах поставщика EC2 с течением времени снизить издержки и сократить трудозатраты персонала. Как показано на рисунке 3.1, дополнительные серверы являются масштабируемыми и могут быть быстро добавлены. Для более быстрой масштабируемости EC2 может быть активным для компаний, которым требуется развертывание крупномасштабной архитектуры с огромными затратами на запуск, как и в рассматриваемом случае. EC2 в работе: оценка findthebest.com и другие. Несколько компаний предложили тематические исследования для обзора на веб-сайте Amazon относительно использования EC2. Например, FindTheBest.com описывается, как онлайн-компания, которая предлагает объективный механизм сравнения. Он позволяет пользователям сравнивать варианты для смартфонов и колледжей, переключаясь с системы VPS на Amazon Web Services (AWS). В этом тематическом исследовании рассматривается переход на AWS и EC2 для стабильности, масштабируемости, гибкости цены и управляемости. Другое исследование касается систем безопасности данных (DS3) и эффективного использования DS3 Elastic Compute Cloud. DS3 это компания, которая специализируется на развертывании серверов аутентификации для банков и финансовых учреждений. Внедрение EC2 сделало бизнес более 49

50 рентабельным для DS3. DS3 использует EC2 для аутентификации и обслуживания транзакций. AWS и EC2 позволили этой компании эффективно использовать EC2 для снижения затрат и повышения производительности (Data Security Systems Solutions, 2011). DS3 начал использовать EC2 для аутентификации и обработки транзакций, чтобы устранить некоторые высокие затраты на запуск, связанные с физическими серверами, необходимыми для этих задач [11]. 6waves Games, издатель игр В другом примере 6waves приводит примеры использования EC2, которые включают процессы настройки, которые должны были бы повторяться на каждом вновь приобретенном физическом сервере. Эти процессы конфигурации требуют затрат времени и усилий. Установка обновлений, настройка системы и добавление пользователей занимает много времени и часто подвержена ошибкам. Для 6waves мониторинг физического состояния сервера и обработка отказов жесткого диска были аспектами, в которых EC2 был инновационным улучшением в быстром внесении изменений в аппаратное обеспечение и конфигурацию. EC2 это инновационное решение для временных вычислительных потребностей и ситуаций, в которых отсутствуют средства для первоначальных инвестиций в IT. Это предварительное вычисление эффективно используется многими обучающими программами, которым требуются ресурсы только на короткий промежуток времени. Ронда Абрамс из USAToday утверждает, что 85% новых предприятий терпят неудачу в течение первого года. Фактически, многие новые предприятия работают менее пяти лет [11]. EC2 не требует авансовых инвестиций, экспериментирование недорого и операции масштабируемы. Это является существенным преимуществом, поскольку совпадение прогнозов и новых ресурсов веб-сайта может превратиться в реальную проблему, в которой переоценка может привести к увеличению затрат и растрате ресурсов компании. Распространение может перерасти в 50

51 тысячи потерянных клиентов из-за сбоев в работе сайта или других проблем. EC2 позволяет компании делать больше с меньшими затратами. Рисунок 3.2 Архитектура системы с применением технологии Amazon Elastic Compute Cloud Исходя из перечисленных выше обстоятельств, сервис EC2 был выбран в качестве платформы для развертывания серверов гетерогенной системы, в том числе сервера-медиатора. Как показано на рисунке 3.2, отдельные EC2 экземпляры были предоставлены для пар D2RQ Oracle DB и AllegroGraph MongoDB. Также для сервера-медиатора был выделен отдельный EC2 экземпляр. Инструменты Chef и Jenkins 2.0 используются для управления экземплярами и своевременной установкой обновлений. 51

52 3.2 Особенности настройки D2RQ для Oracle D2RQ является картографической платформой RDB-to-RDF, которая поддерживает отображение реляционных баз данных в RDF и постановку запросов SPARQL к этим реляционным базам данных. Тем не менее, D2RQ представление применяется только для чтения из реляционных баз данных. Расширение D2RQ/Update позволяет выполнять инструкции SPARQL/Update и SQL Insert по сопоставленным данным и облегчать создание Semantic Web для чтения и записи. Запрос на языке SPARQL: SELECT?lv,?hv,?ut WHERE{ ft:melting_point ft:compound_id "560be580a6a3b6284e000013" ft:melting_point ft:low_value?lv ft:melting_point ft:high_value?hv ft:melting_point ft:units?ut } Переводится D2RQ в SQL-запрос: SELECT LOW_VALUE, HIGH_VALUE, UNITS FROM melting_point WHERE COMPOUND_ID = '560be580a6a3b6284e000013' Целью обновления D2RQ/Update является добавление возможностей SPARQL/Update в инфраструктуру D2RQ. Так D2RQ/Update транслирует инструкцию SPARQL/Update: 52

53 INSERT DATA { ft:melting_point ft:article_id "100567" ft:melting_point ft:page "7" ft:melting_point ft:column "2" ft:melting_point ft:low_value "8.2" ft:melting_point ft:high_value "8.6' ft:melting_point ft:units ft:celsius ft:melting_point ft:decomposition "FALSE" ft:melting_point ft:compound_id cm:560be580a6a3b6284e } В инструкцию к реляционной базе Oracle: INSERT INTO melting_point(article_id, PAGE, COLUMN, LOW_VALUE, HIGH_VALUE, UNITS, DECOMPOSITION, COMPOUND_ID) VALUES(100567, 7, 2, 8.2, 8.6, 'C', FALSE, '560be580a6a3b6284e000013') Аналогичным образом происходит обратная трансляция SQL query в SPARQL query. 3.3 Настройка AllegroGraph для MongoDB AllegroGraph реализует расширение, позволяющие пользователям запрашивать информацию из базы данных MongoDB, используя запросы SPARQL, и выполнять гетерогенные соединения, даже несмотря на то, что MongoDB хранилище документов NoSQL JSON, она не поддерживает родственные соединения SPARQL или связанные с RDF данные. Интерфейс MongoDB. Шаги для использования MongoDB с AllegroGraph: 53

54 установка MongoDB; синхронизация данных MongoDB с данными AllegroGraph; настройка AllegroGraph с параметрами подключения MongoDB. Обратите внимание, что заполнение и поддержка базы данных MongoDB отделена от добавления или удаления тройных копий из тройного хранилища AllegroGraph. Добавление или удаление данных из одного файла не синхронизируется автоматически с другим. Синхронизация данных MongoDB с AllegroGraph: Связать данные AllegroGraph и MongoDB, ссылаясь на один и тот же объект. Использование "_id": ex:subject1001 < 4561; Где 4561 является уникальным идентификатором MongoDB для документа, связанного с ex: subject1001 в тройном хранилище. Тип данных этого объекта-тройки является значительным и будет зависеть от типа данных, который используется для идентификаторов в документах MongoDB. Для каждого типа id в MongoDB используются следующие типы данных RDF: ObjectId использовать простой литерал, значением которого является шестнадцатеричное представление строки ObjectId, Integer использовать тип данных xsd: Long Числовое (нецелое) используется тип данных xsd: Double Настройка AllegroGraph с настройками подключения MongoDB: Настройки подключения MongoDB Сервер, на котором запущен MongoDB Порт, который прослушивает MongoDB Имя базы данных, с которой происходит соединение Название используемой коллекции MongoDB (Опционально) имя пользователя и пароль, которые позволяют подключиться к базе данных 54

55 Эти параметры можно задать с помощью AGWebView интерфейса HTTP или интерфейса Lisp, как описано ниже. Интерфейс AGWebView. AGWebView это веб интерфейс для AllegroGraph. Чтобы использовать его с MongoDB, нужно перейти на страницу «Обзор хранилища» и нажать на ссылку под надписью «Управление хранилищем», в котором указано «Управление внешним подключением MongoDB», на связанной странице можно установить необходимые параметры MongoDB. 3.4 Модели данных в приложениях Как было описано в разделе 2.3, система, для которой разработана гетерогенная база данных, осуществляет объединенный поиск по двум базам данных, связанным с двумя интегрированными друг с другом приложениями. Одно приложение использует MongoDB в качестве хранилища информации о химических соединениях, полученной из официальных каталогов. Ниже приведен пример записи (документа) MongoDB: { "_id" : ObjectId("560be580a6a3b6284e000013"), "NegwerNo" : "14", "CASNo" : " ", "MolecularFormula" : "CH2O2", "ChemicalName" : "Formic acid", "TrivialNames" : [ "Acidum formicicum", "Acidum formicum", "Ameisensa'ure", "Aminic acid", "Formylsa'ure", "Hydrocarbonsa'ure" ], "Synonyms" : [ "Acrocid-Verdunstungssa'ure", "Formic acid", "Formicin", "Formidium", "Formisoton", "Formitoxin-Holzinger:Myrmekan", "Myrmicyl", "Verrulosine" ] 55

56 } База Orcale DB другого приложения хранит связанные с химическими соединениями физические факты, описанные в научных статьях. Существует множество типов таких фактов, и у каждого типа свой набор полей, которые должны быть заполнены при регистрации факта, поэтому данные по каждому факту хранятся в отдельной таблице с колонками, соответствующими полям. Рассмотрим пример записи факта типа "точка плавления" из таблицы melting_point: ARTICLE_ID PAGE COLUMN LOW_VALUE HIGH_VALUE UNITS DECOMPOSITION COMPOUND_ID C FALSE 560be580a6a3b6284e Итоговая поисковая система по условиям, заданным пользователем, с помощью сервера-медиатора составляет SPARQL запросы к обеим базам. Описанные выше модули D2RQ и AllegroGraph опрашивают каждую из баз Oracle DB и MongoDB соответственно. В качестве ответа возвращаются два документа в формате RDF, которые затем объединяются сервером-медиатором в один, и система отображает результат в интерфейсе. Ниже приведен пример объединенного RDF документа: <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xml:base=" xmlns:cm=" 2.compute.amazonaws.com/compounds/" 56

57 xmlns:ft=" <rdf:description rdf:about="compounds/560be580a6a3b6284e000013"> <cm:chemicalname>formic acid</cm:chemicalname> <cm:molecularformula>ch2o2</cm:molecularformula> <ft:has_fact rdf:resource="facts/melting_point"/> </rdf:description> <rdf:description rdf:about="facts/melting_point"> <ft:low_value>8.2</ft:low_value> <ft:high_value>8.6</ft:high_value> <ft:units rdf:resource="facts/celsius"/> <ft:compound_id rdf:resource="compounds/560be580a6a3b6284e000013"/> </rdf:description> </rdf:rdf> Этот RDF документ кодирует объединение данных из обеих баз для одного химического соединения с уникальным идентификатором 560be580a6a3b6284e000013, эти данные могут также быть представлены в более наглядной графовой форме: 57

58 Рисунок 3.3 Набор данных, возвращённый сервером-медиатором 3.5 Компоненты и настройка сервера-медиатора Словарь данных располагается на сервере-медиаторе (Приложение 1). К нему имеют доступ: Парсер запросов, Распределенный обработчик запросов и Оптимизатор запросов. Словарь данных обновляется после каждого структурного изменения в гетерогенной системе. Словарь данных содержит: Схемы баз данных входящих в систему гетерогенных баз данных Предикаты (типы связей) Типы данных полей Ограничения, наложенные на значения в полях URL удаленных серверов SPARQL Север-медиатор участвует как в формировании распределенного SPARQL запроса, так и в обработке SPARQL и форматировании ответа от баз данных. В этом пункте будет более подробно рассмотрен принцип работы сервера-медиатора и его компонентов. Начиная с поступления запроса от 58