Представь, что ты проектируешь новый сервис и дошел до момента выбора базы данных. Первый вопрос, который приходит в голову: «А какую БД выбрать?» Может PostgreSQL? Или MongoDB? А может Valkey?
Понимаю, многие начинающие разработчики думают примерно так: «Буду использовать PostgreSQL для всего — это же универсальная реляционная база, и всё будет тип-топ». Но проектирование систем — это не «сейчас возьму одну БД для всего и не буду париться». Самая крутая система — та, которая использует правильный инструмент для каждой конкретной задачи.
В Big Tech, помимо самого решения задачи, важно, чтобы ты знал, как выбрать базу данных с оптимальными характеристиками. Не все данные одинаковы! Если подходить к каждому типу данных с одной и той же базой, это неизбежно создаст проблемы производительности и усложнит поддержку.
При выборе базы данных нужно идти от потребностей
- какую структуру имеют данные (они строго типизированы или это гибкий JSON?);
- какая ожидается нагрузка (больше читаем или больше пишем?);
- нужны ли сложные запросы (JOIN'ы нескольких таблиц) или достаточно простых операций по ключу;
- требуется ли строгая ACID-совместимость или можно обойтись Eventual Consistency (согласованностью в конечном счете).
Лучше сразу смириться — не бывает идеальной базы для всех задач. Где-то быстрее скорость доступа, но при этом меньше возможностей для сложных запросов. Где-то выше гибкость схемы, но зато больше потребление памяти. Вся архитектура состоит из компромиссов.
Реляционные базы данных (SQL)
Начнем с классики. Это старожилы мира данных, которые до сих пор остаются основой для 90% бизнес-приложений. Когда ты не знаешь, какую базу выбрать, и у тебя нет специфических сверхнагрузок — бери реляционку. Это самый безопасный вариант.
Примеры: PostgreSQL, MySQL, Oracle, SQL Server.
Ключевые особенности:
- Строгая схема: Данные хранятся в таблицах со строго заданными колонками и типами данных. Ты не сможешь записать строку в колонку для чисел.
- Связи: Таблицы связаны между собой внешними ключами (Foreign Keys), что защищает от появления «висячих» записей.
- Функциональность SQL: Поддержка сложных JOIN-запросов, подзапросов и аналитических оконных функций.
- ACID-транзакции: Гарантируют максимальную консистентность и надежность данных.
Сценарии использования
- Финансовые системы, биллинг и бухгалтерия (там, где потеря копейки или гонка данных недопустимы).
- Классические бизнес-системы (CRM, ERP), где преобладают OLTP-нагрузки и важна консистентность.
- Любые приложения с четко структурированной бизнес-логикой.
Но что делать, если структура наших данных постоянно меняется? Или нам нужно выдерживать миллион простых чтений в секунду для корзины интернет-магазина, и тяжелый SQL только замедляет работу? Здесь на сцену выходит семейство NoSQL, о котором мы поговорим в следующем уроке.