CC BY
3
6. Болябкин М. В. Разработка и внедрение общего анализатора SQL // Международный журнал гуманитарных и естественных наук, 2022. - № 1-1(64). -С. 55-61. - DOI 10.24412/2500-1000-2022-1-1-55-61. - EDN PRDDVT.
7. Li H, Liu H, Liu Y, et al. An object-relational IFC storage model based on oracle database [j]. International Archives of the Photogrammetry Remote Sensing & S, 2016, XLI-B2:625-631.
8. Joseph S.R., Hlomani H, Letsholo K. Data Mining Algorithms: An Overview [J]. Neuroence, 2016, 12(3):719-43.
9. Ender Sevin9, Ahmet Co§ar. An Evolutionary Genetic Algorithm for Optimization of Distributed Database Queries [J]. Computer Journal, 2018, 54(5):717-725.
10. Стружкин Н.П. Базы данных: проектирование: Учебник для академического бакалавриата. - Люберцы: Юрайт, 2016. - 477 c.
11. Преснякова Г.В. Проектирование интегрированных реляционных баз данных: Учебное пособие. - М.: КДУ, 2007. - 224 c.
12. Малыхина, М.П. Базы данных: основы, проектирование, использование. -СПб.: BHV, 2007. - 528 c.
13. Морган С. Проектирование и оптимизация доступа к базам данных Microsoft SQL Server 2005. - М.: Русская редакция, 2008. - 480 c.
ПРОТОТИП ОПТИМИЗАТОРА ФЕДЕРАТИВНЫХ ЗАПРОСОВ
А.К. Гладков, Московский технический университет связи и информатики Gl.Al.K@ya.ru;
Д.А. Панов, Московский технический университет связи и информатики, panov135@mail.ru.
УДК 004.657_
Аннотация. Цель данной статьи - представить новый способ для создания оптимизатора федеративных запросов, основанный на машинном обучении. Предлагается модульная гибкая архитектура, позволяющая федеративному оптимизатору запросов интегрироваться с любой системой баз данных, поддерживающей язык структурированных запросов, практически без инженерных затрат. Наблюдая за производительностью внешних систем, оптимизатор изучает и строит модели затрат, обеспечивая оптимизацию объединенных запросов при незначительном взаимодействии с внешними системами. Чтобы продемонстрировать потенциал этого плана исследований, представлен прототип оптимизатора федеративных запросов, построенного при помощи Spark SQL. Реализация эффективно ускоряет федеративные запросы, увеличивая время выполнения запросов до 7,5 раз по сравнению со стандартной реализацией Spark SQL.
Ключевые слова: федеративная обработка запросов; оптимизация запросов; машинное обучение; SQL; база данных.
PROTOTYPE OF THE FEDERATED QUERY OPTIMIZER
А.К. Gladkov, Moscow technical university of communications and informatics; D.A. Panov, Moscow technical university of communications and informatics.
Annotation. The purpose of this article is to present a new way to create federated query optimizer based on machine learning. A modular flexible architecture is proposed that allows the federated query optimizer to integrate with any database system that supports the Structured query language (SQL), with virtually no engineering costs. Observing the performance of external systems, the optimizer studies and builds cost models, ensuring optimization of combined queries with little interaction with external systems. To demonstrate the potential of this research plan, a prototype of a federated query optimizer built using Spark SQL is presented. The implementation effectively speeds up federated queries, increasing query execution time up to 7,5 times compared to the standard Spark SQL implementation.
Keywords: federated query processing; query optimization; machine learning; SQL; database.
Введение
В сложной инфраструктуре современной экосистемы «больших данных» данные обычно распределяются по множеству разнообразных систем баз данных. Это привело к разработке объединенных механизмов запросов, которые позволяют пользователям одновременно запрашивать несколько баз данных, используя унифицированный интерфейс на основе языка структурированных запросов (Structured query language, SQL). Ряд механизмов федерации, разработанных некоторыми из крупнейших поставщиков баз данных, в том числе Athena Federated Query3, BigQuery4, Spark SQL, Presto5 [1] или Dremio6 за последние годы, предоставляют четкие доказательства важности механизмов федеративных запросов. Принимая во внимание неоднородность базовых систем, с которыми интегрируется механизм объединения, оптимизация объединенных запросов является одной из наиболее сложных задач для этих систем. Обычно механизм федеративных запросов использует универсальный подход, позволяющий подключаться к как можно большему количеству внешних систем баз данных. Таким образом, жизненный цикл запросов в большинстве систем федерации (например, Spark, Presto) довольно прост. Во-первых, механизм объединения передает все таблицы и представления, включенные в запрос, из внешних систем баз данных в механизм выполнения федерации через сеть. Также может быть применен ряд специфических оптимизаций на основе правил, например, pushdown подзапроса. Наконец, результирующий план запроса выполняется в механизме федерации. В идеале эффективный оптимизатор должен быть способен генерировать более сложные планы федеративных запросов, как в традиционных базах данных. Однако разнородная природа и архитектурные различия внешних систем делают задачу принятия решения о том какие части запроса следует отбросить и где, особенно сложной. Одной из основных проблем является сложность оценки стоимости выполнения подзапроса во внешней системе. Это сложная задача по целому ряду факторов. К примеру, из-за отсутствия доступа к статистике в удаленной системе баз данных оценка локальной стоимости выполнения (во внешней системе) и размера результата является очень сложной. Кроме того, увеличенное пространство поиска, возникающее в результате дополнительных решений по планированию (например, где выполнять каждый оператор) из-за федеративного выполнения делает оптимизацию еще более трудной.
В результате большинство механизмов федерации применяют очень мало оптимизаций на основе правил (например, выбор с понижением), отбрасывая возможности оптимизации, которые могли бы использовать весь потенциал
внешних систем. Несмотря на то, что были предприняты некоторые попытки разработать оболочки [2, 3] и пользовательские модели затрат [4], чтобы обеспечить более детальную генерацию планов федеративных запросов, эти подходы сталкиваются с некоторыми проблемами. Во-первых, разработка пользовательских оберток и моделей затрат для новых систем является утомительной задачей, что чрезвычайно затрудняет интеграцию с новыми системами. Во-вторых, связь с внешними системами для получения оценок затрат может замедлить оптимизацию, что известно, как стоимость калькуляции [5]. Подводя итог, можно сказать, что подход заключается в следующем:
• Представлена архитектура, основанная на машинном обучении, для оптимизации федеративных запросов, которая способна интегрироваться с любой системой баз данных на основе SQL с минимальными инженерными затратами;
• Представлена реализация архитектуры с использованием Spark SQL и демонстрация, как система может эффективно оптимизировать объединенные запросы в нескольких системах с нулевыми затратами на связь;
• Обсуждение экспериментальной оценки, которая демонстрирует способность системы эффективно изучать производительность внешних систем, в то время как сгенерированные планы выполнения федеративных запросов всегда превосходят Spark SQL.
Оптимизация федеративных запросов на основе машинного обучения
На рис. 1 изображена архитектура прототипа оптимизатора федеративных запросов. В этом разделе описывается каждый отдельный компонент системы.
Рисунок 1
1) Векторизатор запросов. Векторизатор запросов принимает в качестве входных данных проанализированный SQL-запрос в форме абстрактного
синтаксического дерева (Abstract syntax tree, AST) и преобразует его в вектор, который представляет семантику запроса, например, какие таблицы объединяются в запросе или в каких столбцах применяется оператор GROUP BY. В текущей версии было решено придерживаться простого подхода с одним кодированием. Каждый оператор запроса представлен вектором. Например, вектор агрегации д = [1, 0, 0, 1] представляет запрос, в котором оператор GROUP BY применяется к первому и четвертому столбцам. Объединяются все векторы для всех предикатов, которые нужно включить в пространство поиска, далее создается единый вектор, представляющий полный запрос.
2) Изучение модели затрат. Для изучения моделей затрат используются данные, полученные в результате прошлых и текущих рабочих нагрузок. Для каждого запроса сохраняется время его выполнения и его векторная форма. Эти данные передаются в модель машинного обучения, которая предсказывает время выполнения будущих запросов. Текущий прототип обучает свои модели с учетом времени выполнения. Однако этот подход можно легко изменить, чтобы учесть больше целей, таких как денежные затраты в облачной среде.
3) Оптимизатор федеративных запросов. Оптимизатор федеративных запросов использует первые два компонента для создания почти оптимальных федеративных планов. Во-первых, он преобразует AST-форму запроса в граф, в котором каждая вершина представляет одну таблицу и ее местоположение, в то время как ребро представляет соединение между двумя таблицами. Оптимизатор работает в два этапа. Первый проход, который называется поиском по местоположению, является расширением традиционного алгоритма поиска по ширине, который пересекает граф и генерирует новое двоичное дерево со следующим свойством. Гарантируется, что все вершины (таблицы), которые находятся в одном и том же местоположении, будут совместно расположены в одном и том же поддереве (всякий раз, когда это возможно, учитывая семантику запроса). Второй проход обрабатывает каждое поддерево в каждом местоположении и выполняет необходимые преобразования, руководствуясь изученной моделью затрат. Например, в некоторых случаях может иметь смысл разбить поддерево, объединяющее четыре таблицы, на два поддерева, которые соединяют две таблицы, чтобы избежать вычисления большого результата и извлечения этого результата в механизм федерации по сети. Это достигается путем настройки параметра join_limit, который определяет максимальный размер подзапроса, который может быть уменьшен для локального выполнения во внешнюю систему.
4) Федеративный переписчик. Этот модуль принимает в качестве входных данных объединенный план запроса, созданный на предыдущем шаге. Для каждого поддерева, которое ссылается на определенное местоположение (систему базы данных) плана запроса, оно выполняет генерацию SQL-кода, который будет отправлен во внешнюю систему для локального выполнения. Наконец, он генерирует SQL-код, который будет выполняться в механизме федерации, который будет агрегировать результаты каждого запроса компонента, выполняемого во внешних местоположениях.
Жизненный цикл запроса
Жизненный цикл запроса выполняется по тем же шагам, что и в предыдущем разделе. Сначала анализируется SQL-запрос и преобразуется в соответствующую форму AST. Затем этот запрос передается векторизатору, который преобразует его в соответствующую векторную форму. Затем
оптимизатор берет AST запроса, преобразует его в соответствующий график и создает окончательный объединенный план запроса. Наконец, объединенный план передается переписчику, который выполнит необходимую генерацию кода SQL для внешних систем и механизма федерации. Затем запрос выполняется с использованием как внешних систем, так и механизма федерации, и результат возвращается пользователю. В конце выполнения также сохраняются метрики выполнения запросов, такие как общее время выполнения и индивидуальное время выполнения подзапросов во внешних механизмах. Эти показатели требуется сохранять для того, чтобы переобучить и усовершенствовать изученные модели затрат и поддерживать их в актуальном состоянии. Как упоминалось выше, ключевыми преимуществами данного оптимизатора федеративных запросов являются следующие:
1) Векторизатор запросов позволяет легко интегрировать систему с любой системой, поддерживающей SQL, делая специфику проектирования внешней системы прозрачной для механизма федерации. Например, в реализации через Spark SQL используются драйверы JDBC для подключения к внешней системе. Затем система работает только с промежуточным представлением Spark (AST) входного запроса. Эта конструкция будет работать точно так же на любом возможном наборе подключенных систем.
2) Минимизация потенциальных накладных расходов на связь во время оптимизации. Благодаря использованию изученных моделей затрат оценки для каждого подзапроса в каждой внешней системе вычисляются быстро, в то время как большая часть времени оптимизации тратится на полезную работу, то есть на перечисление планов. На рис. 2 представлена архитектура оптимизатора федеративных запросов.
Векторизатор 10.1,... и План
о J Ь Ц-.
Модель затрат ; -* SOL иода
i Оптимизатор
Рисунок 2
Таблица 1. Время выполнения запросов
Система Среднее время выполнения запроса (с)
Spark SQL 1,15
Оптимизатор федеративных запросов 0,152
Предварительные результаты
Прототип оценивался экспериментально и сравнивался с Spark SQL. Цель -показать, что он может эффективно выбирать правильную подсистему для выполнения каждого подзапроса, а результирующие планы превосходят стандартную реализацию Spark SQL. Прототип оценивался на MacBook Pro с 16 ГБ оперативной памяти и чипом Apple M1. Инфраструктура состоит из автономного одноузлового кластера Spark SQL, одного экземпляра Postgres 14.0 и одного экземпляра MySQL 8.0.27, все они работают на одном компьютере.
Изученные модели затрат. Сначала была произведена оценка эффективности оптимизатора при выборе наиболее производительного механизма выполнения. Для этого эксперимента был использован набор данных эталона поддержки принятия решений, разработанный советом по эффективности
обработки транзакций (TPC-H), делая все таблицы доступными во всех системах. Сначала запускался набор микротестов, со случайным выбором некоторых из запросов TPC-H, чтобы собрать данные и обучить модели затрат. Затем были запущены все запросы TPC-H для оценки системы. Для каждого запроса TPC-H оптимизатору помогают изученные модели затрат, и он решает, лучше ли отправить полный запрос в MySQL, Postgres или извлечь все данные и выполнить запрос в Spark. С целью эксперимента был запущен каждый запрос в двух режимах, что позволило сравнить решение оптимизатора со Spark SQL. Результаты представлены в табл. 1 и отображают время выполнения от начала до конца, включая обработку запросов и извлечение данных из внешних систем. При использовании оптимизатора, достигается среднее ускорение в 7,5 раз по сравнению с Spark SQL.
Оптимизированные запросы. Для этого раздела был использован эталонный показатель работы. В этом сценарии таблицы случайным образом размещаются в MySQL и Postgres. Для этих запросов были проведены эксперименты с изменением максимального количества таблиц (параметр joinlimit), которые могут быть включены в подзапрос, передающийся для локального выполнения внешней подсистеме. Используя самый первый прототип оптимизатора на основе обучения с подкреплением, который проверяет различные значения параметра join_limit, удалось прийти к выводу, что для этой настройки ограничение соединения должно быть либо два, либо три. При этих значениях среднее время выполнения запроса составляет 60% от времени, необходимого для стандартной реализации Spark SQL. Это улучшение достигается, главным образом, за счет разделения выполнения запросов между Spark SQL и внешними системами (например, путем удаления части соединения), используя как механизм федерации, так и системы, к которым он подключается.
Заключение
В данной статье представлен прототип оптимизатора федеративных запросов, основанный на машинном обучении. Предварительные результаты показывают, что оптимизация федеративных запросов на основе ML обеспечивает заметное повышение производительности по сравнению с Spark SQL. В отличие от прочих работ по федеративной обработке запросов, предложенный прототип использует машинное обучение, чтобы справиться с неоднородностью систем баз данных. Оптимизатор способен подключать новые системы с минимальными инженерными затратами и эффективно оптимизировать объединенные запросы с минимальными затратами на связь.
Литература
1. Karpathiotakis M., Floratou A., Ozcan F., Ailamaki A. No data left behind: realtime insights from a complex data ecosystem, in: Proceedings of the 2017 Symposium on Cloud Computing, 2017. - pp. 108-120.
2. Giannakouris V., Papailiou N., Tsoumakos D., Koziris N. Musqle: Distributed sql query execution over multiple engine environments, in: 2016 IEEE International Conference on Big Data (Big Data), IEEE, 2016. - pp. 452-461.
3. Deshpande A., Hellerstein J.M. Decoupled query optimization for federated database systems, in: Proceedings 18th International Conference on Data Engineering, IEEE, 2002. - pp. 716-727.
4. Marcus R., Negi P., Mao H., Zhang C., Alizadeh M. Neo: A learned query optimizer, arXiv preprint arXiv:1904.03711 (2019).
5. Sheth A.P., Larson J.A. Federated database systems for managing distributed, heterogeneous, and autonomous databases, ACM Computing Surveys (CSUR) 22 (1990). - pp. 183-236.
6. Leis V., Gubichev A., Mirchev A., Boncz P., Kemper A., Neumann T. How good are query optimizers, really? Proceedings of the VLDB Endowment 9, 2015. - pp. 204-215.
7. Мартишин С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Методы и средства проектирования информационных систем и технолог. - М.: Форум, 2017. - 62 c.
8. Мюллер Р.Д. Проектирование баз данных и UML. - М.: Лори, 2013. - 420 c.
9. Стружкин Н.П. Базы данных: проектирование: Учебник для академического бакалавриата. - Люберцы: Юрайт, 2016. - 477 c.
10. Преснякова Г.В. Проектирование интегрированных реляционных баз данных: Учебное пособие. - М.: КДУ, 2007. - 224 c.
11. Малыхина М.П. Базы данных: основы, проектирование, использование. - СПб.: BHV, 2007. - 528 c.
12. Морган С. Проектирование и оптимизация доступа к базам данных Microsoft SQL Server 2005. - М.: Русская редакция, 2008. - 480 c.
13. Болябкин М.В. Разработка и внедрение общего анализатора SQL // Международный журнал гуманитарных и естественных наук, 2022. - № 1-1(64). -С. 55-61. - DOI 10.24412/2500-1000-2022-1-1-55-61. - EDN PRDDVT.
14. Armbrust M., Xin R.S., Lian C., Huai Y., Liu D., Bradley J.K., Meng X., Kaftan T., Franklin M.J., Gh- odsi A. et al., Spark sql: Relational data processing in spark, in: Proceedings of the 2015 ACM SIGMOD international conference on management of data, 2015. - pp. 1383-1394.
15. Marcus R., Negi P., Mao H., Tatbul N., Alizadeh M., Kraska T., Bao: Making learned query optimization practical, ACM SIGMOD Record 51, 2022. - pp. 6-13.
16. McLeod D., Heimbigner D. A federated architecture for database systems, in: Proceedings of the May 19-22, 1980, national computer conference, 1980. - pp. 283-289.
17. Xu L., Cole R.L., Ting D. Learning to optimize federated queries, in: Proceedings of the Second International Workshop on Exploiting Artificial Intelligence Techniques for Data Management, 2019. - pp. 1-7.
18. Josifovski V., Schwarz P., Haas L., Lin E., Garlic: a new flavor of federated query processing for db2, in: Proceedings of the 2002 ACM SIGMOD international conference on Management of data, 2002. - pp. 524-532.
АНАЛИЗ АЛГОРИТМОВ РАСПОЗНАВАНИЯ ДАТЧИКОМ ЗВЕЗДНОЙ ОРИЕНТАЦИИ КОСМИЧЕСКОГО АППАРАТА
A.С. Чечельницкий, Московский технический университет связи и информатики, mr.vip64@yandex.ru;
Д.А. Везарко, Московский технический университет связи и информатики, vezarko00@mail.ru;
B.А. Коптев, Московский технический университет связи и информатики, УУУ. xxx.98@bk.ru.
УДК520.6.07: 520.6.05_
Аннотация. На этапе развития общества большой интерес в исследовании вызывает космическое пространство, космические аппараты с системами
