Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

18.12.2022

Компроміси баз NoSQL, а особливо Firebase Firestore

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

Так, одного разу я мало не обрав DynamoDB, бо вона здатна працювати “в масштабі планети”. Але в DynamoDB можна ставити запити або по ключу, або ж по індексах, що побудовані заздалегідь. Ці індекси фіксують не тільки поле для запиту, але й порядок результатів. Тому DynamoDB добре застосувати, коли структура запитів обмежена та добре відома; дизайн бази, фактично, зводиться до дизайну запитів.

А зараз замислився над тим, як реалізувати вибірку витрат на накопичення у Firebase Firestore. Річ у тому, що структура бази така, що витрати належать до бюджетів, а цілі накопичення існують окремо від них та мають збирати витрати з усіх можливих бюджетів.

Як я вже писав, у Firestore база складається з колекцій, вкладених у документи. Так от, базові запити завжди працюють в межах однієї колекції — по цей час це нас повністю влаштовувало. Щоб зібрати документи з різних колекцій, є запити до групи колекцій. Але “група колекцій” будує глобальний індекс, та щоб кожний користувач мав доступ тільки до своїх витрат, маємо додати фільтр по ID користувача. Але для цього ID користувача має міститись в самому записі — бо права доступу до групи колекцій вміють працювати тільки зі змістом записів. Раніше в цьому не було жодного сенсу, бо всі витрати користувача вкладені в документ користувача, та авторизація відбувається за шляхом. А тепер, напевно, доведеться додати.

Альтернативний підхід: просто робити копії витрат на накопичення у загальну колекцію. Тоді не потрібно ускладнювати записи, але доведеться робити дублікати. На щастя, Firestore підтримує атомічні операції, так що принаймні база залишиться консистентною.

Поки не вирішив, що краще — група колекцій для (дуже!) приватних даних виглядає ризиковано, але ж з іншого боку, це вбудована функція бази, на відміну від клонування записів.