Типы баз данных: реляционные, NoSQL, колоночные и другие

Коротко

• База данных хранит данные, СУБД — программа, которая их записывает, ищет и отдаёт по запросу.
• Реляционные базы хранят таблицы со связями и понимают SQL. Нереляционные (NoSQL) хранят пары «ключ — значение», документы, графы или широкие строки и чаще имеют свой язык запросов.
• Базы для продукта (OLTP) обычно хранят данные строками, аналитические (OLAP) — столбцами.
• Типичный путь данных для аналитика: рабочая база продукта → реплика → хранилище данных → BI.
• SQL встречается далеко за пределами «классических» реляционных баз: в колоночных хранилищах, во встраиваемых движках, в SQL-похожих языках NoSQL-систем.

Что такое база данных и СУБД

База данных — это организованный набор данных, который хранится так, чтобы его можно было надёжно записывать, быстро находить и одновременно читать многим пользователям. Работой с ней управляет СУБД, система управления базами данных: она принимает запросы, следит за целостностью, пишет данные на диск и восстанавливает их после сбоя.

В разговоре эти слова смешивают: «наша база — PostgreSQL». Строго говоря, PostgreSQL — это СУБД, а база — конкретный набор таблиц внутри неё. Для выбора инструмента важнее другое: какую модель данных СУБД поддерживает и под какие запросы она оптимизирована. От этого и зависит тип базы.

Какие бывают базы данных: классификация

Классификаций много, но на практике базы различают по модели данных и по основной нагрузке. Таблица ниже покрывает то, что встречается в продуктовых компаниях. Одна система может попадать в несколько строк: PostgreSQL с расширениями умеет и временные ряды, и векторы, и JSON-документы.

Реляционные и нереляционные базы данных: в чём разница

Реляционная база раскладывает данные по таблицам и связывает их ключами. Пользователь 8 из учебной базы SQL-курса — это одна строка в users (канал organic, страна RU) и три строки в payments: три оплаты тарифа pro по 29 — 10 июня, 10 июля и 9 августа. Строки оплат ссылаются на пользователя через user_id, а собирает их вместе JOIN.

Документная база хранит того же пользователя одним документом, где оплаты вложены списком. Прочитать профиль целиком — одно обращение, без соединений. Посчитать выручку по месяцам по всем пользователям — наоборот, дольше: придётся пройти по каждому документу и достать вложенные значения.

Второе отличие — схема. В реляционной базе колонки и их типы объявлены заранее, и база не примет строку, которая им не соответствует. В документной базе поле может появиться, пропасть или поменять тип между документами. Схема при этом никуда не исчезает, она просто живёт в коде приложения. Аналитик узнаёт об этом, когда поле amount в половине документов оказывается строкой.

«NoSQL» — не одна технология, а зонтичное название всего нереляционного: ключ-значение, документов, графов, широких колонок. Расшифровывают его обычно как «not only SQL». Поэтому вопрос «SQL или NoSQL» точнее звучит так: какую модель данных и какие гарантии требует задача.

select jsonb_pretty(jsonb_build_object(
  'user_id', u.user_id,
  'channel', u.channel,
  'country', u.country,
  'payments', (
    select jsonb_agg(jsonb_build_object(
      'paid_at', p.paid_at, 'amount', p.amount, 'plan', p.plan
    ) order by p.paid_at)
    from payments as p
    where p.user_id = u.user_id
  )
))
from users as u
where u.user_id = 8;

-- {"user_id": 8, "channel": "organic", "country": "RU",
--  "payments": [{"paid_at": "2026-06-10", "amount": 29, "plan": "pro"},
--               {"paid_at": "2026-07-10", "amount": 29, "plan": "pro"},
--               {"paid_at": "2026-08-09", "amount": 29, "plan": "pro"}]}

OLTP и OLAP: две разные работы

Внутри реляционного мира тоже есть деление — по нагрузке. OLTP-база обслуживает продукт: тысячи коротких операций в секунду, каждая читает или меняет несколько строк. Оплата прошла — добавилась одна строка в payments. Здесь важны транзакции и гарантии ACID.

OLAP-система отвечает на вопросы о продукте: один запрос проходит по всем оплатам за квартал и складывает суммы по каналам. Запросов меньше, зато каждый тяжёлый. Подробное сравнение — в статье про OLAP и OLTP, а про слои хранилища — в материале о DWH, витринах и data lake.

Строковое и колоночное хранение

Строковая база кладёт на диск запись целиком: все поля первого пользователя, затем все поля второго. Так устроены PostgreSQL и MySQL, и для OLTP это удобно — чтобы найти или обновить одну запись, достаточно одного места на диске.

Колоночная база хранит каждую колонку отдельно: все user_id подряд, все channel подряд. Запросу «сколько пользователей в каждом канале» нужна одна колонка из пяти, и остальные четыре можно не читать. Однотипные значения рядом ещё и хорошо сжимаются. Обратная сторона — вставка и изменение одной строки обходятся дороже: запись разложена по нескольким местам.

Один SQL в двух разных движках

Модель хранения меняет скорость и цену запроса, но не его текст. Песочница SQL-курса работает на DuckDB — встраиваемой колоночной базе. Рабочие базы продуктов чаще живут в PostgreSQL. Запрос ниже выполняется в обоих без изменений и возвращает одинаковый результат.

Расхождения начинаются на функциях дат и строк, на приведении типов и на расширениях вроде QUALIFY, которые есть в одних движках и отсутствуют в других. Базовые select, join, group by переносятся между реляционными и колоночными системами почти без правок.

select
  u.channel,
  count(*) as payments,
  sum(p.amount) as revenue
from payments as p
join users as u on u.user_id = p.user_id
group by u.channel
order by revenue desc;

Где работает SQL

SQL давно вышел за пределы классических реляционных баз. ClickHouse, BigQuery и Snowflake — колоночные системы со своими диалектами SQL. DuckDB и SQLite — встраиваемые базы, которые тоже понимают SQL. TimescaleDB — расширение PostgreSQL, поэтому временные ряды в нём запрашивают обычным SQL, как и векторы в pgvector.

У нереляционных систем свои языки, иногда внешне похожие на SQL. В Cassandra это CQL: синтаксис напоминает SQL, но JOIN нет, а запрос удобно строить только от ключа партиции. У MongoDB свой язык запросов и конвейер агрегаций. Neo4j использует Cypher. Redis управляется командами вроде GET и SET. Elasticsearch принимает запросы в виде JSON, и у него есть SQL-интерфейс для простых выборок.

Для аналитика это значит простую вещь: SQL нужен почти всегда, но не везде он один и тот же. Прежде чем переносить запрос в новую систему, проверьте, как в её диалекте устроены даты, NULL и деление целых чисел.

Что обычно видит аналитик

В большинстве продуктовых компаний данные проходят похожий путь, даже если названия систем разные. Аналитик чаще всего работает на двух последних шагах, но полезно понимать все, чтобы знать, откуда берутся расхождения в цифрах.

Выбор, куда писать запрос, обычно сводится к компромиссу между свежестью и удобством. Реплика показывает данные почти в реальном времени, но таблицы там устроены под приложение: статусы закодированы числами, история изменений не хранится, а тяжёлый запрос может мешать другим читателям реплики. Хранилище отстаёт на время загрузки — от минут до суток, — зато в нём есть витрины с понятными колонками и история. Для ежедневных отчётов берите хранилище, для разбора «что случилось час назад» — реплику, предупредив разработчиков.

• Рабочая база продукта — PostgreSQL или MySQL. В неё пишет приложение; тяжёлые запросы сюда не отправляют, чтобы не замедлять оплаты и регистрации.
• Реплика — копия рабочей базы только для чтения. На ней можно смотреть свежие данные, но таблицы нормализованы и неудобны для отчётов.
• ETL или ELT — процессы, которые забирают данные из рабочих баз, логов и NoSQL-систем и загружают в хранилище. Здесь появляются задержки и первые расхождения.
• Хранилище данных (DWH) — ClickHouse, BigQuery, Snowflake, Greenplum или похожая система. Здесь лежат сырые слои и витрины, и здесь аналитик пишет большую часть запросов.
• BI — дашборды, которые читают витрины. Если цифра на дашборде расходится с продуктом, искать причину приходится по всей цепочке в обратном порядке.

Как выбрать тип базы данных

Аналитик редко выбирает базу для продукта, но часто — для своей задачи: где хранить витрину, куда сложить выгрузку, на чём собрать прототип отчёта. Выбор начинается не с названия системы, а с вопросов к задаче.

Есть и вопрос, которого нет в таблице: что уже работает в компании. Каждая новая база — это ещё один процесс загрузки, мониторинг, резервные копии и человек, который умеет её чинить. Витрина в уже существующем хранилище почти всегда дешевле, чем отдельная система под одну задачу, даже если та формально подходит лучше.

Частые заблуждения о типах баз данных

• «NoSQL быстрее SQL». Быстрее бывает конкретная система на конкретном запросе. Redis отдаёт значение по ключу мгновенно, но не посчитает выручку по каналам.
• «В NoSQL нет схемы». Схема есть всегда, вопрос только в том, кто её проверяет: база или код приложения.
• «Колоночная база — это NoSQL». ClickHouse и BigQuery работают с таблицами и SQL. От PostgreSQL они отличаются способом хранения и нагрузкой, а не моделью данных.
• «Хранилище заменит рабочую базу». Колоночные системы плохо переносят частые обновления отдельных строк и не рассчитаны на транзакции продукта.
• «Нормализация устарела». Для OLTP она по-прежнему защищает от противоречивых данных. Денормализация уместна в витринах, где данные только читают.

Что читать дальше

Попробуйте запрос из раздела про два движка в песочнице курса: там он выполняется на колоночном DuckDB. Затем замените sum(p.amount) на count(distinct p.user_id) и посмотрите, сколько платящих пользователей приходит из каждого канала.