Вас вітає Інтернет конференція!
Вітаємо на нашому сайті
ПІДХОДИ CQRS ТА EVENT SOURCING ДЛЯ ПРИШВИДШЕННЯ РОБОТИ З ВЕЛИКИМИ ОБ’ЄМАМИ ДАНИХ
11.11.2021 22:18
[1. Інформаційні системи і технології]
Автор: Янчак А.В., студент, кафедра Комп’ютерних систем та мереж, Чернівецький Національний Університет ім. Ю. Федьковича; Яковлєва І.Д., к.т.н, доцент, кафедра Комп’ютерних систем та мереж, Чернівецький Національний Університет ім. Ю. Федьковича
Швидкість роботи в додатках з великим об’ємом даних є одним з основних критеріїв рентабельності проекту. Більшість десктопних та веб-додатків, в яких задіяна робота з базою даних, базуються на стандартному підході Create, Read, Update, Delete (CRUD) [1], який працює з даними як з об’єктами, не враховуючи ні їх попередній стан, ні будь-який інший стан у обраний момент часу. Також такий підхід виконує запис і зчитування в одній базі даних.
Комбінація підходів Command-Query Responsibility Segregation (CQRS) [2] та Event Sourcing [3] нівелює дані недоліки, а також підвищує швидкодію при роботі з великою кількістю записів. Суть цієї комбінації в тому, що вона дозволяє працювати з даними, як потоком подій, які записуються в базу послідовно, чітко вказуючи, що, коли і як було змінено, а також для читання та запису використовується дві бази, або база-дублікат, щоб уникнути будь-якого впливу на дані при операціях, які цього не вимагають.
CQRS – один з шаблонів, який допомагає розподілити відповідальність між записом та зчитуванням даних – операції, які відбуваються найчастіше. В його основі лежить просте поняття, що існує можливість використовувати різні моделі для оновлення та читання інформації. Однак це просте поняття веде до серйозних наслідків у проектуванні інформаційних систем. На даний час склалася така ситуація, що практично всі працюють з моделлю даних, як з CRUD сховищем. CQRS пропонує альтернативний підхід, але це стосується не тільки моделі даних. Використання CQRS сильно відбивається на архітектурі додатка.
Для прикладу взято дві моделі даних: одна для читання – модель запитів, одна для запису - модель команд. І, зазвичай, це означає, що існує ще й дві бази даних. У випадку використання CQRS у поєднанні з Event Sourcing база запису - це Event Store, щось на зразок логу всіх дій користувача, які важливі з точки зору бізнес-моделі та впливають на побудову бази зчитування. А база зчитування - це в загальному випадку денормалізоване сховище тих даних, які потрібні для відображення. Чому база зчитування денормалізована? Звичайно можна використовувати будь-яку структуру даних як модель запитів, але при використанні CQRS та Event Sourcing наднормалізація [4] бази процес зайвий, оскільки вона може бути повністю перебудована в будь-який час. І це великий плюс, особливо якщо не використовувати реляційні бази даних, а обирати NoSQL [5].
База запису є однією колекцією подій. Якщо на етапі створення проекту був обраний варіант з реляційною базою, то вищеописану поведінку можна імітувати за допомогою запису об’єктів у вигляді JSON [6].
Ідея Event Sourcing у тому, щоб записувати кожну подію, яка змінює стан програми, до бази даних. Таким чином, зберігається не стан сутностей, а всі події, які до них відносяться.
CRUD вимагає, щоб маніпулювати саме станом, який зберігається у базі і завжди доступний для перегляду.
При Event Sourcing теж оперують зі станом сутності. Але на відміну від звичайної моделі, цей стан не зберігається, а відтворюється щоразу при зверненні або зберігається у пам’яті.
Тобто при такому маніпулюванні даними відбувається наступне:
1.) Є сутність «Людина» із полями «Ім’я», «Прізвище» та «Вік».
2.) Створюється подія «Змінити ім’я» з значенням імені та часом зміни.
3.) Створюється подія «Змінити прізвище» з значенням прізвища та часом зміни.
4.) Збираються всі події в єдину сутність – «Стан». Тепер є можливість відтворити цей «Стан» в будь-який момент часу.
При додаванні в базу великої кількості подій, виникає проблема відтворення, коли їх десятки або сотні тисяч. На жаль, повтор стає дедалі складнішим, оскільки кількість подій, які потрібно повторити, збільшується. На перший погляд, використання джерела подій, призводить до того, що доступ до читання стає все повільнішим. Однак вихід із проблеми знайти нескладно.
Події завжди додаються лише в кінець існуючого списку, а наявні події ніколи не змінюються. Повторне відтворення, обчислене один раз, завжди буде давати той самий результат протягом певного моменту часу. Якщо спробувати провести аналогію з керуванням рахунком, то це очевидно: баланс рахунку в певний момент часу завжди однаковий, незалежно від того, чи були якісь депозити чи зняття після цього.
Можна скористатися цією ситуацією, зберігши поточний розрахований стан як, так званий, знімок [3]. Усю історію не завжди потрібно відтворювати на всьому шляху. Зазвичай, достатньо почати з останнього знімку і подивитися лише на події, які були збережені з того часу. Оскільки знімок лише доповнює історію, а не замінює її, старіші події все ще доступні, якщо вони потрібні для оцінки.
При даному підході зростає швидкість і гнучкість маніпуляції з даними, а їх збереження потребує менше виділеної пам’яті.
Література:
1. Bourabai Research – CRUD. [Електронний ресурс]. – Режим доступу: http://bourabai.kz/php/crud.htm
2. Martin Fowler – CQRS. [Електронний ресурс]/ Martin Fowler . – Режим доступу: https://martinfowler.com/bliki/CQRS.html
3. MSDN – Introduction to Event Sourcing. [Електронний ресурс]. – Режим доступу: https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj591559(v=pandp.10)?redirectedfrom=MSDN
4. Нормализация баз данных простыми словами. [Електронний ресурс]. – Режим доступу: https://info-comp.ru/database-normalization
5. MongoDB. What is NoSQL? [Електронний ресурс]. – Режим доступу: https://www.mongodb.com/nosql-explained
6. Введение в JSON. [Електронний ресурс]. – Режим доступу: https://www.json.org/json-ru.html
Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter
Інші наукові праці даної секції
-
АНДРОЇД-ДОДАТОК ДЛЯ ОПТИМІЗАЦІЇ ТУРИСТИЧНИХ УРБАНІСТИЧНИХ МАРШРУТІВ
13.11.2021 10:33 -
ДОСЛІДЖЕННЯ СУЧАСНИХ ПРОВАЙДЕРІВ ХМАРНИХ ТЕХНОЛОГІЙ ТА ПУБЛІКАЦІЯ ВЕБ-ДОДАТКУ У ХМАРІ
13.11.2021 10:24 -
СТРУКТУРНИЙ СИНТЕЗ БАЗИ ЗНАНЬ СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ НА ОСНОВІ НЕЙРОННОЇ МЕРЕЖІ
13.11.2021 10:03 -
АКТУАЛЬНІСТЬ ОБРОБКИ ТА АНАЛІЗУ ВЕЛИКИХ ДАНИХ
13.11.2021 09:59 -
СУЧАСНІ МЕТОДИ ТА ЗАСОБИ ЗАБЕЗПЕЧЕННЯМ БЕЗПЕКИ ІНФОРМАЦІЙНО-ТЕЛЕКОМУНІКАЦІЙНИХ МЕРЕЖ ТА БЕЗПЕКИ НАСЕЛЕННЯ
13.11.2021 09:54
Конференції
Конференції 2024
Конференції 2023
Конференції 2022
Конференції 2021
