...
База даних системи реалізована на основі NoSQL (MongoDB, Elasticsearch) для швидкої обробки великих обсягів даних-рішень, таких як MongoDB (для зберігання основних об'єктів системи) та Elasticsearch (для повнотекстового пошуку та аналітики). Обрана архітектура дозволяє ефективно працювати з великими обсягами даних та забезпечує масштабованість, гнучкість і високу швидкодію.
3.1. Основні колекції БД
| Колекція | Опис | ||
|---|---|---|---|
procedure- (MongoDB | Обʼєкти procedure | ||
| registry-MongoDB | Обʼєкти registry | ||
| jobber-MongoDB | Обʼєкти jobber | ||
| notifications-MongoDB | Обʼєкти notifications | ||
| auction-MongoDB | Обʼєкти auction | ||
| swiftStorage | Обʼєкти файлів (document service) | ||
| ) | Зберігає об’єкти процедур, включаючи метадані, статуси, етапи проведення, тощо. | ||
registry (MongoDB) | Містить об’єкти реєстрів оренди, приватизації тощо | ||
jobber (MongoDB) | Об’єкти, пов’язані з фоновими задачами, чергами на обробку, планувальниками. | ||
notifications (MongoDB) | Події та повідомлення, які надсилаються користувачам або службам. | ||
auction (MongoDB) | Дані, що стосуються аукціонів: ставки, учасники, результати, лоти. | ||
swiftStorage | Служба зберігання документів – файлові об’єкти, пов’язані з процедурами. | ||
Elasticsearch | Індекси для реалізації повнотекстового пошуку по процедурах, учасниках, документах. | Elasticsearch | search |
3.2. Зв’язки між
...
Використовується реляційна модель, де основна сутність – аукціон, а всі інші сутності пов’язані через зовнішні ключі (foreign keys).
...
колекціями
У MongoDB зв’язки реалізовані через посилання (reference) між об’єктами шляхом зберігання ідентифікаторів:
Колекція
procedureмістить посилання на:пов’язані документи у
swiftStorage,події у
notifications,об’єкти аукціону з
auction.
Колекція
auctionмістить посилання на:учасників та ставки, які можуть зберігатись у піддокументах або окремих колекціях.
Колекція
jobberпов’язана з процедурами або іншими задачами, які вона обслуговує.Колекція
notificationsможе мати поляentity_idтаentity_type, які дозволяють пов’язати повідомлення з будь-яким об’єктом у системі (наприклад, процедурою чи аукціоном).
Зв’язки типово реалізуються через ідентифікатори (_id) без застосування вкладених JOIN-запитів, що забезпечує високу продуктивність.
3.3. Оптимізація бази даних
Індексація ключових полів
– підвищує швидкість вибірки даних:
Основні поля, за якими здійснюється пошук або фільтрація (наприклад,procedure.status,procedure.createdAt,auction.procedure_id,notifications.user_id), індексуються для прискорення виконання запитів.Розділення БД на модулі
– для масштабованості- Кешування запитів – через Redis або Memcached
- Логування операцій – для аудиту та безпеки
4. Висновок
(шардінг або окремі бази):
Для підвищення масштабованості й продуктивності, дані розділяються за логічними модулями (наприклад,registry,auction,notifications), а також можуть бути фізично рознесені між базами/серверами.Кешування запитів:
Часто використовувані дані (наприклад, списки категорій, типів процедур, попередні пошуки) кешуються у Redis або Memcached, що суттєво зменшує навантаження на основну БД.Логування операцій:
Усі запити, зміни та критичні події логуються у спеціальну колекцію або зовнішній лог-сервіс. Логи включають інформацію про користувача, час виконання, дію та результат, що забезпечує аудит та інформаційну безпеку.- Інформаційна модель системи структурована та охоплює всі бізнес-процеси
- API забезпечує інтеграцію з іншими державними та фінансовими системами База даних оптимізована для швидкої обробки запитів та забезпечення безпеки