CC BY
4COMPUTER SCIENCE
АРХ1ТЕКТУРА МЕХАН1ЗМ1В ОБРОБКИ ДАНИХ ТА СИНХРОН1ЗАЦ1Я МОДУЛ1В У ВИСОКОНАВАНТАЖЕНИХ СИСТЕМАХ SMART CITY
Войчик С. С., бакалавр Тимошин Ю. А., к. т. н, доцент
Украгна, м. Кигв, Нац^ональний техшчний университет Украгни «Кигвський полтехтчний институт 1мен1I. Сторського», ФЮТ, кафедра Техмчног Кибернетики
DOI: https://doi.org/ 10.31435/rsglobal_ws/31102018/6173
ABSTRACT
The study is aimed to determine the main problem during developing and maintaining services of high load Smart City system and propose solutions for achieving eventual consistency between services. The main problem with the services and databases is a significant amount of requests which is produced by millions of devices and how to process and store it quite fast. Low latency, high scalability and failure resistance should be the main characteristic of the system. That is why choosing a database, a right strategy for database replicas, service synchronization and its monitoring are basic problems which must be solved first. There are several architecture and database types which are already used in more simple systems. Key aspect needs to be resolved - how to synchronize data between multiple services in Smart City system. To solve the problems we need to redevelop already existing technology which is used for more simple problems, join them and apply on new solution.
Citation: Войчик С. С., Тимошин Ю. А. (2018) Arkhitektura Mekhanizmiv Obrobky Danykh ta Synkhronizatsiia Moduliv u Vysokonavantazhenykh Systemakh Smart City. World Science. 10(38), Vol.1. doi: 10.31435/rsglobal_ws/31102018/6173
Copyright: © 2018 Войчик С. С., Тимошин Ю. А. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) or licensor are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
Вступ: У системах Smart City, навиъ для невеликих мют, завжди буде оброблятись та збертатись велика кшьюсть даних. Основним джерелом даних е pyxoMi об'екти: люди, приватш автомобш, громадський транспорт. Кpiм того, дат агрегуються та обробляються piзними сервюами вбудованими в систему, як в свою чергу також спшкуються мiж собою використовуючи визначеш протоколи. За таких умов з'являються проблеми синхрошзаци, збереження даних, забезпечення вщмовостшкосп та прийнятного часу вщповщь В щеал^ робота з стльними даними у розподшенш системi повинна виглядати так само, як у нерозподшенш системi - це означае, що все повинно виглядати так, шби е лише одна котя даних, що читаеться та записуеться - без всяких реплш. Без сумшву сильна консистентшсть (strong consistency) [2] е найкращою моделлю узгодженост з точки зору програмю^в додатюв. На жаль, це не завжди можливо pеалiзyвати в житп. Мережа повинна бути роздшена, адже, якщо з якоюь причини неможливе спшкування всix вyзлiв, то у кopистyвачiв можуть бути
ARTICLE INFO
Received: 10 August 2018 Accepted: 21 October 2018 Published: 31 October 2018
KEYWORDS
IoT,
replication, architecture, synchronization, databases, smart city,
highly loaded systems.
проблеми при використанш, оскшьки вони будуть отримувати або застарш данi, або не зможуть працювати з системою.
Результати дослщжень: Кожне оновлення вимагае вщправлень в обидва боки - до певно1 центрального вузлу або до певного кворуму серверiв, а якщо комунiкацiя вiдбуваеться повiльно (наприклад, через географiчну вiдстань мiж клiентом i сервером або мiж реплiками) то постраждае продуктивнiсть i час вщповщ мiж клiентами системи. Всi компоненти розумного мюта мають бути штегроваш за допомогою сервiс-орiентованоl архiтектури. Мюька архiтектура е, по сутi, масштабною розподшеною системою, яка по сво!й сутi е складною i децентралiзованою. Рiзнi платформи, неоднорiдна обстановка та рiзноманiтнiсть мереж датчикiв призведуть до проблем сумсносп. Сервiсно-орiентована архiтектура з li вiдкритими стандартами, такими як JSON, GraphQL, XML забезпечуе не тшьки взаемодiю мiж рiзними платформами, але також тдтримуе модульний дизайн, повторне використання програмного забезпечення, взаемодда та iнтеграцiю додаткiв. Таку архтектуру легко впроваджувати, а деякi частини системи можна зробити на основi Event-Driven архiтектури [3]. Для оброблення подш та iнiцiалiзацil веб-сервiсiв (для безпосередньо! роботи) можуть бути використаш три стратеги: проста, потокова i комплексна.
- Просте оброблення полягае в iнiцiалiзацil веб-сервiсiв по мiрi реестрацп вiдповiдних подiй. Основна перевага тако! системи — це робота в режимi реального часу. Мiнус очевидний - не враховуеться фактор прюритету.
- Потокове оброблення враховуе iснуючi залежностi веб-сервiсiв i об'еднуе кiлька сервiсiв в один загальний потiк. Цей пiдхiд виправдовуе себе в системах з великими накладними витратами на пошук i отримання шформаци з баз даних.
- Комплексне оброблення - це так зване управлшня за вщхиленнями. Будь-яка подiя розцiнюеться як вихвд системи зi стану рiвноваги. Iнiцiалiзацiя веб-сервiсiв переслiдуе едину мету - повернути систему в стан рiвноваги (задовольняючи потреби клiентiв системи).
Для забезпечення нормальное' роботи систем е сенс вважати помилки при робот систем не як рщюсш випадки, а як передбачувану частину нормальное' роботи. Наприклад, зв'язок мiж мобшьним клiентом i сервером може вийти з ладу, оскшьки користувач про1жджае через тунель або здшснюе посадку на лгак. Найчастiше, помилки роблять програму непридатною для використання, iнодi не вказуючи на те, що пiшло не так, i коли ми можемо очшувати нормального функцюнування для вiдновлення. У гiршому випадку, збо1 можуть призвести до постшно1 невалiдного стану даних або !х повно! втрати.
Крiм того, один з сервгав може оновлюватись в момент вщправки запиту i через це бути певний час недоступним. В такому випадку можна приховати проблему вщ користувача, проганяючи вс важливi повiдомлення вiд клiентiв через чергу.
Ц аспекти дуже важливi при розглядi того, як краще провести компромiс мiж стабiльнiстю та доступнютю. Проте на абстрактному рiвнi всi цi системи базуються на принципах узгодженостк спiльнi данi оновлюються в рiзних реплiках, оновлення передаються асинхронно, а конфлшти постiйно виршуються.
Для реалiзацil асинхронних протоколiв використовуються рiзнi технологи MessageBrokers (МВ) [1]. Метою брокерiв повiдомлень е отримання вхщних повiдомлень вiд додатюв та виконання дiй на них в майбутньому. У типовш архiтектурi повiдомлення, якi вважаються бiзнес-критичними, надсилаються в MB, де зберiгаються повщомлення та розсилаються вiдповiдним слухачам на надшний гарантований спосiб. Якщо в компонент вiдбуваеться помилка обробки, перш шж обробляти повiдомлення, MB буде вимагати повщомлення шсля того, як компонент буде перезавантажено, або передасть шшому аналопчному серверу, який зможе впоратися з ним.
Для обробки подш, що можуть вщправлятись на смарт пристро1 можна застосовувати процесор подш. Цей компонент дозволяе розтзнавати послщовносп повiдомлень, якi можуть сигналiзувати тип под^'. Один тип послщовносп може представляти загрозу безпецi. 1нша послiдовнiсть може означати можливiсть щось продати комусь. Послiдовнiсть повiдомлень мае вщбуватися протягом певного перiоду часу. У свт IoT сервер CEP - (Complex Event Processing) може шукати послщовшсть повiдомлень, якi можуть вказувати на те, що хтось перемщуеться з юмнати в юмнату, щоб свiтло було включено або вимкнено, або навт бiльш складш розрахування. Двигун CEP може зробити пристро1 IoT розумними, визнаючи поведшку в деяких випадках i навт в пристроях.
Iсторичнi данi для IoT сервюв зростають швидко i часто досягають десяткiв петабайт. Популярним ршенням роботи з даними е збертання iсторичних даних на реплшах. У такому
pa3i, коли дат можуть збериатись у декшькох джерелах, n0Tpi6H0 використовувати map-reduce алгоритм. KpiM того, iсторичнi данi потрiбно iндексувати та використовувати шардiнг для досягнення прийнятно1 швидкостi запитiв. Якщо сервю буде використовувати хмарнi технологи, то важливу частину цих задач бере на себе постачальник послуг.
Для синхротзаци БД, якщо, наприклад, потрiбно побудувати навколо вже юнуючого сховища пошуковий iндекс, краще використовувати наступт технiки:
Використання невелико1 програми, яка буде вщслщковувати змiну даних в БД (update, delete) використовуючи певний стовбець (зазвичай Modified Date) та вщправляти ix для оновлення в шшу БД [2]. Такий спошб е пiдxодящим для невеликих систем, де дат оновлюються не так часто i в бшьшосп свош е статичними.
Реплiкацiя журналу (CDC - change data capturing): найшвидший спошб - бiльш-менш золотий стандарт у реплшаци даних. Вона включае в себе запит внутршньо! змiнноï журналу вашо! бази даних кожн кiлька секунд, копiювання змш у сховище даних та ik частому використанню. Всi змiни до вказаних вами таблиць i об'екпв завантажуються за замовчуванням, використовуючи журнал змш, тому тчого не втрачаеться. CDC - це не тшьки швидший, надiйнiший спосiб, вiн також впливае значно менше на продуктивнють бази даних пiд час запиту та допомагае уникати завантаження повторюваних подiй. Однак, це потребуе бшьше налаштувань i у випадку, якщо БД не тдтримуе його за замовчуванням, тодi доведеться самому використовувати допомiжне програмне забезпечення.
CDC - це найкращий спосiб для баз даних, яю постiйно оновлюються, вш повнiстю пiдтримуе видалення [2].
Так як вш процеси в системi потрiбно контролювати для розумiння працездатност та помилок програмного забезпечення, потрiбен монiторинг за бiзнес - активнютю сервiсiв. Цю роль можна покласти на сервю мониторингу BAM (business activity monitor).
Вш призначений для обробки великих потоюв повщомлень з рiзниx джерел, включаючи файли журналiв або джерела, яю, можливо, не орiентованi на повщомлення. Сервер BAM [1] може обчислювати ключовi бiзнесовi або операцiйнi показники на основi всix потоюв повщомлень. Вiн може обчислювати показники SLA (Service Level Agreement), середн й пiдсумковi значення, а також генерувати поди на основi значень, в дiапазон яких потрапляли цi показники. Ця функцюнальтсть може використовуватися для цiлей операцш або для бiзнес-показникiв [1].
Часто потоки потрапляють у велику вприну даних для подальшоï обробки та аналгтики. У середовищi IoT сервер BAM - це збирач даних для пристроïв IoT. Вiн передае дат в сховище даних, а також виконуе обчислення та видае нову iнформацiю та поди. Тут ви можете вказати, що ви хочете сумувати всю електроенерпю, яка використовуеться у домi або в бiзнесi, або в середньому за енерпю протягом години. BAM може публшувати цi розрахунки перiодично як поди.
Висновки. 1снуе деюлька титв архггектури та баз даних, яю вже використовуються в бiльш простих системах, тому для побудови модутв Smart City з потрiбними вимогами, доцiльно реконструювати вже iснуючi технологи та об'еднати для застосування у модулях Smart City.
Основними вимогами до модулiв та систем збериання даних у високонавантажених системах Smart City е:
- Консистентнють даних системи у чаш мiж собою (Eventual Consistency) та можливють до швидких вiдновлень у разi падiння,
- Пiдтримання сховищами реплшацш журналу та меxанiзмiв обробки повщомлень,
- Взаемодiя модулiв у œ^^i не напряму, а через посередника - наприклад, брокера повщомлень,
- Мошторинг активносп сервiсiв, якi використовуються, для розширення аналiтики бiзнес-процесiв.
Л1ТЕРАТУРА
1. Архитектура корпоративных программных приложений - Мартин Фаулер. - ст.63-84, СПБ., 2006
2. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 1st Edition by Martin Kleppmann 2017: p.151 -270
3. Event-Driven Architecture: How SOA Enables the Real-Time Enterprise 2009: p.63-111
