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

• Аль-Мусави Осама Адил Рахим
• кандидат наук
• 2023

Оглавление диссертации кандидат наук Аль-Мусави Осама Адил Рахим

Введение

1. Проблемы управления облачными маршрут-нестабильными системами

1.1. Маршрут-нестабильные сети и программное обеспечение управления ими

1.2. Современное управление данными и Интернет

1.3. Маршрут-нестабильные сети и программное обеспечение управления ими

1.4. Проблемы повышения эластичности и надежности облачных ресурсов

1.5. Постановка задач работы

Список источников к главе

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

2.1. Идея оптимальной репликации, основанной на оптимальных переходах пути

2.2. Допущения и модель системы

2.3. Оптимальная репликация на основе оптимальных переходов пути (ЖВОРН)

2.4. Улучшение заполнения буфера

2.5. Эксперимент и результаты

2.6. Выводы

Список источников к главе

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

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

3.2. Основные концепции и задачи

3.3. Описание машины состояния транзакций

3.4. Зависимости между состояниями транзакционной машины состояний

3.5. Обоснование концепции

3.6. Выводы

Список источников к главе

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

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

4.2. Повторная оптимизация запросов - описание и эксперименты

4.3. Результаты реализации повторной оптимизации запросов

4.4. Производительность различных алгоритмов повторной

оптимизации запросов

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

4.6. Выводы

Список источников к главе

Заключение

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

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

Введение

Актуальность темы. Маршрут-нестабильные сети (RunsNets) - это облачные сети, устойчивые к задержкам (DTN), в которых отсутствуют сквозные пути между узлами. RunsNets может, среди прочих вариантов, состоять из мобильных устройств, взаимодействующих через облачные приложения. Такая сеть имеет высокую мобильность, что приводит к ненадежной связи между узлами. Операции среды DTN и RunsNets децентрализованы, и узлы имеют существенные ограничения ресурсов. Среди прочего, актуальными являются накладные расходы на ретрансляцию и хранение, поскольку сети зависят от маршрутизации хранения, переноса и пересылки.

Однако из-за потенциального отсутствия достаточных ресурсов исходные узлы ретрансляции должны контролировать передачу сообщений при поиске места назначения. Исследованием этой проблемы занимались Димитриев Ю.К., Задорожный В.Н., Кравец О.Я., Bayhan S., Hyytira E., Kangasharju J. Требуется схема управления, которая ограничила бы путь сообщения максимальным числом переходов, точнее -оптимальным пределом перехода по пути. Но определение оптимальных переходов пути не является ни простым, ни выполнимым. Там, где большое количество переходов приводит к увеличению накладных расходов репликации, это также увеличивает вероятность нахождения места назначения сообщения. Большинство алгоритмов репликации сообщений для RunsNets обычно сохраняют несколько копий сообщения на разных узлах. Эти копии сообщений пытаются увеличить коэффициент доставки сообщений, но эта дополнительная репликация приводит к значительному потреблению производительности, что сокращает срок службы устройств с автономным питанием, образующих сеть RunsNet. Простейшим протоколом управления является Epidemic, который

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

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

Тематика диссертационной работы соответствует научному направлению ФГБОУ ВО «Воронежский государственный технический университет» «Вычислительные комплексы и проблемно-ориентированные системы управления».

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

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

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

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

3. Разработать модифицированный алгоритм повторной оптимизации запросов на основе ретроспективных данных.

4. Создать структуру распределенной программной системы

управления облачными маршрут-нестабильными базами данных.

Объект исследования: системы облачных вычислений.

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

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

Тематика работы соответствует следующим пунктам паспорта специальности 2.3.5 «Математическое и программное обеспечение вычислительных систем, комплексов и компьютерных сетей»: п.3 «Модели, методы, архитектуры, алгоритмы, языки и программные инструменты организации взаимодействия программ и программных систем»; п.9 «Модели, методы, алгоритмы, облачные технологии и программная инфраструктура организации глобально распределенной обработки данных».

Научная новизна работы. В диссертации получены следующие результаты, характеризующиеся научной новизной:

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

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

выполнимости транзакций.

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

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

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

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

Положения, выносимые на защиту

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

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

безопасности и выполнимости транзакций.

3. Модифицированный алгоритм повторной оптимизации запросов обеспечивает повышение эффективности повторной оптимизации запросов.

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

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

Апробация работы. Основные положения диссертационной работы докладывались и обсуждались на следующих конференциях: Всероссийской научной конференции «Достижения науки и технологий-ДНиТ-2021» (Красноярск, 2021); XXVII-th International Open Science Conference «Modern informatization problems in economics and safety (MIP-2022'ES)» (Yelm, WA, USA, 2022), 11-й Всероссийской научно-практической конференции «Решение» (Пермь, 2022); XXVIII-th International Open Science Conference «Modern informatization problems in the technological and telecommunication systems analysis and synthesis (MIP-2023'AS)» (Yelm, WA, USA, 2023), а также на научных семинарах кафедры автоматизированных и вычислительных систем ВГТУ (2020-2023 гг.).

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

Публикации. По результатам диссертационного исследования опубликовано 11 научных работ (1 - без соавторов), в том числе 6 - в изданиях, рекомендованных ВАК РФ (из них 1 - в издании, индексируемом в международной базе данных Scopus и два свидетельства о регистрации программы для ЭВМ). В работах, опубликованных в соавторстве и приведенных в конце автореферата, лично автором получены следующие результаты: [1, 4] - модель динамики распространения сообщения на основе мобильности и путей с использованием учета состояний посещенных узлов на базе цепей Маркова и сетевых графов; [8, 9] - алгоритм работы механизмов оптимальной репликации с учетом параллелизма и будущего использования в облачных средах; [2, 3, 10] - алгоритмы повторной оптимизации запросов в облачных базах данных; [5, 6, 7] - информационное и программное обеспечение распределенной программной системы повышения производительности и безопасности транзакций облачных маршрут-нестабильных баз данных с последующей реализацией ее отдельных компонент экспериментальной оценки качества разработанных методов и алгоритмов.

Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы из 155 наименований. Работа изложена на 146 страницах.

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

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

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

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

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

В работе вводится Оптимальная репликация, основанная на оптимальных переходах пути (ОЯВОРИ), модель, которая интегрирует оптимальную вероятность доставки, основанную на моделировании цепи Маркова, в сочетании с оптимальными переходами пути, основанными на определении Оптимального пути всех переходов (ОПВП). Модель направлена на определение правила копирования сообщений в сети. Чтобы оптимизировать распределение сообщений в сети, ОЯВОРИ минимизирует количество копий сообщений на основе оптимальных переходов по пути для всенаправленного посещения пути/маршрута.

ОЯВОРИ отличается от существующих алгоритмов репликации

следующими основными целями:

1) Моделируется динамика распространения сообщения на основе мобильности и путей. Подход рассматривает роль состояний посещенных узлов с использованием цепей Маркова и сетевых графов. Оптимальный маршрут основана на формулировке ОПВП в системе.

2) Подход обеспечивает методологические основы для изучения различных механизмов контроля и пороговых значений репликации сообщений.

3) Оптимальность модели учитывает неориентированные пути, когда она реплицируется на основе вероятности. Кроме того, он учитывает направленные пути, применяя правила ОПВП или остановки для оптимальной репликации.

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

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

Для обеспечения надежности эластичных облачных ресурсов используется концепция транзакционных свойств, которые подразделяются на сводные, повторяемые и компенсируемые [3.6]. Концепция транзакционных действий чрезвычайно полезна для

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

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

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

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

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

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

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

В заключении представлены основные результаты работы.

1. Проблемы управления облачными маршрут-нестабильными системами

1.1. Маршрут-нестабильные сети и программное обеспечение управления ими

Маршрут-нестабильные сети (КишК^Б) - это облачные сети, устойчивые к задержкам (ВТК), в которых отсутствуют сквозные пути между узлами. КишК^Б может, среди прочих вариантов, состоять из мобильных устройств [2.1], взаимодействующих через облачные приложения. Такая сеть имеет высокую мобильность, что приводит к ненадежной связи между узлами. Операции среды БТК и КииБ№1Б децентрализованы, и узлы имеют существенные ограничения ресурсов. Среди прочего, актуальными являются накладные расходы на ретрансляцию и хранение, поскольку сети зависят от маршрутизации хранения, переноса и пересылки.

1.1.1. Задержка в облачных приложениях

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

Новые веб-приложения необходимы для удовлетворения нескольких нефункциональных требований:

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

сервера, проблемы с подключением и человеческая ошибка.

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

• Быстрая страничная загрузка и время отклика - наиважнейшие условия для удовлетворения пользователя, трафика и выручки.

• Увлекательный пользовательский опыт значительно помогает улучшить продуктивность и эффективность пользователя.

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

1.1.2. Трехуровневые архитектуры

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

Мы будем различать двух- и трехуровневую архитектуру, основываясь на расположении уровня представления. Как показано на рис. 1.1, классическая трехуровневая архитектура включает в себя уровень представления как часть бэкэнд приложения. Это означает, что приложение и веб-сервер выполняют представление или бизнес-логику, пока сервера уровня данных и хранилища данных используют одну или более систему баз данных.

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

d<w J Platform (1ээБ, Ра ab)

Render

I_J I_I

Prvswtfiticj and Pcr^Tier

0ЫЛЛ«5 LigirTicr

Рис. 1.1. Архитектура трехуровневого веб-приложения

Поток запросов

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

1. Клиент запрашивает веб-сайт через протокол HTTP.

2. Веб-сервер принимает запрос и вызывает компоненты для обработки соответствующего URL-адреса. Обычно веб-сервер не запрашивается напрямую, а через балансировщик нагрузки: он распределяет запросы между доступными веб-серверами. Запрос может быть напрямую выполнен на веб-сервере (например, PHP), или вызван через сеть (например, через AJP), или с использованием системы очередей (например, RabbitMQ).

3. На сервере приложения выполняется бизнес-логика.

4. Данные, необходимые для рендера в текущем представлении, запрашиваются из базы данных и обновляются для отражения состояния приложения.

5. Ответ отправляется клиенту как HTML-файл. Веб-сервер напрямую отвечает на следующие запросы статических ресурсов, таких как изображения и скрипты.

Реализация

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

Провайдеры облака PaaS, такие как Microsoft Azure, Google App Engine и Heroku, предлагают управляемые операционные системы, серверы приложений и связующее ПО для запуска веб-приложений в масштабируемой форме. Пока провайдеры прописывают среду

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

В IaaS модели весь контроль над виртуальными машинами ведется арендатором. Это подразумевает то, что трехуровневые архитектуры могут использовать те же технологические стэки, что и приложения в локальных средах. Например, Amazon Web Services (AWS) и Google Cloud Platform (GCP) предоставляют инфраструктуру управления для предоставления отдельных виртуальных машин или контейнеров, которые могут запускать произвольное ПО для каждого уровня в архитектурах. Как правило, вебсервер (например, Apache, IIS или Nginx), сервер приложения (например, Tomcat или Wildfly) или обратный прокси-сервер (например, Varnish) комбинируются со структурой веб-приложения на определенном языке программирования, запуская бизнес-логику и части уровня представления (например, Python с Django, Java с Spring MVC или Ruby с Sinatra. Уровень бизнес-логики, в свою очередь, или использует системы базы данных, которая также размещена у провайдера IaaS, или подключается к предложениям DBaaS для сохранения и извлечения данных.

Архитектура микросервисов - это усовершенствование трехуровневой архитектуры, которое разлагает три уровня бэкэнд части.

Главная идея микросервисов заключается в разложении приложения на функциональные элементы, которые слабо связаны и взаимодействуют друг с другом через REST API. Следовательно, микросервисы предлагают облегченную альтернативу сервис-ориентированным архитектурам (СОА) и стандартов веб-сервисов. В отличие от трехуровневых приложений, микросервисы не передают состояние через уровень данных. Вместо этого, каждый микросервис ответственен за отдельное хранение данных, необходимых для выполнения специального функционала. Одной из основных причин для принятия микросервисов является то, что они дают возможность масштабировать разработку больших распределенных приложений: каждая команда может отдельно разрабатывать, развертывать и тестировать микросервисы до тех пор, пока контракты API остаются нетронутыми. В сочетании с рендерингом со стороны сервисов, то есть генерацией представления HTML для каждого взаимодействия в веб-приложении, микросервисы демонстрируют те же характеристики производительности, что и трехуровневые архитектуры. Некоторые аспекты даже усложняются, так как каждый микросервис является точкой отказа и время отклика на запрос совокупности нескольких микросервисов подвержена задержке.

Список литературы диссертационного исследования кандидат наук Аль-Мусави Осама Адил Рахим, 2023 год

Список источников к главе 2

2.1. Ippisch A., Graffi K. Infrastructure mode based opportunistic networks on android devices// 2017 IEEE 31st Int. Conf. on Advanced Information Networking and Applications (AINA), 2017, p. 454-461.

2.2. Woungang I., Dhurandher S.K., Anpalagan A., Vasilakos A.V. Routing in Opportunistic Networks. Springer, 2013.

2.3. Vahdat A., Becker D. Epidemic Routing for Partially-Connected Ad Hoc Networks. Technique Report, Duke University, USA, vol.20, no. 6, 2000.

2.4. Gurerin R., Orda A. Computing shortest paths for any number of hops// IEEE/ACM Trans. Netw., vol. 10, no. 5, p. 613-620, 2002.

2.5. Lindgren A., Doria A., Davies E., Grasic S. RFC 6693: Probabilistic Routing Protocol for Intermittently Connected Networks. IETF, 2012.

2.6. Spyropoulos A., Psounis K., Raghavendra C.S. Single-Copy Routing in Intermittently Connected Mobile Networks// Proc/ of the Annual IEEE Communications Society Conf/ on Sensor and Ad Hoc Communications and Networks (SECON), 2004, p. 235-244.

2.7. Spyropoulos T., Psounis K. Spray and Wait: An Efficient Routing Scheme for Intermittently Connected Mobile Networks// Proc. of the ACM SIGCOMM Workshop on Delay-Tolerant Networking, 2005.

2.8. Spyropoulos T., Psounis K., Raghavendra C.S. Spray and Focus: Efficient Mobility-Assisted Routing for Heterogeneous and Correlated Mobility// Proc. of the IEEE Int. Conf. on Pervasive Computing and Communications - Workshops (PerCom Workshops), 2007, p. 79-85.

2.9. Groenevelt R., Nain P., Koole G. The Message Delay in Mobile Ad Hoc Networks// Performance Evaluation, vol. 62, no. 1-4, 2005.

2.10. Zhang X., Neglia G., Kurose J.F., Towsley D.F. Performance

Modeling of Epidemic Routing// Computer Networks, vol. 51, no. 10, p. 28672891, 2007.

2.11. Vojnovic M., Proutiere A. Hop limited flooding over dynamic networks// INFOCOM 2011. 30th IEEE Int. Conf. on Computer Communications, Shanghai, China, 2011, p. 685-693.

2.12. Hanbali A.A., Nain P., Altman E. Performance of ad hoc networks with two-hop relay routing and limited packet lifetime (extended version)// Perform. Eval., vol. 65, no. 6-7, p. 463-483, 2008.

2.13. Bayhan S., Hyytira E., Kangasharju J., Ott J. Analysis of hop limit in opportunistic networks by static and time-aggregated graphs// 2015 IEEE International Conference on Communications, ICC 2015, London, UK, 2015, p. 3287-3292.

2.14. Neglia G., Zhang X. Optimal Delay-power Tradeoff in Sparse Delay Tolerant Networks: A Preliminary Study// Proc. of the SIGCOMM Workshop on Challenged Networks, 2006, p. 237-244.

2.15. Liu C., Wu J. An Optimal Probabilistic Forwarding Protocol in Delay Tolerant Networks// Int. J. of Distributed Sensor Networks , p. 105-114, 2009.

2.16. Xu J., Feng X., Yang W., Wang R., Han B.Q. Optimal Joint Expected Delay Forwarding in Delay Tolerant Networks// Int. J. of Distributed Sensor Networks, vol. 9, no. 11, p. 941473, 2013.

2.17. Kerranen A., Ott J., Krarkkrainen T. The ONE Simulator for DTN Protocol Evaluation// Proc. of the 2Nd Int. Conf. on Simulation Tools and Techniques, 2009, p. 55:1-55:10.

2.18. Kerranen A., Krarkkrainen T., Ott J. Simulating Mobility and DTNs with the ONE// J. of Communications, vol. 5, no. 2, p. 92-105, 2010.

2.19. Graffi K. Monitoring and Management of Peer-to-Peer Systems, Ph.D. diss., Technische Universiteat, Darmstadt, 2010. http://tuprints.ulb.tu-darmstadt.de/2248/.

2.20. Gu1d1 B., Amft T., Salve A.D., Graffi K., R1cc1 L. D1DuSoNet: A P2P Arch1tecture for D1str1buted Dunbar-based Soc1al Networks// Peer to-Peer Network1ng and Appl1cat1ons, vol. 9, no. 6, p. 1177-1194, 2016.

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

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

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

Для обеспечения надежности эластичных облачных ресурсов используется концепция транзакционных свойств, которые подразделяются на сводные, повторяемые и компенсируемые [3.6]. Концепция транзакционных действий чрезвычайно полезна для управления, а также для обеспечения правильности одновременного выполнения операций в различных приложениях (например, системах баз данных, веб-службах и т.д.). Предлагается транзакционный подход, который расширяет описания облачных ресурсов для более надежной эластичности с учетом возможных препятствий. Чтобы выразить успешные действия по реконфигурации эластичности, используем понятие принятых состояний завершения [3.7]. ATS машины транзакционного состояния (TSM) - это состояние, для которого облачные потребители принимают прекращение TSM. Если набор состояний завершения включен

в ATS, TSM идентифицируется как действительный. С транзакционной точки зрения каждая машина состояний рассматривается как составная транзакционная структура, ее состояния как транзакционные подпункты, а взаимодействия между ними как зависимости.

3.2. Основные концепции и задачи

3.2.1. Модель описания облачных ресурсов (cRDM)

В этом разделе представлена модель описания облачных ресурсов (cRDM), которая описывает облачные ресурсы и их характеристики эластичности с помощью конечного автомата [3.2].

Определение 3.1. Облачный ресурс CR, представляет собой кортеж из 5 элементов - CR = (имя, тип, ResReq, QoS, SM), где имя - это имя ресурса, тип - тип ресурса (например, вычислитель, база данных, сеть и т.д.), ResReq - это набор пар (Имя-значение), описывающих требования к ресурсу, QoS - кортеж, определяющий возможные ограничения на конкретную метрику QoS, SM - это конечный автомат, который фиксирует поведение эластичности облачного ресурса в течение его жизненного цикла.

Например, виртуальная машина (VM1) определяется как VM1 = ("vmcompute", вычислитель, {Процессор: 4 ГГц, Экземпляры: 5, Оперативная память: 8 ГБ, Поставщик: AWS}, Наличие, SM1)

Определение 3.2. Качество обслуживания, QoS представляет собой кортеж из 4 элементов - QoS = (имя, оператор, значение, единица измерения), где имя - метрика QoS, оператор - оператор сравнения, значение - значение метрики, а единица - единица измерения.

Например, QoS с именем «доступность» определяется как QoS = (Доступность, >=, 99, %)

Определение 3.3. Машина состояний SM представляет собой кортеж

из 3 элементов - БЫ = (имя, Б, Т), где имя - имя машины состояния, Б -набор состояний, а Т - набор переходов.

Например, конечный автомат с именем (БЫ1) определяется как БЫ = (БЫ1, б1, б2, бз, б4, б5, 11, 12, 13, 14, 15, 16).

Определение 3.4. Состояние Бе Б определяется как кортеж из 4 элементов - б = (метка, 1Б1пШа1, 1БКогша1, 1ББта1), где метка - это имя состояния, 1Б1пШа1 указывает, является ли состояние начальным состоянием, 1БКогша1 указывает, является ли состояние промежуточным состоянием, а 1ББта1 указывает, является ли состояние конечным состоянием. Каждое состояние аннотировано требованиями к ресурсам, которые должны быть удовлетворены в соответствии с ним.

Например, состояние б = (б1, является начальным).

Определение 3.5. Переход 1еТ между двумя состояниями определяется как кортеж из 5 элементов - 1 = (1ё, бб, б1, Е, А), где -идентификатор перехода, бб - исходное состояние, б1 - целевое состояние (т.е. состояние, которое активно после завершения перехода), Е - набор событий (т.е. набор стимулов, запускающих переход), и набор действий (т.е. выполняется, когда происходят определенные события).

Например, переход 1 = (11, б1, б2, ЯК-событие (средняя загрузка процессора, >=, 80, %, 300 с), масштабирование (УЫ1, AWS, изменение емкости, 5,60 с)).

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

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

3.2.2. Пример и обзор подхода

Рассмотрим потребителя облака, имеющего определенные потребности в ресурсах и ограничения для развертывания приложения, которое состоит из базы данных MongoDB, сервера NodeJS и приложения Java Script. Потребитель выбирает Amazon Web services (AWS) для развертывания этого приложения и указывает, что ему необходимо 5 экземпляров виртуальной машины (VM1). Рассмотрим машину состояний (SM), связанную с VM1, описанную с использованием модели cRDM [2], которая состоит из пяти состояний s1, s2, s3, s4 и s5, которые VM1 может пройти в течение своего жизненного цикла (где s1 - начальное состояние, а s5 - конечное состояние). Как показано на рис. 3.1, каждое состояние снабжено аннотациями с указанием потребностей в ресурсах, которые должны быть удовлетворены в соответствии с ним. Например, состояние s1 может быть достигнуто только в том случае, если запущено 5 экземпляров VM1. s2 достигается после горизонтального масштабирования (т.е. добавления 5 экземпляров VM1). s3 достигается после вертикального масштабирования (т.е. назначения большего количества физических процессоров и/или памяти экземпляру VM1). s4 достигается после миграции (т.е. переноса экземпляра VM1, запущенного на физическом сервере, на другой). Наконец, s5 достигается после завершения VM1.

Рис. 3.1. Конечный автомат УМ1, описанный с использованием

сКОМ

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

В модели отсутствуют средства для обеспечения надежных

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

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

Pool of cloud resources

Рис. 3.2. Обзор подхода

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

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

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

3) Обеспечение достоверности: поддерживается валидация конечного автомата транзакций, определяя набор правил достоверности в соответствии с требованиями облачных потребителей. Как только будет достигнут допустимый ТБМ, он будет развернут и выполнен.

3.3. Описание машины состояния транзакций

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

характеристики и правильного использования.

a) Поворотное действие

б) Компенсируемое действие

в) Повторяемое действие

Рис. 3.3. Жизненный цикл состояния в зависимости от типа действия транзакционной эластичности

Основными транзакционными свойствами, которые рассматриваются, являются поворотные, компенсируемые и повторяемые [3.8]. Состояние TSM si является pivot(p) (рис. 3.3а), если после его успешного завершения его эффекты остаются навсегда и не могут быть семантически отменены. si является компенсируемым (comp) (рис. 3.3б), если он предлагает политику компенсации, чтобы семантически отменить

его последствия путем или компенсировать состояние и переход компенсируется. si можно повторить (г) (рис. 3в), если оно обязательно завершится после нескольких конечных активаций с помощью повторной попытки перехода retry(r). Естественно, состояние может объединять свойства, и набор всех возможных комбинаций равен {г, comp, p, (г, comp),

(p, r)}.

На рис. 3.4 показан TSM, связанный с VM1, представленный в мотивирующем примере. Различные транзакционные свойства рассматриваются для нормальных состояний s2, s3 и s4, чтобы обеспечить решение для восстановления в случае сбоя1. Например, мы определяем s2 как (i) повторяемый, который обязательно завершится после нескольких конечных активаций и достигнет следующего состояния s3 или конечного состояния s5, и как (ii) компенсируемый, чтобы отменить его последствия, если следующее состояние s3 завершится неудачей.

3.4. Зависимости между состояниями транзакционной машины состояний

3.4.1. Транзакционный конечный автомат

TSM представляет собой набор состояний эластичного облачного ресурса, расширенного транзакционными свойствами. В этом разделе определяются транзакционные зависимости между состояниями. Эти зависимости определяют, как поведение определенного состояния влияет на поведение другого состояния после сбоев или/и проблем. Зависимость от si до sj существует, если переход si может вызвать переход восстановления sj и моделируется пунктирной стрелкой. Переход восстановления определяет влияние определенного состояния (состояний) (например, сбой s4) на другое состояние (состояния) (например, s3 продолжает компенсироваться).

Рис. 3.4. VM1 Транзакционный конечный автомат

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

• Альтернативная зависимость от

альтернативная зависимость от si до Sj, если переходу восстановления активации Sj.

Можно адаптировать альтернативные зависимости между состояниями, указав альтернативное условие, АкСопё^), для каждого состояния s. АкСопё^) определяет предварительное условие, которое должно быть выполнено до того, как s можно будет активировать в

si до Sj: существует сбой si может привести к

качестве альтернативы другому состоянию(состояниям). Существует альтернативная зависимость от Si до Sj, тогда и только тогда, когда si.failed е AltCond (sj).

В примере выполнение действия по восстановлению миграции (te3) может вызвать препятствие типа целостность ресурсов в s4. Чтобы иметь надежный TSM, справляемся с таким препятствием, определяя альтернативную зависимость от s4 до s5, чтобы s5 был активирован в случае сбоя s4. Это означает, что AltCond(s5) = s4.failed.

• Зависимость компенсации от si до sj! существует зависимость компенсации от si до ss, если сбой или компенсация si могут привести к переходу на восстановление компенсирующего sj.

Можно адаптировать зависимости компенсации между состояниями, указав условие компенсации, CpsCond(s), для каждого состояния s. CpsCond(s) определяет предварительное условие, которое должно быть выполнено до того, как s может быть компенсировано. Существует зависимость компенсации от si в sj, если

si.failed е CpsCond V (sj) .compensated е CpsCond(sj) .

В примере выполнение действия по восстановлению вертикального масштабирования (te2) может вызвать препятствие типа недоступности ресурсов в s3. Чтобы иметь надежный TSM, мы справляемся с таким препятствием, определяя (1) s2 как компенсируемую и (2) зависимость компенсации от s3 до s2 таким образом, что s2 будет компенсирован, если s3 выйдет из строя. Это означает, что CpsCond(s2) = s3.failed.

• Зависимость отмены от si до ss: существует зависимость отмены от si до ss, если сбой si может привести к переходу восстановления при отмене ss. Можно адаптировать зависимости отмены между состояниями, указав условие отмены, CnlCond(s), для каждого состояния s. CnlCond(s) определяет условие, которое должно быть выполнено до того, как s может быть отменено. Существует зависимость отмены от si до sj, если

в^а!^ е CnlCond(sj).

В примере выполнение действия по изменению конфигурации вертикальное масштабирование (^2) может вызвать препятствие типа недоступности ресурсов в Чтобы иметь надежный ТБМ, мы

справляемся с таким препятствием, определяя зависимость отмены от до таким образом, что будет отменен, если в3 выйдет из строя. Это означает, что CnlCond(s4) =

• Зависимость активации от в! до Sj: она представляет нормальный поток выполнения без ошибок. Но это можно рассматривать как решение для восстановления, если состояние определено как повторяемое в случае возникновения препятствий. Таким образом, действие выполнения эластичности повторяется до тех пор, пока не будет устранено препятствие. Таким образом, существует зависимость активации от в! до Sj, если завершение В! может запустить переход восстановления активации Sj.

Можно адаптировать зависимости активации между состояниями, указав условие активации, ActCond(s), для каждого состояния в. ActCond(s) определяет предварительное условие, которое должно быть выполнено до того, как s может быть активировано (только после завершения другого состояния (состояний)). Существует зависимость активации от Si до Sj, если si.completed е ActCond(sj) .

В примере выполнение действия по восстановлению горизонтального масштабирования ^е1 на рис. 3.4) может вызвать препятствие типа нехватки ресурсов в точке S2. Чтобы иметь надежный ТБМ, справляемся с таким препятствием, определяя (1) s2 как подлежащий повторному использованию и (2) зависимость активации от s2 до s3 таким образом, что s3 будет активирован только после завершения s2. Это означает, что ActCond(s3) = s2.completed.

3.4.2. Состояния завершения

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

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

Действие эластичной реконфигурации завершается успешно, если оно приводит свой TSM в приемлемое состояние завершения (ats). TSM достигает ats, если (1) он успешно завершается или (2) завершается неудачно и устраняет все нежелательные последствия частичного выполнения.

Вернемся к примеру и, как показано в табл. 3.1, может быть набор состояний завершения (tsj) для VM1. Облачный потребитель может выбрать ATS, что означает, что VM1 находится в правильном состоянии, например, когда ats1: все состояния завершены или когда ats4: s2 компенсируется, а s4 отменяется (учитывая сбой s3). Однако предполагается, что VM2 содержит следующее состояние завершения (s1.compensated, s2.completed, s3.failed, s4.cancel, s5.completed), которое не является принятым состоянием завершения. После этого VМ2 недействителен в соответствии с ATS. Очевидно, что транзакционное поведение ресурса может варьироваться в зависимости от выбранной ATS.

Таблица 3.1

*

ATS, используемые в примере

•51 s2 S3 s4 s5

ats 1 С С с С С

ats 2 С С i С С

at ss С С f cnl i

ats 4 С comp f cnl С

ats 5 С comp comp f 1

* с: завершено, i: начальное, f: не удалось, cnl: отменено, comp: компенсировано

3.4.3. Допустимый конечный автомат транзакций

Транзакционное поведение ресурса может генерировать различные состояния завершения. TSM действителен, если его набор состояний завершения включен в ATS. Чтобы сделать транзакционное поведение соответствующего ресурса для допустимого TSM эквивалентным определению соответствующих зависимостей между состояниями. Можно вывести из ATS и TSM условия состояний, соответствующие этим зависимостям. Для извлечения этих условий используем алгоритм, предложенный в [3.9]. atsCpsCond(si) (соответственно atsCnlCond(si) и atsAltCond(si)) - это условие компенсации ATS, выведенное из ATS (соответственно отмена ATS и альтернативные условия).

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

Введем правила действия, которые будем использовать, следующим образом:

Для состояния si в TSM, и набор принятых состояний завершения si

ATSsi:

Правило 1: если состояние неуспеха не принадлежит ATSsi, то существует транзакционное свойство, указывающее, что si должен быть повторен:

si.failedg ATSsi ^ si должен быть повторен.

Правило 2: если компенсируемое состояние не принадлежит ATSsi, то существует транзакционное свойство, говорящее, что нет необходимости в том, чтобы si подлежал компенсации:

si.compensated g ATSsi ^ si - нет необходимости в том, чтобы si подлежал компенсации.

Правило 3: для каждого условия компенсации ATS si, atsCpsCondi(si), существует транзакционное свойство, говорящее, что: если это условие в конечном итоге верно, то si должен быть компенсируемым, и atsCpsCond(si) становится условием компенсации si. Это означает, что Vsi е atsCpsCondi(si) добавляет зависимость компенсации от sj к si в соответствии с atsCpsCondi(si).

VatsCpsCondi(si) е atsCpsCond(si), atsCpsCondi(si) ^ si должен быть компенсируемым -л CpsCond(si) ^ CpsCond(si) ^ atsCpsCondi(si). Правило 4: для каждого условия отмены ATS si, atsCnlCondi(si), существует транзакционное свойство, которое гласит: если это условие в конечном итоге выполняется, то atsCnlCond(si) становится условием отмены si. Это означает, что V atsCnlCondi(si) е atsCnlCond(si) добавляет зависимость отмены из sj в si в соответствии с atsCnlCondi(si): V atsCnlCondi(si) е atsCnlCond(si),

atsCnlCondi(si) ^ CnlCond(si) ^ CnlCond(si) ^ atsCnlCondi(si). Правило 5: для каждого альтернативного условия ATS si, atsAltCondi(si), существует транзакционное свойство, которое гласит: если

это условие в конечном итоге выполняется, то atsAltCond(si) становится альтернативным условием si. Это означает, что V sj е atsAltCondi(si) добавляет альтернативную зависимость от sj в si в соответствии с atsAltCondi(si):

V sj е atsAltCondi(si),

atsAltCondi(si) ^ AltCond(si) ^ AltCond(si) ^ atsAltCondi(si).

В соответствии с примером можно вычислить следующие транзакционные свойства:

• Используя правило 1, и поскольку состояние "сбой" не принадлежит ATS(s2), получаем транзакционное свойство: s2 должен быть повторен.

• Используя правило 2 и поскольку компенсируемое состояние не принадлежит ATS(s4), получаем транзакционное свойство: нет необходимости в том, чтобы s4 подлежал компенсации.

• Используя правило 3 и поскольку atsCpsCond(s2)=s3. failed, получаем транзакционное свойство: s3.failed ^ s2 должно быть компенсируемым, л s2 должен быть компенсирован при сбое s3.

• Используя правило 3 и поскольку atsCpsCond(s3) = s4.failed, мы получаем транзакционное свойство: s4.failed ^ s3 должен быть компенсируемым, и s3 должен быть компенсирован при сбое s4.

• Используя правило 4, и поскольку atsCnlCond(s4)=s3. failed, получаем транзакционное свойство s3. failed ^ s4 должно быть отменено при сбое s3.

• Используя правило 5, и поскольку s3 .failed=atsAltCond(s5), получаем транзакционное свойство s3. failed ^ s5, которое должно быть активировано при сбое s3.

• Используя правило 5, и поскольку s4.failed = atsAltCond(s5), мы получаем транзакционное свойство s4.failed ^ s5, которое должно быть активировано при сбое s4.

Итак, транзакционные свойства различных состояний, необходимые, чтобы гарантировать действительный TSM: s2 - это rcomp, s3 - это comp, а s4 - p.

3.5. Обоснование концепции

В [3.2] описан прототип, под названием cRDMCore3. Благодаря своим основным компонентам, а именно редактору cRDM, генератору cRDM и контроллеру эластичности cRDM, ядро cRDM позволяет пользователям облака описывать и настраивать свои облачные ресурсы и соответствующие политики эластичности. Редактор cRDM снабжен тремя основными диаграммами с именами cRDM, CSM и cRDMCore. Сначала используется диаграмма cRDM, позволяющая пользователю облака графически создать экземпляр из модели cRDM соответствующего экземпляра cRDM, который удовлетворяет ее требованиям, касающимся облачных ресурсов и того, как они связаны друг с другом. Затем диаграмма CSM может быть использована для разработки SM, описывающей поведение эластичности для каждого облачного ресурса в экземпляре cRDM. Этот последний затем настраивается с помощью схемы cRDM - ядра, подключая ее к целевым облачным поставщикам и инструментам оркестровки. В результате автоматически создается файл JSON для всего экземпляра cRDM. Из этого файла генератор cRDM приступает к интерпретации высокоуровневых описаний, относящихся к облачным ресурсам, и определению их низкоуровневых сценариев и команд, необходимых на этапах развертывания, мониторинга и управления временем выполнения. После этого шага может быть выполнено развертывание экземпляра cRDM.

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

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

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

Добавление SM с транзакционными свойствами: расширена модель [3.2] SM в cRDM, чтобы обеспечить расширенное описание эластичности с транзакционными свойствами (область 1 на рис. 3.5). Пользователи облака могут выражать свои транзакционные свойства, перетаскивая соответствующие TSM, а также определяя возможные зависимости между ними. Затем они могут указать необходимые ATS для каждого TSM, используя область 2 на рис. 3.5.

Обеспечение достоверности SM: разработан механизм транзакций с использованием Java, который реализует алгоритм, предложенный в [9], для извлечения требуемых условий неопределенности и использует правила проверки, чтобы убедиться, что данный TSM действителен в отношении указанных ATS. Возвращаясь к примеру, на основе данного TSM (см. рис. 3.4) и указанной ATS механизм транзакций выводит требуемые свойства транзакций, перечисленные выше. Проверяя соответствие TSM этим свойствам транзакций, механизм транзакций возвращает пользователю облака уведомление о том, что его TSM действителен, вместе с соответствующими пояснениями, как показано на рис. 3.6.

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

Рис. 3.5. Скриншот, иллюстрирующий применение транзакционного подхода на примере

Validate Sfvl-Success!!

I

иаз-Г

, Success! -

The validation has beer done successfuiSy!!

S2 must be retribie —satisfied! í=

53.failed =>52 must be compensable----satisfied!

54.faiied =>53 must be compensatabie----satisfied! -

S3.fai!ed =>54 must be cancelled----satisfied! &

®

[ OK

Рис. 3.6. Скриншот, иллюстрирующий проверку ТБМ для виртуальной машины в примере

3.6. Выводы

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

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

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

Список источников к главе 3

3.1. Y. Al-Dhuraibi, F. Paraiso, N. Djarallah, and P. Merle, "Elas- ticity in cloud computing: State of the art and research challenges," IEEE Trans. Services Computing, vol. 11, no. 2, pp. 430-447, 2018.

3.2. H. Brabra, A. Mtibaa, W. Gaaloul, and B. Benatallah, "Model-driven elasticity for cloud resources." in CAiSE, ser. Lecture Notes in Computer Science, J. Krogstie and H. A. Reijers, Eds., vol. 10816. Springer, 2018, pp. 187-202.

3.3. P. Latchoumy and P. S. A. Khader, "Hybrid failure handling approach for guaranteed service in cloud computing environ- ment," in 2017 International Conference on Communication and Signal Processing (ICCSP), April 2017, pp. 0076-0082.

3.4. R. J. Priyadarsini and L. Arockiam, "Failure management in cloud: An overview," International Journal of Advanced Re- search in Computer and Communication Engineering (IJAR- CCE), vol. Vol. 2, Issue 10, pp. 40034008, Oct. 2013.

3.5. S. Prathiba and S. Sowvarnica, "Survey of failures and fault tolerance in cloud," in 2017 2nd International Conference on Computing and Communications Technologies (ICCCT), Feb 2017, pp. 169-172.

3.6. M. Little, "Transactions and web services," Commun. ACM, vol. 46, no. 10, pp. 49-54, Oct. 2003.

3.7. M. Rusinkiewicz and A. P. Sheth, "Specification and ex- ecution of transactional workflows." in Modern Database Systems, W. Kim, Ed. ACM Press and Addison-Wesley, 1995, pp. 592-620.

3.8. S. Mehrotra, R. Rastogi, H. F. Korth, and A. Silberschatz, "A transaction model for multidatabase systems." in ICDCS. IEEE Computer Society, 1992, pp. 56-63.

3.9. S. Bhiri, O. Perrin, and C. Godart, "Ensuring required failure

atomicity of composite web services." in WWW, A. Ellis and T. Hagino, Eds. ACM, 2005, pp. 138-147.

3.10. S. S. Gill and R. Buyya, "Failure management for reliable cloud computing: A taxonomy, model and future directions," Computing in Science and Engineering, p. 1, 2018.

3.11. C. Liu, Y. Mao, X. Chen, M. F. Fernandez, B. T. Loo, and J. E. van der Merwe, "TROPIC: Transactional resource orchestration platform in the cloud," in Presented as part of the 2012 USENIX Annual Technical Conference (USENIX ATC 12), Boston, MA, 2012, pp. 183-190.

3.12. S. Das, D. Agrawal, and A. El Abbadi, "Elastras: An elastic, scalable, and self-managing transactional database for the cloud," ACM Trans. Database Syst., vol. 38, no. 1, pp. 5:1- 5:45, Apr. 2013.

3.13. A. Waqas, A. Mahesar, N. Mahmood, Z. Bhatti, M. Karbasi, and A. Shah, "Transaction management techniques and prac- tices in current cloud computing environments:A survey," In- ternational Journal of Database Management Systems, vol. 7, 03 2015.

3.14. R. B. Halima, S. Kallel, K. Klai, W. Gaaloul, and M. Jmaiel, "Formal verification of time-aware cloud resource allocation in business process," in On the Move to Meaningful Inter- net Systems: OTM 2016 Conferences - Confederated Inter- national Conferences: CoopIS, C&TC, and ODBASE, ser. Lecture Notes in Computer Science, vol. 10033. Springer, 2016, pp. 400-417.

3.15. R. B. Halima, S. Kallel, W. Gaaloul, and M. Jmaiel, "Optimal cost for time-aware cloud resource allocation in business pro- cess," in Proceedings of the IEEE International Conference on Services Computing, SCC. IEEE IEEE Computer Society, 2017, pp. 314-321.

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

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

В облачных средах конфигурация оборудования, использование данных, и распределение рабочей нагрузки постоянно меняются. Эти изменения затрудняют оптимизатору запросов системы управления облачными базами данных подобрать оптимальный план выполнения запроса ^ЕР). Чтобы оптимизировать запрос с более точной оценкой затрат, в литературе было предложено во время выполнения запроса осуществлять повторную оптимизацию запроса. Тем не менее, некоторые из этих оптимизаций не могут обеспечить прирост производительности с точки зрения времени ответа на запрос или денежных затрат, которые являются двумя целями оптимизации для облачных баз данных, и могут оказывать негативное влияние на производительность из-за накладных расходов. Это поднимает вопрос о том, как определить, когда оптимизация выгодна. Целью исследования является разработка метода повторной оптимизации запросов, который использует компьютерное обучение. Ключевая идея алгоритма заключается в использовании прошлых выполнений запросов, чтобы научиться прогнозировать эффективность повторной оптимизации запросов, и делается это с целью помочь оптимизатору запросов избежать ненужной повторной оптимизации запросов для будущих запросов. Метод осуществляет запрос поэтапно, используя модель компьютерного обучения, для прогнозирования того, будет ли повторная оптимизация запроса полезной после выполнения этапа, и вызывает оптимизатор запросов для автоматического выполнения

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

Одно из ключевых различий между оптимизацией запросов в традиционных базах данных и в облачных базах данных заключается в том, что оптимизация запросов в облачных базах данных направлена на снижение денежных затрат, выплачиваемых провайдеру облачных услуг в дополнение к времени ответа на запрос. Тем не менее, временные и денежные затраты, необходимые для выполнения запроса, оцениваются на основе статистических данных, доступных оптимизатору запросов в момент выполнения оптимизации запроса. Эти статистические данные часто приблизительны, что может привести к неточным оценкам временных и денежных затрат, необходимых для выполнения запроса [4.1, 4.2]. Таким образом, планы выполнения запросов (QEP), сгенерированные оптимизатором запросов на основе этой статистики, до выполнения запроса, могут быть не самыми лучшими.

Одним из подходов, который может быть применен для решения вышеуказанной проблемы, является адаптивная обработка запросов [4.3]. Эта стратегия состоит не в выполнении запроса в целом за один раз, а вместо этого разделяет выполнение каждого запроса на несколько этапов, и затем повторно запускает оптимизатор запросов между каждым этапом. Сделав это, оптимизатор запросов может собирать более точную статистику между этапами выполнения, которые могут позволить изменять QEP во время выполнения, таким образом, вероятно, повышая производительность запросов [4.1, 4.4]. Операторы, которые не полагаются на выполнение других, группируются вместе, и такие группы называются "Этапами". Например, если план запроса содержит оператор JOIN, его левая и правая части выполняются на отдельном этапе. После выполнения каждого из этапов QEP, статистика данных обновляется, чтобы оптимизатор запросов мог использовать самую последнюю статистику для

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

На любом приведенном этапе выполнения запроса решение о том, приведет ли повторная оптимизация к повышению производительности, является непростой задачей. В [4.3] такое решение принимается на основе эвристических методов. Несколько контрольных точек размещаются вручную между определенными типами операторов. Тогда разница между предполагаемыми затратами и фактическими затратами считается после проверки контрольной точки запроса. Если эта разница превышает заранее определенный порог, то происходит повторная оптимизация. Проблема такой методики заключается в том, что правила размещения контрольных точек и порог фиксированы. Из-за динамики облачных сред сроки повторной оптимизации, определенные с помощью данного метода, недостаточно точны, чтобы сократить время выполнения запроса. В [4.5] представлен алгоритм обработки запросов, который выполняет повторную оптимизацию запросов после завершения каждого этапа на основе методики, предложенной в [4.1]. Однако работа [4.5] показывает, что

многие из этих вызовов повторной оптимизации не привели к изменению базового QEP, что означает, что повторная оптимизация запроса была выполнена без необходимости. Это произошло из-за того, что этапы не были согласованы с наилучшим временем для применения повторной оптимизации. Например, после выполнения примера запроса 1, приведенного на рис. 4.1, установлено, что из 10 раз, когда оптимизатор вызывался для повторной оптимизации во время выполнения этого запроса, только 2 из этих вызовов изменили QEP для оставшихся этапов; поэтому большинство вызовов повторной оптимизации не привели ни к улучшению времени, ни денежных затрат на выполнение этого запроса.

SELECT R.p_id, R.pjiame, R.sc, S.p_hr FROM (SELECT p_id, p_name, AVG(p_bp) AS sc FROM patient GROUP BY p_id, p_name) AS R

Рис. 4.1. Запрос 1

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

В то время как компьютерное обучение использовалось для улучшения обработки запросов в [4.6], известно, оно не использовалось для предотвращения ненужных вызовов повторной оптимизации запросов при адаптивной обработке запросов. Среди проблем, которые необходимо решить при использовании компьютерного обучения для этой цели, следующие. Первая состоит из множества функций, влияющих на оценку стоимости запроса, таких как избирательность, мощность, минимальные и максимальные значения столбца, наиболее частое значение столбца, гистограмма и т.д. Сложность здесь заключается в выборе наиболее подходящего подмножества из всех этих функций. Вторая проблема заключается в большом количестве возможных моделей компьютерного обучения. Алгоритмы контролируемого обучения, такие как Случайный лес [4.7], Нейронная сеть [4.8] и Расчет опорных векторов [4.9] широко используются, но для поставленной цели их необходимо тщательно изучить. Третья проблема касается сбора исторических данных по выбранному подмножеству функций, необходимых для обучения модели прогнозирования, построенной с использованием выбранного алгоритма компьютерного обучения. Четвертая проблема заключается в измерении эффективности алгоритма обучения. Работы [4.10, 4.11, 4.12] показывают, что алгоритм обучения эффективен для их собственных целей, например, для улучшения оценки затрат, но на самом деле ни один из них не демонстрирует, что они эффективны в фактической производительности выполнения запросов.

4.2. Повторная оптимизация запросов - описание и эксперименты

4.2.1. Стандартная генерация и механизм оптимизации запросов

В [4.5], после отправки запроса в СУБД, обычный оптимизатор

запросов сначала генерирует начальный QEP. Затем этот QEP будет разделен на этапы и поэтапно выполнен механизмом выполнения. После завершения этапа статистика данных обновляется. Эти статистические данные включают мощность, избирательность, а также максимальные и минимальные значения для каждого атрибута в каждой таблице базы данных. Обновляя эти статистические данные, оценка результирующего объема данных, используемого на последующих этапах, обновляется соответствующим образом. Остальные этапы QEP также отправляются оптимизатору запросов для повторной оптимизации с использованием обновленной статистики. Кроме того, в этой системе несколько машин с различными конфигурациями оборудования используются параллельно для выполнения операторов запросов. В настоящей статье эти машины будут называться контейнерами. Выполнение запроса на различные контейнеры приводит к различному времени ответа на запрос и денежным затратам, а при выборе наилучшего QEP необходимо учитывать и то, и другое. Для этого используем нормализованную взвешенную аддитивную модель [4.13] для выбора наилучшего плана. В этой модели каждая возможная альтернатива QEP оценивается по шкале, которая сочетает в себе как цели, время ответа на запрос, так и денежные затраты, с весами, определенными пользователем и средой для каждой цели, и определенным пользователем допустимым максимальным значением для каждой цели. Следующая функция А^М _8СОге используется для вычисления оценки QEP:

(QEPi) для цели Ш| - заданное пользователем допустимое максимальное значение для цели а '^-нормализованный суммарный вес пользователя и среды для цели который определяется следующим образом:

п

альтернативы QEP с индексом i

u «e

Wj Wj

W: =' ' '

J n

Z (UWj'eWj)

J=1

Здесь uW. и eW. описывают вес пользователя и вес окружающей

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

Проведены эксперименты, сравнивающие производительность запросов, полученную в результате использования повторной оптимизации запросов, и без повторной оптимизации запросов. Использовано два набора машин. Первый набор состоит из одной локальной машины (двухъядерный процессор Intel i5 2500K, 3 ГГц и 16 ГБ DRAM), используемой для обучения модели машинного обучения и выполнения оптимизации запросов. Второй набор состоит из 10 выделенных виртуальных частных серверов (VPS), которые использовались для развертывания механизма выполнения запросов. Пять из этих VPS -небольшие контейнеры (процессор Intel Xeon E5 2682, 2,5 ГГц с 1 ГБ DRAM). Остальные 5 VPS - большие контейнеры (двухъядерный процессор Intel Xeon E5-2682, 2,5 ГГц с 2 ГБ DRAM). Оптимизатор запросов и механизм запросов, использованные в этом эксперименте, были модифицированы из PostgreSQL 8.4. Данные были распределены между этими VPS.

В экспериментах было создано 1200 запросов с использованием шаблонов запросов, представленных в [4.1]. Запрос 1, показанный на рис. 4.1, является запросом, созданным на основе одного из этих шаблонов. Результаты показывают, что использование повторной оптимизации в среднем на 20% улучшает общие временные затраты по сравнению с использованием без повторной оптимизации, в то время как денежные затраты на два подхода близки, с разницей всего в 4%. Эти увеличения

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

Однако большое количество повторной оптимизации запросов не требуется. Ненужная повторная оптимизация для QEP происходит, когда QEP не изменяется после выполнения повторной оптимизации. В этих экспериментах после выполнения этапа QEP автоматически выполняется повторная оптимизация независимо от того, изменилась ли статистика данных после выполнения этапа, что приводит ко многим ненужным повторным оптимизациям. Например, эксперименты показывают, что при выполнении первого запроса 8 из 10 повторных оптимизаций запроса не требуются. Только две необходимые повторные оптимизации происходят после выполнения подзапроса. За исключением этих случаев, QEP после выполнения оператора TableScan или Aggregate вообще не меняются после повторной оптимизации. Выполнение повторной оптимизации сопряжено с накладными расходами, а ненужная повторная оптимизация увеличивает время ответа на запросы и денежные затраты. В этих экспериментах почти 60% повторной оптимизации запросов являются ненужными, а выполнение повторной оптимизации одного запроса стоит около 0,5% от общего времени ответа на запрос.

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

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

Особенности, лежащие в основе алгоритма

На рис. 4.2 показаны основные этапы обработки запросов при включении алгоритма для повторной оптимизации запросов. Сначала оптимизатор получает запрос и записывает текущую статистику данных. Затем запрос компилируется в QEP с информацией об этапе. Первый этап в QEP выполняется и удаляется из QEP. Во время выполнения статистика данных отслеживается и обновляется. После выполнения первого этапа эти обновленные статистические данные сравниваются с текущими статистическими данных, которые были записаны до выполнения этапа.

Рис. 4.2. Обработка запросов с повторной оптимизацией запросов на основе компьютерного обучения

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

("ДА" или "НЕТ") в качестве выходных данных. Запрос повторно оптимизируется, если решение "ДА" и выполняется текущий первый этап в новом QEP после повторной оптимизации; в противном случае, если решение "НЕТ", QEP остается прежним и выполняется его следующий этап. Эта процедура продолжается до тех пор, пока не останется ни одного этапа.

Выбор функций

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

Изменение QEP после повторной оптимизации подразумевает, что повторная оптимизация выгодна. Определим типы такого изменения:

1) изменения в типах физических операторов,

2) изменения в количестве контейнеров,

3) изменения в типах контейнеров.

Это означает, что если произойдет какой-либо из этих трех типов изменений, то следует разрешить повторную оптимизацию.

Предположим, что в текущей СУБД существуют столбцы С1, С2, ..., Сп во всех таблицах. Различия в избирательности (DIFF_SELECTIVITY), в количестве различных значений (DIFF_NDV) и в гистограммах (DIFF_HISTOGRAM) каждого столбца до и после выполнения этапа используются в качестве объектов данных в обучающих данных, используемых для прогнозирования, как показано в табл. 4.1. Двоичное значение ДА/НЕТ используется в качестве прогнозируемого класса в обучающих данных, где ДА означает, что повторная оптимизация, по прогнозам, будет полезной, и никак иначе. Ранее установлено, что избирательность, количество различных значений и гистограмма влияют на оценку размера данных [4.11]. Таким образом, различия в этих трех функциях до и после выполнения этапа приводят к изменениям в оценке

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

Таблица 4.1

Список выбранных функций

DIFF_SELECTIVITY(C 1) DIFF_NDV(C1) DIFF_HISTOGRAM(C1)

DIFF_SELECTIVITY(C2) DIFF_NDV(C2) DIFF_HISTOGRAM(C2)

DIFF_SELECTIVITY(Cn) DIFF_NDV(Cn) DIFF_HISTOGRAM(Cn)

Модельное обучение

Прежде всего генерируются запросы для обучения модели, выполняя случайные запросы, сгенерированные из всех 22 типов запросов в тесте TPC-H [4.14], которые являются значениями функций, выбранных ранее. Таким образом, модель прогнозирования может быть применена ко всем запросам. Если повторная оптимизация предназначена только для самых дорогостоящих/наиболее представительных запросов, то на этом первом этапе обучающие данные должны быть собраны из выполнения только случайных, но наиболее дорогостоящих/представительных запросов. На рис. 4.3 показана процедура сбора обучающих данных. Для того, чтобы лучше объяснить подробно как собираются обучающие данные, продемонстрирован пример выполнения запроса 2 (рис. 4.4).

Рис. 4.3. Порядок сбора данных для обучения

&ЕЬЕСТ СератШеаг, СОиГЧТ(Мате) тОМ STUDENT ОНОиР ВУ Серайтсп! \VHKRE См<1е<= С:

Рис. 4.4. Запрос 2

После отправки запроса записывается текущая статистика 81а1;сигг, собранная из системных журналов. Затем запрос отправляется оптимизатору для создания QEP. Этот QEP включает в себя информацию об этапах и узлах, на которых будут выполняться эти этапы. На рис. 4.5 показан QEP, созданный оптимизатором запросов для запроса 2. Каждый узел обозначает отдельный оператор запроса. Стрелки указывают на поток данных между операторами. QEP разделен на этапы, каждый из которых обозначен прямоугольником.

Рис. 4.5. QEP, разделенный на различные этапы, генерируемые оптимизатором запросов для запроса 2

ТS, FIL, SOR и AGG, обозначают операторы сканирования таблиц, сортировки, фильтрации и агрегирования соответственно.

4.3. Результаты реализации повторной оптимизации запросов

4.3.1. Механизм повторной оптимизации

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

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

операторы, которые выполняются параллельно для разных данных в разных контейнерах. Затем этап 1 отправляется в механизм выполнения запросов. Во время выполнения обновляется статистика данных, используя метод, представленный в [4.1]. В этом методе статистика данных собирается во время выполнения и обновляется после завершения работы операторов в одной вершине. Обновленные статистические данные -81аШрёа1е. Поскольку эти статистические данные собираются из фактически выполняемого запроса, 81аШрёа1е является более точным, чем 81а1;сигг, который получается из оценки. Разница между 81аШрёа1е и 81а1;сигг есть 81а1ё1Г:Т. включает значения функций, используемых в

качестве обучающих данных. Например, текущая избирательность и обновленная избирательность столбца А равны 0,5 и 0,1 соответственно, затем разница 0,4 добавляется в качестве значения функции ВШЕ_8ЕЬЕСТ1У1ТУ в обучающем наборе данных. Этот процесс применяется ко всем функциям табл. 4.1.

4.3.2. Создание обучающих запросов и баз данных

Для изучения точности моделей разных моделей при разных размерах обучающих запросов создаются пакеты обучающих запросов разного размера. Каждый пакет содержит разное количество запросов, которые были выполнены и отслеживались в одной системе с алгоритмом, реализованным на основе [4.6]. Размер пакета составляет от 10000 до 60000 запросов с интервалом в 5000 запросов между ними. Кроме того, мы готовим две базы данных для обучения: одну базу данных, в которой все таблицы заполнены однородными распределенными данными, и другую базу данных, в которой все таблицы заполнены распределенными асимметричными данными. Чтобы смоделировать реальное использование системы управления базами данных, кортежи всех таблиц базы данных постоянно меняются случайным образом. Это означает, что постоянно

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

4.3.3. Настройка параметров модели

Если алгоритм обучения, создающий модель, имеет параметры, важно выбрать наилучшие значения для параметров перед обучением модели. Для алгоритма случайного леса выбрано три параметра, влияющих на точность модели: количество деревьев, количество узлов в дереве и вариант случайного разделения. Для выбора наилучших значений параметров для запуска этой модели используется метод вложенной перекрестной проверки [4.5]. В этом методе сначала используется один этап перекрестной проверки для поиска лучших значений параметров, а затем применяется еще один этап перекрестной проверки для проверки истинной точности модели. В экспериментах установлено, что использование количества скрытых слоев как 600, количества узлов в дереве как 200 и опции случайного разделения как ДА обеспечивают наилучшую точность модели случайного леса.

4.3.4. Точность модели

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

нейронной сети, случайного леса и SVM. Также изучается влияние различных распределений данных на точность моделей обучения. Таблицы базы данных заполняются как равномерно распределенными данными, так и асимметричными данными, и для обоих выполняются одни и те же запросы. Многие традиционные оптимизаторы запросов, такие как PostgreSQL [4.16], предполагают, что данные распределены равномерно, поэтому, если используются только равномерно распределенные данные, есть больше шансов, что повторная оптимизация вообще не даст никакого эффекта. Асимметрия данных может привести к неправильной оценке стоимости, и поэтому QEP, выбранный традиционным оптимизатором запросов, далек от оптимального, поэтому повторная оптимизация может быть более полезной при перекосе данных. Специально использованы асимметричные данные, чтобы увидеть, как влияет на точность модели и производительность выполнения запросов.

Как показано на рис. 4.6, по мере увеличения количества запросов точность также увеличивается. Это связано с тем, что по мере того, как модель получает больше наблюдений, она более способна предсказывать полезные повторные оптимизации. Установлено, что точность этих трех моделей немного различается. В среднем нейронная сеть имеет точность около 70%, а случайный лес и SVM - около 75%. С точки зрения распределения данных, модели на однородных данных и на асимметричных данных имеют немного разную точность, при этом средняя точность находится в пределах 5% разницы друг от друга.

Точность моделей близка друг к другу, как указано выше; поэтому, чтобы выбрать, какую модель следует использовать в конечном итоге, эти модели оцениваются с точки зрения производительности при выполнении запроса при их включении в обработку запроса, как показано в алгоритме на рис. 4.1. Генерируется 100 экземпляров запросов из каждого из 22 типов запросов тестов TPC-H, всего 2200 запросов.

а) Точность модели в случае однородных данных 83%

б) Точность модели в случае асимметричных данных Рис. 4.6. Точность модели трех различных алгоритмов машинного обучения, которые учатся на запросах, выполняемых на (а) однородных данных и (б) асимметричных данных

В среднем каждый запрос состоит из 13 этапов. Эти запросы выполняются и повторно оптимизируются на основе решений, принятых

этими тремя моделями. Каждый QEP оценивается с одинаковым весом по времени и затратам, когда оптимизатор запросов выбирает лучший QEP. Это означает, что предполагается, что у пользователей нет никаких предпочтений в отношении временных или денежных затрат. Сравниваются фактические временные и денежные затраты, связанные с применением этих трех моделей. Эти запросы создаются заново и не видны ни одной из этих моделей в процессе обучения модели. На рис. 4.7 показано время ответа на сквозной запрос и денежные затраты на выполнение запросов, сгенерированных на основе всех 22 типов запросов эталонного теста TPC-H, и эти затраты сведены в табл. 4.2. Эти результаты усреднены при выполнении запросов на обеих унифицированных системах.

Из табл. 4.2 видно, что SVM дает лучшее время ответа на запрос. Как показано на рис. 4.5, три модели имеют очень схожую точность моделей. Это означает, что оптимизатор имеет аналогичный шанс выполнить полезную повторную оптимизацию, используя любую из этих моделей. Однако для применения этих моделей требуется разное количество времени. Поскольку эти модели применяются в интерактивном режиме во время выполнения запроса, накладные расходы, вызванные использованием этих моделей, добавляются ко времени ответа на запрос. Таким образом, небольшая разница в этих накладных расходах может вызвать значительную разницу во времени ответа на запрос и, таким образом, имеет решающее значение для пользователей.

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

а) Среднее время ответа б) Средняя стоимость

на сквозной запрос (с) выполнения запросов

■ Нейронная сеть 1 Случайный лес вУМ

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

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

Таблица 4.2

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

Нейронная сеть Случайный лес SVM

Среднее время ответа на запрос, с 36.2 35.4 31.5

Совокупное время ответа на 2200 запросов из 22 типов запросов, с 79.2 77.88 69.3

Средняя денежная стоимость запроса, у.е. 0.070 0.071 0.069

Общая денежная стоимость на 2200 запросов из 22 типов запросов, у.е. 154.6 156.2 151.8

В целом, SVM имеет лучшую точность прогнозирования и время ответа на запрос, а также занимает второе место по стоимости в денежном выражении. Таким образом, в следующих экспериментах SVM выбрана в качестве модели машинного обучения, которая будет использоваться в предлагаемой нами повторной оптимизации запросов на основе машинного обучения, ReOptML, и далее этот алгоритм сравнивается с другими алгоритмами повторной оптимизации запросов. Модель выбрана только для сравнения; на деле отдельной задачей является то, какая модель должна быть выбрана автоматически, поскольку некоторые QEP могут выполняться быстрее, но стоят больше денег и наоборот, в зависимости от

выбранной модели.

4.4. Производительность различных алгоритмов повторной оптимизации запросов

В этом разделе сравнивается производительность сквозной обработки запросов (end-to-end query processing performances), полученная при включении в обработку запросов следующих алгоритмов повторной оптимизации запросов: 1) предлагаемый алгоритм (ReOptML); 2) алгоритм, представленный в [4.6] (обозначен как ReOpt на рисунках), где повторная оптимизация запроса проводится автоматически после завершения выполнения каждого этапа в запросе; алгоритм [4.16] (обозначается как Tukwila), хорошо известный алгоритм повторной оптимизации адаптивного запроса, который запускает повторную оптимизацию после выполнения оператора, если разница между оценочной стоимостью запроса и фактической стоимостью запроса превышает некоторые порог; и базовый алгоритм, при котором запросы обрабатываются без какой-либо повторной оптимизации запроса (обозначается как NoReOpt).

Запускается 2200 запросов, при этом по 100 запросов создается из каждого 22 типов запросов TPC-H как для однородных, так и для асимметричных данных. Сравнивается среднее время ответа на запрос и денежную стоимость. Устанавливаются типы запросов, которые в среднем сильно различаются между ReOpt и ReOptML, чтобы с помощью машинного обучения можно было увидеть, сколько улучшений можно получить с помощью повторной оптимизации.

4.4.1. Асимметричные данные

Асимметричные данные: сравнивается предложенный алгоритм с Tukwila, NoReOpt и ReOpt на асимметричных данных. Результаты

экспериментов показывают, что предложенный алгоритм работает лучше всего как с точки зрения времени ответа на запрос, так и с точки зрения затрат. Из рис. 4.7а видно, что в среднем ЯеОр1МЬ дает на 13%, 22% и 35% меньше времени ответа на запрос, чем ЯеОр1;, Тикш1а и КоЯеОр11, соответственно. Из рис. 4.7б видно, что в среднем ЯеОр1МЬ тратит на 17%, 34% и 35% меньше денег, чем КоЯеОр1, ЯеОр1 и Тикш1а, соответственно.

Приведенные результаты показывают, что ЯеОр1МЬ экономит больше времени и денежных средств, чем три других алгоритма: ЯеОр11, Тикш1а и КоЯеОр11. В этом эксперименте повторная оптимизация способствует этой экономии и имеет два преимущества. Во-первых, после повторной оптимизации оптимизатор реализует различные типы физических операторов. Различные типы физических операторов, такие как КеБ1еёЬоор1от или НаБЫот, используемые для выполнения этих присоединений, могут привести к большой разнице во времени ответа на запрос. Во-вторых, повторная оптимизация помогает определить степень параллелизма каждого оператора, чтобы сэкономить много денег, поскольку для выполнения этих операторов используется меньшее количество контейнеров. Однако не все повторные оптимизации полезны, проведение более полезных повторных оптимизаций и избежание ненужных повторных оптимизаций может еще больше повысить производительность. Проведено сравнение QEP до и после повторной оптимизации в каждом алгоритме, чтобы выяснить, действительно ли каждая повторная оптимизация необходима или нет. В этом эксперименте почти 70% повторных оптимизаций необходимы в ЯеОр1МЬ, в то время, как только 35% в ЯеОр1 и 28% в Тикш1а. Таким образом, использование машинного обучения помогает сократить как временные, так и денежные затраты на выполнение запросов, избегая ненужных повторных оптимизаций.

tj

к °

5 & s d

а Я 40

И S3

aj П g « 20

я

o

Асимметричные данные

Q2

03 05 07 08 09 018

Q21

Тип очереди 1ЧоКеОр1 КеОр1 ТиктИа ИеС^МЬ

а) Среднее время ответа на запрос для асимметричных данных

Асимметричные данные

Тип очереди Р^оЛеОр! ИеОр! ТиктИа ЫеОр1МЬ

б) Затраты на выполнение одного запроса для асимметричных

данных

а 60

" К

О» & 8 40

оа 53

о» к _ _

о> Я п ответа ы о о

<и Он и

Однородные данные

¿-Я, М-11111Л ЧЬ»

hiüú

Q2

Q21

Q3 OS Q7 Q8 Q9 Q18

Тип очереди NoReOpt ReOpt Tukwilla ReOptML

в) Среднее время ответа на запрос для однородных данных

Тип очереди 1ЧоКеОр1 КеОр1 Тик>уШа ЯеС^МЬ

г) Затраты на выполнение одного запроса для однородных данных Рис. 4.7. Среднее время ответа на запрос и затраты на выполнение одного запроса из типов Q2, Q3, Q5, Q7, Q8, Q9, Q18, Q21 запросов для асимметричных данных (а, в) и для однородных данных (б, г)

4.4.2. Однородные данные

Однородные данные. В дополнение к результатам, полученным при выполнении запросов к асимметричным данным, на рис. 4.7 (в) и (г) также показаны результаты выполнения тех же запросов к однородным данным. Из рис. 4.7 (в) видно, что в среднем ЯеОр1МЬ дает на 13%, 13% и 21% меньше времени ответа на запрос, чем ЯеОр11, Тик-ш1а и КоЯеОр11, соответственно. Общая экономия времени ответа на запрос в результате использования ЯеОр1МЬ, ЯеОр11, Тик-ш1а и КоЯеОр1 для однородных данных меньше, чем для асимметричных данных, поскольку оптимизатор предполагает, что данные по умолчанию распределены равномерно. Таким образом, ошибка оценки стоимости на однородных данных меньше, чем на асимметричных данных. Это показывает, что повторная оптимизация запросов в целом более полезна при выполнении запросов с асимметричными данными. Что касается денежных затрат, из рис. 4.7 (г) в среднем видно, что ЯеОр1МЬ тратит столько же денег, что и ЯеОр11, на 7% меньше денег, чем Тик'^а, но на 10% больше денег, чем КоЯеОр11. Из этих

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

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

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

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

Структура распределенной программной системы в части разработанных средств представлена на рис. 4.8. При разработке использован инструментарий сред разработки (Tez, Spark и MapReduce).

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

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

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

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

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

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

4.6. Выводы

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

Представлен алгоритм под названием ЯеОр1МЬ, который использует модель на основе машинного обучения, чтобы решить, следует ли

повторно оптимизировать запрос. Проведенные эксперименты показывают, что для асимметричных данных ЯеОр1МЬ улучшает время ответа на запрос (с 13% до 35%) и денежные затраты (с 17% до 35%) по сравнению с существующими алгоритмами, которые не используют повторную оптимизацию, оптимизацию после каждого этапа в плане выполнения запроса (QEP) выполняется повторная оптимизация, когда достигается контрольная точка и разница между фактической стоимостью запроса и расчетной стоимостью запроса превышает некоторый порог. Для однородных данных предлагаемый алгоритм также улучшает время ответа на запрос (с 13% до 21%) по сравнению с существующими алгоритмами, но не улучшает денежные затраты. Алгоритм машинного обучения, предложенный в работе, обеспечивает только двоичное решение о том, следует ли проводить повторную оптимизацию, и модель полагается на статистику данных, которая может быть доступна не во всех СУБД.

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

Список источников к главе 4

4.1. Bruno N., Jain S., Zhou J. Continuous cloud-scale query optimization and processing. VLDB Endow. 2013;11(6):961-972.

4.2. Wolf F., May N., Willems R., Sattler K.-U. On the Calculation of Optimality Ranges for Relational Query Execution Plans. 2018 International Conference on Management of Data (SIGMOD '18). 2018;663-675.

4.3. Deshpande A., Ives Z., Raman V. Adaptive Query Processing. Foundations and Trends in Databases. 2017;1(1):1-140.

4.4. Markl V., Raman V., Simmen D., Lohman G., Pirahesh H., Cilimdzic M. Robust query processing through progressive optimization. ACM SIGMOD International Conference on Management of data (SIGMOD '04). 2004;659-670.

4.5. https://www.postgresql.org.

4.6. Bankole A.A., Ajila S.A. Predicting cloud resource provisioning using machine learning techniques// 26th IEEE Canadian Conference on Electrical and Computer Engineering (CCECE), p.1-4, 2013.

4.7. Breiman L. Random Forests. Machine Learning. 2001;45(5):5-32.

4.8. Schmidhuber J. Deep Learning in Neural Networks: An Overview// Neural Networks, vol. 61, no. 10, p.85-117, 2014

4.9. Corinna C., Vapnik V. Support-vector networks// Machine Learning. 20 (3), 1995.

4.10. Liu H., Xu M., Yu Z., Corvinelli V., Zuzarte C. Cardinality Estimation Using Neural Networks. 25th Annual International Conference on Computer Science and Software Engineering (CASCON '15). 2015;53-59.

4.11. Kipf A., Kipf T., Radke B., Leis V., Boncz P., Kemper A. Learned Cardinalities: Estimating Correlated Joins with Deep Learning// 9th Biennial Conference on Innovative Data Systems Research (CIDR'19), 2019.

4.12. Saravanan T., Shohedul H., Nick K., Gautam D. Approximate Query Processing for Data Exploration using Deep Generative Models. 36th

International Conference on Data Engineering (ICDE). 2020;1309-1320.

4.13. Helff F., Gruenwald L., d'Orazio L. Weighted Sum Model for Multi-Objective Query Optimization for Mobile-Cloud Database Environments. EDBT/ICDE Workshops. 2016;1558:751-760.

4.14. Barata M., Bernardino J., Furtado P. An Overview of Decision Support Benchmarks: TPCDS, TPC-H and SSB// Advances in Intelligent Systems and Computing, vol. 353, p. 619-628, 2015

4.15. Wang W., Zhang M., Chen G., Jagadish H.V., Ooi B.C., Tan K.-L. Database Meets DeepLearning: Challenges and Opportunities// SIGMOD Rec., 45(2), p.17-22, 2016.

4.16. Marcus R., Negi P., Mao H., Zhang C., Alizadeh M., Kraska T., Papaemmanouil O., Tatbul N. Neo: a learned query optimizer// VLDB Endow. 12, 11, p.1705-1718, 2019.

4.17. Navin K., David D. Efficient mid-query re-optimization of suboptimal query execution plans// SIGMOD Rec. 27, 2, pp.106-117, 1998.

Заключение

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

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

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

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

3. Разработан модифицированный алгоритм повторной оптимизации запросов, обеспечивающий повышение эффективности повторной оптимизации запросов.

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

5. Элементы программного обеспечения зарегистрированы в ФИПС.

Рекомендации и перспективы дальнейшей разработки темы

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

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

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

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

1. Аль Мусави О.А.Р., Кравец О.Я. Алгоритмизация повторной оптимизации запросов в облачных базах данных на основе компьютерного обучения// Моделирование, оптимизация и информационные технологии, Т. 22, №1. 11с. ЬИрв://ёо1.о^/10.26102/2310-6018/2022.36.1.020.

2. Аль Мусави О.А.Р., Кравец О.Я. Вычислительный эксперимент по исследованию результатов повышения безопасности и оптимизации репликаций для облачных маршрут-нестабильных сетей// Информационные технологии моделирования и управления, №2(124), 2021. - С. 141-151.

3. Аль Мусави О.А.Р., Кравец О.Я. Исследование алгоритмов повторной оптимизации запросов в облачных базах данных// Решение: матер. 11-й Всеросс. НПК. - Пермь: Изд-во Перм. нац. исслед. политехн. ун-та, 2022. - С. 168-171.

4. Аль Мусави О.А.Р., Кравец О.Я. Повышение безопасности и оптимизация репликаций, основанные на оптимальных маршрутах для облачных маршрут-нестабильных сетей// Системы управления и информационные технологии, №2(84), 2021. - С. 69-74.

5. Аль Мусави О.А.Р., Кравец О.Я. Проблемы обеспечения надежности и безопасности репликаций в маршрут-нестабильных сетях // Труды Всероссийской научной конференции «Достижения науки и технологий-ДНиТ-2021». - Красноярск, 2021. С. Ийр://ги-соп£ёошш1.т/шеё1аЯ11ег_риЬНс/34/1а/341аа8с6-7Г88-420Ь-9881-Ге5261еааЬ6е/3003-ёш1;-2021.рё£/

6. Аль Мусави О.А.Р., Красновский Е.Е. Экспериментальное исследование эффективности алгоритмов повторной оптимизации запросов в облачных базах данных на основе компьютерного обучения// Системы управления и информационные технологии, №3(89), 2022. - С.

29-34

7. Вентцель Е.С., Овчаров Л. А. Теория случайных процессов и ее инженерные приложения. - М.: Наука. Гл. ред. физ.-мат. лит. - 1991.

8. Волков Д. Как оценить рабочую станцию // Открытые системы, №2, 1994, С. 44-48.

9. Волков Д., Французов Д., Новое поколение тестов SPEC. / Открытые системы, №4, 1996, С. 73-74.

10. Гамильтон С. Управление цепочками поставок с Microsoft Axapta. - М.: Альпина Бизнес Букс, 2005, 352 с.

11. Гешвинде Э., Шенинг Г.Ю. Разработка WEB-приложений на PHP и PostgreSQL. М.: ДиаСофт, 2003.- 608 C.

12. Ги К. Введение в локально-вычислительные сети. - М.: Радио и связь, 2000. - 190 с.

13. Гнеденко Б.В., Коваленко И.Н. Введение в теорию массового обслуживания, 2-е изд., М.:Наука, 1987. - 336 C.

14. Говорский А.Э., Кравец О.Я. Особенности взаимодействия подсистем при решении задач интегрального обслуживания неоднородного трафика // Системы управления и информационные технологии. 2008. Т. 31. № 1.1. С. 141-146.

15. Горшков А.В., Кравец О.Я., Аль Мусави О.А.Р., Гребенникова Н.И. Программа визуального моделирования миграции агентов в мультиагентной системе. - Свидетельство о регистрации программы для ЭВМ № 2022685251 от 22.12.2022. - М.: ФИПС, 2022.

16. ГОСТ 28195-89 Оценка качества программных средств. Общие положения. Введен 01.07.90. - 39 С.

17. ГОСТ 28806-90 Качество программных средств. Термины и определения. Введен 01.01.92. - 12 С.

18. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Введен 01.07.94. - 19 С.

19. Гриневич А.И., Кулямин В.В., Марковцев Д.А., Петренко А.К., Рубанов В.В., Хорошилов А.В. Использование формальных методов для обеспечения соблюдения программных стандартов. - Тр. института системного программирования РАН. - 2006. - Т.10, с. 51-68.

20. Грязнов Н.Г., Димитриев Ю.К., Мелентьев В. А. Оптимизация отказоустойчивого вложения диагностического графа в тороидальные структуры живучих вычислительных систем// Автоматика и телемеханика. 2003. № 4. С. 133-152.

21. Дастин Э., Рэшка Д., Джон П. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. - М.: Лори, 2003.

22. Дейт К. Введение в системы баз данных - 6-е изд. - Киев: Диалектика, 1998. - 784 C.

23. Дейтел Х., Дейтел П., Нието Т. Как программировать для Internet & WWW М.: Бином, 2002, - 1184 C.

24. Денисов А.А., Колесников Д.Н. Теория больших систем управления. Л.: Энергоиздат, 1982. - 288 C.

25. Диго С.М. Проектирование и использование баз данных. М.: Финансы и статистика, 1995. -208 C.

26. Дрожжинов В.И. От теста не уйдешь// Мир ПК, N 2, 1993.

27. Жожикашвили В. А., Вишневский В.М. Сети массового обслуживания. Теория и применение к сетям ЭВМ. М.: Радио и связь, 1988. - 192 C.

28. Журков А.П., Аминев Д.А., Гусева П.А., Мирошниченко С.С., Петросян П.А. Анализ возможностей применения подходов самодиагностирования к распределенной радиотехнической системе

наблюдения// Системы управления, связи и безопасности. 2015. № 4. С. 114-122.

29. Задорожный В.Н. Модели и системы. Анализ научного мышления. - Омск, ОМГТУ, 1999. - 100 с.

30. Задорожный В.Н. Статистическое моделирование. - Омск: Изд-во ОмГТУ, 1996. - 92с.

31. Иванов П. Управление информационными системами: базовые концепции и тенденции развития // Открытые системы, №4, 1999, C. 37-43.

32. Камер Д. Компьютерные сети и Internet М.: Вильямс, 2002.640 С.

33. Кастаньетто Д. и др. Профессиональное PHP программирование. М.: Символ - Плюс, 2001. - 912 C.

34. Кениг Д., Штоян Д. Методы теории массового обслуживания.-М.: Радио и связь, 1981. - 127 с.

35. Киллелиа П. Тюнинг WEB-сервера. СПб.: Питер, 2003. - 528 C.