Какие бывают базы данных

По пути к описи КВЕРИ притормаживает у тёмной секции хранилища. За стеклом — реестр архивов старой Земли, не переживших Большой обрыв: кэш-узлы погасли первыми, документные хранилища дошли рваными фрагментами, аналитические кластеры молчат целыми секторами. А реляционный снимок «Котомаркета» уцелел целиком — со всеми связями.

Не только реляционные

Для «Котомаркета» нам особенно удобны реляционные БД: покупатели, заказы и товары естественно ложатся в таблицы со связями. Именно им посвящён курс. Но в индустрии — что в 2024-м, что сейчас — встречаются и другие подходы:

• ключ-значение (Redis) — очень быстрый формат «ключ → значение», когда нужно мгновенно достать простую запись;
• документоориентированные (MongoDB) — хранят гибкие JSON-документы, где структура может отличаться от записи к записи;
• колоночные (ClickHouse) — сильны в аналитике, когда нужно быстро считать показатели по огромным объёмам данных.

Большинство популярных СУБД для продуктовой разработки остаются реляционными: PostgreSQL, MySQL, Oracle, MS SQL. Освоишь SQL здесь — сможешь уверенно читать данные в очень разных компаниях.

КВЕРИ: Каждому архиву — своя работа: одним скорость, другим гибкость, третьим аналитика. Нам с тобой повезло: нам достался тот, в котором всё связано со всем.

Реестр семейств: разбор по полочкам

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

Реляционные БД: строгая схема и связи

Способ хранения: строки в таблицах с заранее объявленной схемой — у каждого столбца есть тип, между таблицами действуют связи по ключам, и СУБД сама охраняет целостность: заказ от несуществующего покупателя записать не выйдет. Изменения исполняются транзакциями с гарантиями ACID — «заказ + списание остатка» либо записываются вместе, либо не записываются вовсе.

• Сильные стороны: выразительный SQL (фильтры, соединения таблиц, агрегаты), целостность на уровне базы, транзакции.
• Слабые: схему нужно продумывать заранее и мигрировать при изменениях; горизонтальное масштабирование на много серверов даётся труднее, чем NoSQL-семействам.
• Продукты: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Когда брать: пользователи, заказы, деньги, склад — везде, где данные связаны и ошибка записи недопустима. Для нового продукта это выбор по умолчанию.

Базы ключ-значение: словарь на максимальной скорости

Способ хранения: один гигантский словарь «ключ → значение», чаще всего в оперативной памяти. Ни таблиц, ни связей: положил по ключу — забрал по ключу за доли миллисекунды.

-- Это не SQL, это команды Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Сильные стороны: скорость, простота, лёгкое масштабирование.
• Слабые: запросы только по точному ключу — вопрос «найди все сессии покупателей из Москвы» этому формату не задать; внутренность значения для базы непрозрачна.
• Продукты: Redis, Memcached, Amazon DynamoDB.
• Когда брать: кэш, сессии, счётчики, очереди, рейтинги — горячие данные рядом с основной базой, а не вместо неё.

Документные БД: гибкий JSON

Способ хранения: записи — JSON-документы, сгруппированные в коллекции. Схема не объявляется заранее: у смарт-часов есть поле «время работы батареи», у худи — «размерная сетка», и оба документа спокойно лежат в одной коллекции. Вложенные структуры хранятся прямо внутри документа, без отдельных таблиц.

• Сильные стороны: гибкая структура, документ читается целиком одним обращением, удобно для каталогов с разнородными атрибутами и быстрых прототипов.
• Слабые: связи между документами — забота приложения, полноценных JOIN почти нет; без дисциплины коллекция превращается в зоопарк несовместимых форматов.
• Продукты: MongoDB, Couchbase, Firestore.
• Когда брать: контент, каталоги с сильно различающимися полями, профили и настройки.

Граница семейств, кстати, размыта: PostgreSQL умеет хранить документы в столбце типа jsonb и строить по ним индексы — часто это закрывает «документную» потребность без второй базы:

-- Пример вне нашего снимка: attrs — столбец типа jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Колоночные БД: аналитика по миллиардам строк

Способ хранения: значения лежат не построчно, а по столбцам: все цены — рядом, все даты — рядом. Запрос «средний чек по месяцам» читает с диска только два столбца вместо всей таблицы, а однотипные значения отлично сжимаются. Отсюда скорость на агрегатах.

-- Любимый жанр колоночной базы (диалект ClickHouse: toYYYYMM — его функция)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Сильные стороны: агрегаты и сканирование миллиардов строк, сильное сжатие.
• Слабые: точечные обновления и удаления дороги; прочитать одну строку целиком — медленнее, чем в строчной базе; транзакционная нагрузка — для такой нагрузки они не предназначены.
• Продукты: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Когда брать: аналитика, отчёты, события, логи, метрики — обычно рядом с «боевой» реляционной базой.

Здесь же пара терминов, которые любят на собеседованиях: OLTP (online transaction processing — много коротких операций записи и чтения, мир PostgreSQL) и OLAP (online analytical processing — тяжёлые аналитические чтения по всей истории, мир ClickHouse). Продукт пишет в OLTP-базу, аналитика читает OLAP-копию.

И последнее семейство — графовые БД

Когда связи важнее самих записей — «друзья друзей», маршруты доставки, цепочки рекомендаций — берут графовые БД (Neo4j, Memgraph). Данные в них — узлы (это записи) и рёбра (это связи между записями); обход связей любой глубины — родная операция. В реляционной базе такой обход — лестница из соединений таблиц, которая с глубиной тяжелеет.

Мини-гайд: как выбрать базу под проект

1. Начни с вопросов, а не с данных. Какие запросы будет задавать продукт: точечные «по ключу», связные «кто что купил», аналитические «сколько за месяц»?
2. По умолчанию — реляционная. Связанные данные плюс цена ошибки (заказы, оплаты, остатки) — это PostgreSQL. Самый безопасный старт почти для любого продукта.
3. Специализированные базы — под конкретную задачу, а не «про запас». Жмут горячие чтения — добавь кэш на Redis. Выросла аналитика — реплицируй события в ClickHouse. Дикая вариативность полей — сперва jsonb в PostgreSQL, и лишь когда его не хватит — документная база.
4. Считай цену второй базы. Каждая новая СУБД — это синхронизация данных, бэкапы, мониторинг и ещё одна технология, которую команде поддерживать.