ПІДХОДИ CQRS ТА EVENT SOURCING ДЛЯ ПРИШВИДШЕННЯ РОБОТИ З ВЕЛИКИМИ ОБ’ЄМАМИ ДАНИХ - Scientific conference
Main page
UA RU EN

Congratulation from Internet Conference!

Hello

Рік заснування видання - 2011

ПІДХОДИ CQRS ТА EVENT SOURCING ДЛЯ ПРИШВИДШЕННЯ РОБОТИ З ВЕЛИКИМИ ОБ’ЄМАМИ ДАНИХ

11.11.2021 22:18

[1. Information systems and technologies]

Author: Янчак А.В., студент, кафедра Комп’ютерних систем та мереж, Чернівецький Національний Університет ім. Ю. Федьковича; Яковлєва І.Д., к.т.н, доцент, кафедра Комп’ютерних систем та мереж, Чернівецький Національний Університет ім. Ю. Федьковича


Швидкість роботи в додатках з великим об’ємом даних є одним з основних критеріїв рентабельності проекту. Більшість десктопних та веб-додатків, в яких задіяна робота з базою даних, базуються на стандартному підході 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 Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
допомога Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter

Another articles in this section

Сonferences

Conference 2024

Conference 2023

Conference 2022

Conference 2021



Міжнародна інтернет-конференція з економіки, інформаційних систем і технологій, психології та педагогіки

Наукова спільнота - інтернет конференції

:: LEX-LINE :: Юридична лінія

Інформаційне суспільство: технологічні, економічні та технічні аспекти становлення