АВТОМАТИЧЕСКАЯ ТРАНСЛЯЦИЯ ЗАПРОСОВ ИЗ ФОРМАТА MYSQL В ФОРМАТ MONGODB C УЧЕТОМ СТРУКТУРЫ БАЗЫ ДАННЫХ Текст научной статьи по специальности «Компьютерные и информационные науки»

МА ТЕМА ТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН, КОМПЛЕКСОВ И КОМПЬЮТЕРНЫХ СЕТЕЙ

УДК 004 DOI: 10.24412/2071-6168-2021-4-294-301

АВТОМАТИЧЕСКАЯ ТРАНСЛЯЦИЯ ЗАПРОСОВ ИЗ ФОРМАТА MYSQL В ФОРМАТ MONGODB C УЧЕТОМ СТРУКТУРЫ БАЗЫ ДАННЫХ

В.М. Ха

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

Ключевые слова: MySQL, MongoDB, обработка запросов, трансляции запроса, синтаксический анализ.

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

Большинство организаций на сегодняшний день в момент принятия решений о переходе на СУБД NoSQL уже имеют реляционные системы хранения данных. Реляционные БД удерживали и продолжают удерживать первенство по популярности начиная с 80-х годов 19 века. Многие популярные СУБД NoSQL, такие как MongoDB не имеют интерфейса, схожего с SQL для своих систем. Поэтому, проблема автоматического перевода запросов из существующей реляционной базы данных в новый формат NoSQL является одновременно актуальной и сложной задачей. Сложность решения задачи автоматизации процесса трансляции запросов из формата SQL в формат NoSQL связана, во-первых, с различием синтаксисов языков запросов, во-вторых, с различием моделей хранения данных в БД SQL и БД NoSQL.

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

В работах [1-4] описаны результаты исследований по созданию систем промежуточного уровня, которые поддерживают выполнение запросов SQL к различным NoSQL базам данных. Например, решения, описанные в [1], подходят только для NoSQL баз данных типа ключ-значение, решения, описанные в [3], поддерживают выполнение запросов SQL для баз данных SQL Amazon. В исследовании [2] автор остановился только на уровне с простыми запросами, а сложная структура запросов еще не разработана. В [4] автор фокусируется на сравнении структуры запросов различных типов базы данных NoSQL и SQL, но не предоставляет формализованный способ для перехода от одной формы запроса к другой. Поэтому результат этой работы больше подходит для администраторов баз данных, чем для конечных пользователей, извлекающих данные для анализа.

Исследования по построению универсального языка запросов для разных типов баз данных описаны в [5]. Авторы предлагают язык UnQL (Unstructured Query Language) для работы с данными из разных баз данных NoSQL. Идея авторов [5] состояла в том, чтобы создать язык для документно-ориентированных моделей баз данных, таких как CouchDB и MongoDB. Синтаксис описанного ими языка похож на синтаксис SQL и включает CRUD команды (создание, чтение, обновление, удаление). Схожие исследования проводились авторами [6], которые представили описание языка Impala. Это инструмент обработки запросов с открытым исходным кодом, который позволяет создавать запросы в формате SQL к таблицам Hbase.

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

В данной работе мы представляем разработанный нами подход к автоматической трансляции запросов из формата SQL в формат MongoDB. MongoDB представляет собой базу данных NoSQL типа ключ-документ, которая широко используется из-за высокой производительности, доступности и возможности горизонтального расширения. Основными структурами хранения данных в MongoDB являются: база данных, коллекция и документы. Как и другие типы баз данных, MongoDB также имеет свой собственный язык запросов, который отличается от формата SQL. Наша цель состоит в том, чтобы разработать систему, которая позволит пользователю просто запросить данные из базы данных в MySQL и MongoDB, не требуя понимания структуры запроса MongoDB.

Основные этапы трансляции запроса из MySQL в MongoDB. Предлагаемый нами подход к автоматической трансляции запросов из формата SQL в формат MongoDB с учетом структуры баз данных MySQL и MongoDB состоит из 4 этапов (рис.1).

Этап 1: Парсинг запроса в формате MySQL. Парсинг или синтаксический анализ можно объяснить как процесс анализа компьютерных языков (языков программирования, языков запросов) с формальной грамматикой. Целью данного этапа является разбор кода входного запроса на токены. Токенами запросов являются части запросов (ключевые слова, параметры, число, знак). Самой большой сложностью при парсинге является обеспечение точности результата запроса. Результат запроса напрямую зависит от структуры запроса и от способа построения SQL-предложения. В этом случае

стандартные функции обработки строк классических высокоуровневых языков программирования вроде C++, Java и других или регулярные выражения применимы, но значительно усложняют код программы по разбору запроса и значительно сокращают варианты возможного написания запроса. В нашем случае для разбора запроса MySQL применялась теория грамматик [7]. Итогом разбора запроса является список сырых то-кенов. При этом под выражением «сырые токены» понимается список токенов, который непосредственно получен из запроса. При этом в нем отсутствует привязка не ключевых токенов к ключевым словам SQL.

Пример. Пусть дан запрос в формате SQL:

SELECT Dateorder FROM t1, t2 WHERE t1.keyt1 = t2.keyt1 and Name = "Jad-

ed336"

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

['SELECT', [[['Date order']]], 'FROM', [['t1'], ['t2'], []], 'WHERE', [[['t1', '.', 'key_t1'], '=', ['t2', '.', 'key_t1']], 'AND', [['name'], '=', 'Jared336']]]

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

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

Для запроса из вышенаписанного примера сформированные списки не ключевых токенов будут выглядеть так:

Рис. 2. Пример формирования списков не ключевых токенов

296

Этап 2: Формирование словаря предложений запроса MongoDB. В базе данных MongoDB по аналогии с оператором запроса SELECT в MySQL для извлечения данных используется метод Find(). Однако просто замена оператора SELECT на метод Find() в некоторых случаях приводит к неверным результатам, например, при выполнении запросов к коллекциям с вложенными документами. Поэтому вместо метода Find() лучше применять метод Aggregate(O). На основе результатов парсинга на этапе 1 и с учетом синтаксиса операции агрегации данных в MongoDB на втором этапе строится словарь, который включает в себя токены запроса следующим образом:

S= {

'aggregate': {True|False}, 'collection': ['collection 1', ..., 'collection n'], 'fields': {field 1: 1|0, ..., field n:1|0}, 'spec': {expression 1, ..., expression n}, 'group_by': False|True, 'having': False|True,

'sort': False|True

}

Видно, что в словаре предложений запроса MongoDB некоторым предложениям ставится в соответствие одно из двух значений: «True» и «False». Если предложению соответствует значение «False», то оно не будет включено в формируемый запрос MongoDB.

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

Пример. Пусть есть некоторая коллекция Q:

Q ={key1:value1 , key2: [{key3:value3, key4:[{key5:value5, key6: value6}]}]} Дерево, соответствующее данной коллекции, представлено на рис. 2.

По рис.3 видно, что если поле «Key 1» участвует в запросе, то т.к. это поле находится на первом уровне, то взапрос непосредственно войдет имя этого поля. Если поля «key 3» или «key 5» участвуют в запросе, то их имена долны быть прописаны в

297

коде запроса через имена их родительских узлов. Например, {'Key2.Key4.Key5': '1', 'Key2.Key3': '1'}.

Под «глубиной коллекции» будем понимать число уровней вложенных документов в коллекции. Если n = 1, значит в коллекции не существует вложенных документов.

Этап 4 - Синтез выходного запрос из предложений словаря с учетом структуры базы данных MongoDB и на основе синтаксиса функции «aggregate» в MongoDB. Процесс синтеза осуществляется последовательно с проверкой наличия соответствующих предложений в словаре и при наличии добавлением их в код запроса.

Тестирование подхода к трансляции запросов из MySQL в MongoDB. Для тестирования описанного выше подхода к трансляции запросов из MySQL в MongoDB была разработана программа на языке программирования Python с применением библиотек Pyparsing, PyMongo.

Основные классы программы и их назначение:

- «SelectParser» и «ParsingMySQL» - разбор MySQL запроса;

- «MySQLtoMongoDB_parser», «Note2Tree» «RebuildQuery» - построение словаря предложений, участвующих в коде запросе MongoDB;

- «MainForm» - мониторинг результатов;

- «MySQL_execute» и «MongoDB_execute» - выполнение запросов к базам данных MySQL и MongoDB.

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

SelectParser

а

ParsingMySQL

а

RebuildQuery -*-

3

IJse

MySQLtoMongoDB_parser

Return Return

Use

а

MySQL_execute a

Use

MainForm a

MongoDB_execute a

MySQL

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

Для тестирования подхода к трансляции запросов из MySQL в MongoDB были использованы 2 варианта структуры базы данных на MongoDB, которые приведены на рис. 5. Они отличаются наличием в них вложенных документов. В табл. 1 приведены SQL-запросы, на основе которых проводилось тестирование.

Запросы для тестирования

Таблица 1

№ Запрос

Q1 SELECT Customer,Product_name,Date_order,Type From t1,t2,t3 Where t1.key_t1 = t2.key_t1 and t2.key t2 = t3.key t2

Q2 select Customer, Date_order,Product_name,Brand from t1,t2,t4 where t1.key_t1 = t2.key_t1 and t2.key t2 = t4.key t2 and Brand = 'Emnipedor Group'

Q3 select Product_name, Brand, Type from t2, t3, t4 where t2.key_t2 = t3.key_t2 and t2.key_t2 = t4.key t2 and Product name = 'Gropickazz' and Type = 'Type 9'

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

Т1

sHLid objectld NN

key_t1 double NN

Date_order string NN

Customer string NN

key_t2 double NN

Productjiame string NN

key_t3 double NN

Type string NN

key_t4 double NN

Brand string NN

key_t5 double NN

Adress string NN

_id

key_t1 Customer T5_of_T1 [{>] key_t5 Ad re 55 Date_order T2_of_T1 [{}] key_t2

Productname T3_of_T2 [{}] key_tB Type T4_of_T2 [{>] key_t4 Brand

objectld NN I

double NN

string NN

... 77. T5_of_71 NN

double NN

string NN

string NN

...T1.T2_of_T1 NN

double NN

string NN

... T1.T2_of_ T1. T3_of_T2 NN

double NN

string NN

... 77.T2_of_ 77. T4_of_T2 NN

double NN

String NN

Вариант 1

Вариант 2

Рис. 5. Две структуры баз данных MongoDB для тестирования

Таблица 2

Запросы после трансляции из формата MySQL в формат MongoDB

для 2 структур баз данных

№ Вариант 1 Вариант 2

Q1 db.Tl. aggregate( [ {'Sproj ect': {'Customer': 'SCustomer', 'Product_name': 'SProduct_name', 'Date_order': 'SDate_order', 'Type': 'SType'}}, {'Sgroup': {'_id': {'Customer': 'SCustomer', 'Product_name': 'SProd-uct name', 'Date order': 'SDate order', 'Type': 'SType'}}}]) db.T1.aggregate([{'Sunwind': 'ST5 of Tl'}, {'Sunwind': 'ST2 of Tl'}, {'Sunwind': 'ST2 of T1.T3 of T2'}, {'Sun-wind': 'ST2_of_T1.T4_of_T2'}, {'Sproject': {'Customer': 'SCustomer', 'T2_of_T 1 .Product_name': 'ST2 of Tl.Product name', 'Date order': 'SDate order', 'T2 of T1.T3 of T2.Type': 'ST2_of_T1.T3_of_T2.Type'}}, {'Sgroup': {'_id': {'Customer': 'SCustomer', 'Product_name': 'ST2 of Tl.Product name', 'Date order': 'SDate order', 'Type': 'ST2_of_T1.T3_of_T2.Type'}}}])

Q2 db.Tl. aggregate( [ {'Smatch': {'Brand': 'Emnipedor Group'}}, {'Sproj ect': {'Customer': 'SCustomer', 'Date_order': 'SDate_order', 'Product name': 'SProduct name', 'Brand': 'SBrand'}}, {'Sgroup': {'_id': {'Customer': 'SCustomer', 'Date_order': 'SDate_order', 'Product_name': 'SProd-uct_name', 'Brand': 'SBrand'}}}]) db.T1.aggregate([{'Sunwind': 'ST5 of Tl'}, {'Sunwind': 'ST2 of Tl'}, {'Sunwind': 'ST2 of T1.T3 of T2'}, {'Sunwind': 'ST2 of T1.T4 of T2'}, {'Smatch': {'T2_of_T1.T4_of_T2.Brand': 'Emnipedor Group'}}, {'Sproject': {'Customer': 'SCustomer', 'Date_order': 'SDate order', 'T2 of Tl.Product name': 'ST2 of Tl.Product name', 'T2 of T1.T4 of T2.Brand': 'ST2_of_T1.T4_of_T2.Brand'}}, {'Sgroup': {'_id': {'Customer': 'SCustomer', 'Date_order': 'SDate_order', 'Product name': 'ST2 of Tl.Product name', 'Brand': 'ST2_of_T 1.T4_of_T2.Brand'}}}])

Q3 db.Tl. aggregate( [ {'Smatch': {'Product_name': 'Gropickazz', 'Type': 'Type 9'}}, {'Sproject': {'Product_name': 'SProduct_name', 'Brand': 'SBrand', 'Type': 'SType'}}, {'Sgroup': {'_id': {'Product_name': 'SProduct name', 'Brand': 'SBrand', 'Type': 'SType'}}}]) db.T1.aggregate([{'Sunwind': 'ST5 of Tl'}, {'Sunwind': 'ST2 of Tl'}, {'Sunwind': 'ST2 of T1.T3 of T2'}, {'Sunwind': ' S T 2_of_T 1.T4_of_T2'}, {'Smatch': {'T2 of Tl.Product name': 'Gropickazz', 'T2_of_T1.T3_of_T2.Type': 'Type 9'}}, {'Sproject': {'T2 of Tl.Product name': 'ST2 of Tl.Product name', 'T2 of T1.T4 of T2.Brand': 'ST2 of T1.T4 of T2.Brand', 'T2 of T1.T3 of T2.Type': 'ST2_of_T1.T3_of_T2.Type'}}, {'Sgroup': {'_id': {'Product name': 'ST2 of Tl.Product name', 'Brand': 'ST2 of T1.T4 of T2.Brand', 'Type': 'ST2_of_T1.T3_of_T2.Type'}}}])

На рис. 6 приведен пример работы программы для запроса 03 для второго варианта структуры базы данных Моп§оВБ:

■ 3 MainWindow

Source database Input query

select Product_name, Brand, Type Irom Q. 13.14 where t2.keyJ2 = I3.key_t2 and 12.key_t2 = I4.key_t2 and Product_name = 'Gropickazz' and Type = 'Type 91

1 2 1 Gropickazz Adtinanax 3 Type 9

2 Gropickazz Supiropicator Inc Type 9

3 Gropickazz Lomjubor... Type 9

4 Gropickazz Winvenicator... Type 9

5 Gropickazz Lompickplor Type 9

Target. Database

Output query

db.Tl.aggregatetK'îmwrnJ1: '£T5_of_TI}> {'iunwincf: i.TZ_of_Tl^, {'Südwind': '$T2_or_Tl.T3_of_T2'},йипмпгГ: $T2_of_TI.T4_of_T2'}r {'fratch1 : iT2_of_Tl.Pro(iud_namer: 'Gropickazz1,12jf_Tl.T3_of_T2.Type1: 'Type 9'}}, {'Jprojecf : {TZ_of_Tl.Product_name': '$T2_of_T 1.Pr«tnct_name'r T2_of_Tl.T4_of_T2Brantf: 'tT2_of_Tl.T4_of_T2.Bran(fr TZ_of_Tl.T3_of_T2.Type1: 'tT2_of_Tl.T3_of_T2.Type')}, {'tjroup': fjf: {'Productjiame': 'ÎTZjOl.Product name', 'Brand1: '$T2_of_Ti.T4_of_T2.BraMÎ'l Type1: '$T2_of_Tl.T3_of_T2TypeTO])

Show

{'Jd : {'Productjiame' 'Gropickazz', ' rand' 'Winvenicator worldwide Corp.', Type': Type 9'}}

{'Jd : {'Productjiame' 'Gropickazz', ' rand' 'Lompickplor ', Type': Type 9'}}

{'Jd : {'Productjiame' 'Gropickazz', ' rand' lomjubor International ', Type': Type 9'}}

{'Jd : {'Productjiame' 'Gropickazz', ' rand' 'Adtinanax ', Type': Type9'}}

{'Jd : {'Productjiame' 'Gropickazz', ' rand' 'Supfropicator Inc', Type': Type 9'}}

Рис. 6. Результаты выполнения запроса для второго варианта структуры базы

данных Мо^оББ

Из рис.6 видно, что результаты выполнения запроса после его трансляции в MongoDB точно совпадают с результатами выполнения исходного запроса MySQL.

Заключение. Представленный в данной статье подход для трансляции запросов из MySQL в MongoDB с учетом структуры базы данных выполняет трансляцию запросов для любой структуры базы данных на MongoDB. Но в настоящее время подход ограничен для SQL-запросов. В настоящее время проводятся исследования по доработке данного подхода для более сложных SQL-запросов, таких как запросов с подзапросами или запросов с операциями объединения «Union». Еще одной задачей, решаемой нами, в настоящее время является задача оптимизации запросов после трансляции с использованием индексов.

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

1. Costa A.V., Vilain P., Mello R.S., A Layer for the Mapping Management of SQL DML Instructions to the Key-Value NoSQL Database Voldemort // XII Brazilian Symposium on Information Systems on Brazilian Symposium on Information Systems: Information Systems in the Cloud Computing Era. 2016. V.1 (SBSI 2016). P. 224-231.

2. Rith J., Lehmayr P., Meyer-Wegener K., Speaking in tongues: SQL access to NoSQL systems // Proceedings of the 29th Annual ACM Symposium on Applied Compu-ting.2014. P.855-857.

3. Calil A., Mello R., SimpleSQL: a relational layer for SimpleDB // Advances in Databases and Information Systems.2012. V. 7503. P. 99-110.

4. Andreas R., Stefanie S., Tegawendé F. B., Data model evolution using object-NoSQL mappers: folklore or state-of-the-art? // IEEE/ACM 2nd International Workshop on Big Data Software Engineering (BIGDSE). 2016. P. 33-36.

5. Buneman P., Fernandez M., Suciu D., UnQL: A Query Language and Algebra for Semistructured Data Based on Structural Recursion // The VLDB Journal. 2000.V.9. P.76-110.

6. Kornacker M., Behm A., Bittorf V., Bobrovytsky T., Ching C., Choi A., Erickson J., Grund M., et al: Impala: a modern, open-source SQL engine for Hadoop. // CIDR (2015).

7. Harkins S., Reid M., SQL Grammar // SQL: Access to SQL Server.2000. P.69-82.

Ха Ван Муон, аспирант, muon. haamail. ru, Россия, Санкт-Петербург, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В.И. Ульянова (Ленина)

AUTOMATIC TRANSLATION OF QUERYFROMMYSQL TO MONGODB TAKING INTO ACCOUNT STRUCTURES OF THE DABATASES

Ha Van Muon

This article proposes an approach to automatic translation queries from MySQL to MongoDB , taking into account the database structure, which consists of four stages. The input data are metadata in the MYSQL format, the MYSQL database structure, the MYSQL query code and metadata in the MongoDB database structure. Result of translation is the query code in MongoDB format. This approach is tested on various queries and databases which have different structures. The article provides the test results and evaluation of the effectiveness of this approach.

Key words: MySQL, MongoDB, query processing, translation queries, syntax analysis.

Ha Van Muon, postgraduate, muon. haamail. ru, Russia, Saint-Petersburg, Saint Petersburg Electrotechnical University «LETI»