Автоматична система генерації запитів до бази даних на основі асинхронних операційа



Стаття | Article    

Download

Automatic database query generation system based on asynchronous operations

Valery Tiurin

Igor Sikorsky Kyiv Polytechnic Institute

Kyiv,Ukraine

tiurinvalery@gmail.com

Olena Savchuk

Igor Sikorsky Kyiv Polytechnic Institute

Kyiv,Ukraine

savchuk_l1@ukr.net

Abstract. The work is devoted to the development of an automatic database query generation system based on asynchronous operations. An open source library in a non-relational database and an integrated application for its testing had been developed.

Keywords: automatic system, database, asynchronous operations.

Анотація. Робота присвячена розробці автоматичної системи генерації запитів до бази даних на основі асинхронних операцій. Розроблена бібліотека відкритих джерел в нереляційній базі даних та інтегрований застосунок для її тестування.

Ключові слова: автоматична система, база даних, асинхронні операції.

Вступ

Хмарне обчислення дає можливість широкомасштабного спільного доступу до послуг, що дозволяє користувачам отримувати доступ до технологічних сервісів без знання, досвіду та контролю над технологічною інфраструктурою, яка їх підтримує. Через зростання загальної кількості інформації, виникає необхідність у більш оптимальних системах, що можуть обробляти таку кількість інформації. Системи, що засновані на неблокуючих операціях – є основними в цій галузі. При розробці архітектурної схеми бібліотеки була обрана вірна архітекутра, яка базувалася на шаблонах проєктування для асинхронних систем. Були обрані раціональні технології, які відповідають основним критеріям – це безкоштовність, підтримуваність, сучасність, швидкодія, надійність. Завдяки слідуванню сучасним стандартам, набір технологій є звичним та зрозумілим фахівцям, які працюють з хмарними та Java орієнтованими застосунками [1-3]. Усі елементи, за виключенням DynamoDB [4], є безкоштовними, тож заміняючи хмарну DynamoDB локальною версією для розробників, було можливо створити проєкт без додаткових витрат на оплату інших компонентів та розмістити його як Open Source.
Завдяки використанню Spring Boot Framework, бібліотека є платформо-незалежною та легкою для розгортання завдяки вбудованому контейнеру [5-7]. Правильний вибір технологій дозволив створити потужну систему модульного, інтеграційного та навантажувального тестування, що дозволяє підтримувати належну якість застосунку.

І. ОПИС ПРОЦЕСУ ГЕНЕРАЦІЇ ЗАПИТІВ ЗАСТОСУНКУ

Процес генерації запитів складається з наступних етапів:

1) впровадження клієнтським застосунком об’єкта, що відповідальний за зв'язок з БД (створювати цей бін робота саме клієнта, бо це прямо впливає на безпеку PII даних); 2) пошук кандидатів (на основі власної анотації над класами бібліотека розуміє, для яких класів потрібно буде генерувати запити); 3) створення метадати для всіх знайдених кандидатів; 4) побудова запитів на основі створеної метадати. Вибір різних та оптимальних мов програмування для різних задач підвищує якість проєкту, а їх гармонічне поєднання (Scala є дуже схожею на Java) не створює додаткових складнощів для проєкту [8]. Орієнтованість на AWS застосунки, як на цільову аудиторію користувачів, є влучним вибором, бо AWS є найпопулярнішим хмарним провайдером сьогодення, що забезпечує широке коло потенційних користувачів. Наступним кроком клієнтський застосунок має додати у контекст DynamoDbAsyncClient бін, який має всередині налаштування параметрів підключення до бази даних, такі як accessKey, secretKey та region. Створити цей бін - задача саме клієнтського застосунку для того, щоб бібліотека не залежала від параметрів підключення і не потребувала знань приватних даних – це забезпечує гнучкість системи. Наступним кроком необхідно вказати значення пакету або пакетів, які програма має просканувати для пошуку кандидатів. Spring дозволяє динамічно змінювати значення полів біна за допомогою додаткових конфігураційних ресурсів. Для користувача робота з БД перетворюється на модель виклику методу й отримання результату, усі маніпуляції над створенням запиту бере на себе створена бібліотека. Серед прикладів інтерфейсів найбільш цікавий будівельник – це структурний шаблон, мета якого відокремити логіку створення об’єкту від логіки представлення об’єкта.

ІІ. РЕАЛІЗАЦІЯ БІБЛІОТЕКИ

Розроблювалася бібліотека для автоматичної генерації найчастіше вживаних запитів. Першим кроком була створена технічна діаграма, яка враховувала такі процеси: ініціалізація бібліотеки, її інтеграція з користувальницьким ПЗ, робочий режим, обробка помилок, можливість автоматизованого тестування. Наступним кроком була розроблена низькорівнева архітектура застосунку, яка базувалася на шаблонах проєктування, рекомендованих для Spring застосунків.
Були влучно перевикористані можливості Spring Framework для досягання цілей проєкту, а саме для роботи з завантажуваними класами, інверсією контроля тощо. Був розроблений простий інтерфейс взаємодії з бібліотекою для користувачів, який дає можливість розробникам одразу використовувати бібліотеку, а не вивчати її внутрішню будову, а також закладена можливість додавання нових інтерфейсів взаємодії для подальшого розширення функціоналу. Були створені функціональні тести бібліотеки, і автоматизована система збірки та розгортання проєкту.

ІІІ. ТЕСТОВИЙ ДОДАТОК БІБЛІОТЕКИ

Для того, щоб провести end-to-end навантажувальне тестування, був розроблений тестовий проєкт, в якому як залежність використовується розроблена бібліотека. За допомогою фреймворку Gatling й додаткової програми на Scala, створюються віртуальні користувачі, які імітують велике одночасне навантаження на систему. Після цього фреймворк будує графіки по основним отриманим результатам – це кількість оброблених запитів, середній час обробки одного запиту, розподіл навантаження по квантилям. З іншого боку, тестовий додаток слугує інструкцією по інтеграції та використанню бібліотеки, тобто користувачі бібліотеки мають впровадити бібліотеку так само, як в тестовому застосунку, й це гарантовано буде працювати. Розглянемо розподіли навантаження в синхронному (рис. 3.1) та асинхронному (рис. 3.2) клієнтах.

Рис. 3.1- Розподіл навантаження в синхронному клієнті

Важливим показником є те, що синхронний клієнт не виконав 1397 запитів з 36 000. Це означає, що за налаштований максимальний час (1200 мс) віртуальний користувач не зміг отримати ніякої відповіді від системи взагалі. Це дуже показово, що зі збільшенням складності системи, у користувачів синхронного клієнта не залишається механізмів покращення швидкодії – лише горизонтальне масштабування й відповідно більші економічні витрати, або збільшення часу очікування для користувачів, тобто погіршення якості системи.

Рис. 3.2 - Розподіл навантаження в асинхронному клієнті

Для асинхронного клієнту кількість невиконаних запитів є на третину меншою й, що саме головне, природа цих помилок інша, й вони такі, що їх можна вирішити шляхом оптимізації, а не масштабуванням чи збільшенням часу очікування. За результатами тестування було доведено неефективність використання асинхронного підходу для однієї операції та для дуже простих операцій, вищу ефективність та надійність асинхронності при роботі з декількома важкими операціями та необхідність використання правильних підходів при масштабуванні асинхронних додатків.

ВИСНОВКИ

Ця стаття представляє рішення, що задовольняє вимогам ринку з використанням сучасних технологій та орієнтацією на хмарні рішення через зростання їх популярності. Були обрані раціональні технології, які відповідають основним критериям: актуальності, безкоштовності, підтримуваності, швидкодії, надійності. За результатами тестування було доведено: вищу ефективність та надійність асинхронності при роботі з декількома важкими операціями; необхідність використання правильних підходів при масштабуванні асинхронних додатків. Було запропоноване рішення для розглянутих проблем: блокування по CPU; блокуючої передачі даних входу/виходу; витоку пам’яті.

ЛІТЕРАТУРА

  1. Effective Java 3rd edition / Best practices for the Java platform / Joshua Bloch / Addison Wesley Professional 2017.
  2. https://vertex\-academy.com/tutorials/ru/java\-8\-completablefuture/(дата звернення 01.03.2020).
  3. https://vertex\-academy.com/tutorials/ru/java\-8\-completablefuture\-part\-2/(дата звернення 01.03.2020).
  4. [https://medium.com/swlh/building\-dynamodb\-brick\-by\-brick\-237e0008b698/Building DynamoDB brick by brick](https://medium.com/swlh/building\-dynamodb\-brick\-by\-brick\-237e0008b698/Building DynamoDB brick by brick) [Електронний ресурс] (дата звернення 10.03.2020).
  5. https://docs.spring.io/spring\-data/jpa/docs/current/reference/html/#reference/ Spring Data JPA [Електронний ресурс] (дата звернення 01.03.2020).
  6. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWork.html (дата звернення 02.03.2020).
  7. https://dzone.com/articles/partitioning\-behavior\-of\-dynamodb(дата звернення 02.03.2020).
  8. https://www.scala\-lang.org/The Scala programing language [Електронний ресурс] (дата звернення 05.04.2020).
May 30, 2020