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

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

07.06.2024

Обережно, Query-Driven Design

Коли шукаєш потужну базу даних, можна натрапити на категорію баз, які обіцяють надзвичайну здатність до масштабування (це ж круто!) з майже незмінною швидкістю запиту (база мрій!) Прикладом будуть Cassandra, DynamoDB, ScyllaDB тощо.

Втім, при пропозиції необмеженого масштабування, варто придивитись, чи використовує база модель “Query-Driven Design / Modelling”, тобто “проєктування згідно з запитами”. За цим безневинним висловом криється небезпечна для проєкту особливість. А саме: Query-Driven Design значить, що всі запити до бази потрібно продумати наперед. Фактично це екстремальна форма оптимізації на читання: якщо коротко, то, дані в таких базах розташовуються так, щоб їх було швидко прочитати, навіть коли база сягає тисячі вузлів.

QDD-бази не є поганими! Вони дійсно надають неперевершену здатність до масштабування. Тому їх використовують компанії, яким потрібні дійсно глобальні обсяги даних. Наприклад, на DynamoDB побудована крамниця Amazon.

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

…Краще, як завжди, почати з PostgreSQL, а переходити на Cassandra коли проєкт того буде потребувати.