Начальный ~15 мин чтения

SQL vs NoSQL: как выбрать хранилище

Урок 1 из 5 в курсе NoSQL базы данных

SQL vs NoSQL: как выбрать хранилище

SQL и NoSQL решают разные задачи; выбор зависит от модели данных, требований к согласованности и масштабированию

Почему это важно: неправильный выбор БД — дорогостоящая ошибка. MongoDB не замена PostgreSQL; каждый инструмент оптимален для своей задачи

Главная идея

реляционные БД: строгая схема, ACID-транзакции, связи; NoSQL: гибкость, горизонтальное масштабирование, специализация

Как это выглядит на практике

  1. Интернет-магазин с заказами, пользователями, товарами — чёткие связи, нужны JOIN, ACID. PostgreSQL.
  2. Лента событий с 100M записей в день, структура меняется — MongoDB или Cassandra.
  3. Кэш сессий, очереди задач, pub/sub — Redis.
  4. Граф связей пользователей в соцсети — Neo4j.
  5. Метрики и временные ряды сервера — InfluxDB или TimescaleDB.

Что происходит под капотом

  • ACID (Atomicity, Consistency, Isolation, Durability) — гарантии транзакций в реляционных БД.
  • BASE (Basically Available, Soft state, Eventually consistent) — модель многих NoSQL.
  • Sharding в NoSQL: данные горизонтально партиционируются по nodes; каждый node хранит часть.
  • Schema-on-read (NoSQL) vs schema-on-write (SQL): гибкость vs строгость.

Типичные ошибки и заблуждения

  • Ошибка: NoSQL масштабируется лучше SQL. PostgreSQL горизонтально масштабируется через Citus; правильно настроенный SQL выдерживает огромные нагрузки.
  • Ошибка: MongoDB проще начать, потом оптимизируем. Гибкая схема накапливает технический долг; схему нужно проектировать в любой БД.
  • Ошибка: нужно выбрать одну БД на весь проект. Polyglot persistence: PostgreSQL для транзакционных данных + Redis для кэша + Elasticsearch для поиска.
  • Ошибка: NoSQL без схемы означает 'можно хранить что угодно'. Неструктурированные данные ведут к хаосу; NoSQL требует такого же дизайна.

Ключевые выводы

  • Не существует 'лучшей' БД — есть правильная для задачи.
  • PostgreSQL подходит для большинства backend-проектов.
  • Используй специализированные хранилища там, где они лучше SQL.
  • Polyglot persistence — норма в production-системах.

Термины урока

ACID: гарантии транзакций (Атомарность, Согласованность, Изоляция, Долговечность).
BASE: модель слабой согласованности в распределённых системах.
Sharding: горизонтальное партиционирование данных по нескольким узлам.
Polyglot persistence: использование разных БД для разных типов данных.
Schema-on-read: схема применяется при чтении, а не записи (подход NoSQL).

Связь с работой backend-разработчика

Дефолт для нового проекта: PostgreSQL. Добавляй Redis (кэш/очереди) и Elasticsearch (полнотекстовый поиск) когда доходишь до реальных ограничений PostgreSQL в этих областях.

Мини-разбор реальной ситуации

Стартап начинает с MongoDB 'для гибкости'. Через год: коллекция users содержит документы с 15 разными схемами из-за миграций без контроля схемы. Запросы стали сложными из-за отсутствия JOIN. Миграция обратно на PostgreSQL занимает 3 месяца.

Что запомнить

  • PostgreSQL — разумный дефолт для начала.
  • Добавляй NoSQL при конкретной необходимости, не 'потому что хайп'.
  • Polyglot persistence: разные задачи — разные хранилища.

Итог

Выбор БД — архитектурное решение с долгосрочными последствиями. PostgreSQL покрывает 80% случаев; изучи его глубже прежде чем переходить на NoSQL.