СУБД (система управления базами данных) — это программа-посредник между вашим приложением и данными на диске. Приложение не читает файлы базы напрямую: оно шлет запрос, а СУБД сама находит нужные записи, следит за целостностью, разграничивает доступ и гарантирует, что параллельные операции не испортят друг друга. Ниже разберем, чем СУБД отличается от базы данных и от языка SQL, какие бывают виды и как выбрать систему под конкретную задачу.
Содержание
СУБД, база данных и SQL — три разные вещи
Эти три термина постоянно путают, поэтому разведем их сразу одной цепочкой на примере интернет-магазина:
- База данных (БД) — это сами данные: таблицы с товарами, заказами, клиентами. Хранятся как файлы на сервере.
- СУБД — это программа, которая этими файлами управляет (PostgreSQL, MySQL и другие). Именно она выполняет запросы, а не БД сама по себе.
- SQL — это язык запросов, на котором вы формулируете «дай все заказы за сентябрь». СУБД читает этот текст и выполняет его.
Короче: БД — это данные, СУБД — программа над ними, SQL — язык общения с программой. Про сам язык SQL у нас отдельный разбор, здесь речь только про софт. Одну и ту же СУБД можно спрашивать разными способами, а NoSQL-системы вообще часто обходятся без классического SQL.
Что делает СУБД: пять базовых функций
Любая зрелая СУБД закрывает пять задач, которые иначе пришлось бы писать руками для каждого приложения.
- Хранение и доступ. СУБД раскладывает данные по файлам и строит индексы, чтобы находить нужную запись за миллисекунды, а не перебором всей таблицы.
- Транзакции и ACID. Группа операций выполняется как единое целое: либо все, либо ничего. ACID — это Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция), Durability (долговечность, сохранность данных). Пример: при переводе денег списание и зачисление либо проходят оба, либо откатываются оба — промежуточного состояния не будет.
- Целостность. Правила вроде «у заказа обязан быть существующий клиент» (внешние ключи), «email уникален» проверяет сама СУБД, а не каждое приложение по отдельности.
- Безопасность. Разграничение прав: кому можно читать, кому менять, кому только определенные таблицы. Плюс шифрование соединения и данных на диске.
- Многопользовательский доступ. Сотни клиентов пишут и читают одновременно, а СУБД через блокировки и изоляцию транзакций следит, чтобы они не переписали данные друг друга.
Оговорка про упрощение: полный набор ACID-гарантий дают в первую очередь реляционные СУБД. Часть NoSQL-систем сознательно ослабляет согласованность ради скорости и масштаба.
Два больших класса: реляционные и NoSQL
Все многообразие СУБД удобно делить на два лагеря по модели данных.
Реляционные (SQL) хранят данные в таблицах со строгой схемой: заранее заданные столбцы и типы, связи между таблицами по ключам. Это выбор по умолчанию, когда данные структурированы и важна строгая целостность (финансы, учет, заказы). Запросы — на языке SQL.
NoSQL — зонтичный термин для систем, которые отходят от таблично-реляционной модели ради гибкой схемы, горизонтального масштабирования или скорости. Внутри NoSQL — четыре основных подвида:
- Документные хранят записи как самодостаточные документы (обычно JSON/BSON) с произвольной вложенной структурой. Пример — MongoDB.
- Ключ-значение — простейшая модель «ключ -> значение», очень быстрая. Пример — Redis, часто как кеш.
- Колоночные (wide-column) хранят данные семействами столбцов и хорошо масштабируются на большой поток записи и чтение по ключу. Пример — Apache Cassandra (под капотом строчная, а не аналитическая система). Близкий, но отдельный класс — колоночно-ориентированные аналитические СУБД (ClickHouse): они физически держат каждый столбец подряд и быстро считают агрегаты по миллиардам строк.
- Графовые держат сущности как узлы, а связи между ними — как ребра, и быстро обходят эти связи. Пример — Neo4j. Уместны там, где важны отношения: соцсети, рекомендации, графы знаний.
Сравнение видов СУБД
| Вид | Модель данных | Схема | Сильная сторона | Когда брать | Примеры |
|---|---|---|---|---|---|
| Реляционная | Таблицы, связи по ключам | Жесткая | Целостность, транзакции ACID | Структурированные данные, финансы, учет | PostgreSQL, MySQL, MS SQL, Oracle |
| Документная | Документы JSON/BSON | Гибкая | Гибкая вложенная структура | Каталоги, профили, контент | MongoDB |
| Ключ-значение | Пара ключ -> значение | Минимальная | Скорость доступа | Кеш, сессии, счетчики | Redis |
| Колоночная (wide-column) | Семейства столбцов | Полугибкая | Масштаб на запись и чтение по ключу | Большой поток записи, временные ряды | Cassandra |
| Колоночно-аналитическая | Хранение по столбцам | Жесткая | Быстрые агрегаты по миллиардам строк | BigData, отчеты, метрики | ClickHouse |
| Графовая | Узлы и связи | Гибкая | Обход связей | Соцсети, рекомендации | Neo4j |
Популярные реляционные СУБД
Четыре системы покрывают большинство реляционных задач. Ниже — для чего каждая, без рекламных превосходных степеней.
PostgreSQL — свободная СУБД с открытым кодом, объектно-реляционная: помимо таблиц умеет типы JSON, массивы, полнотекстовый поиск, расширения. Актуальная мажорная ветка на сентябрь 2026 — PostgreSQL 18. Хороший выбор по умолчанию для нового проекта: бесплатна, зрелая, строго соблюдает стандарт SQL.
MySQL — принадлежит Oracle, одна из самых распространенных в вебе; Community-редакция с открытым кодом и бесплатна под GPL, есть и платные коммерческие редакции. Проще PostgreSQL в базовом использовании, исторически популярна в связке с PHP. Подходит для типовых сайтов и приложений со средней нагрузкой.
Microsoft SQL Server — коммерческая СУБД Microsoft, тесно интегрирована с экосистемой Windows и .NET. Есть бесплатная редакция Express с ограничениями и платные редакции. Уместна там, где стек уже завязан на продукты Microsoft.
Oracle Database — коммерческая СУБД корпоративного уровня, исторически сильна в крупных банках и госсекторе. Мощная и дорогая; лицензирование сложное. Для небольших проектов избыточна.
Пример SQL-запроса, одинакового по смыслу почти во всех реляционных СУБД:
-- Все заказы клиента с email за сентябрь 2026
SELECT o.id, o.total, o.created_at
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE c.email = 'ivan@example.com'
AND o.created_at >= '2026-09-01'
ORDER BY o.created_at DESC;Ожидаемый результат: строки заказов этого клиента за месяц, от новых к старым. СУБД сама решит, как эффективно соединить таблицы и через какой индекс искать по email — вам достаточно описать, что нужно, а не как это доставать.
Популярные NoSQL-системы
MongoDB — самая известная документная СУБД. Хранит записи как BSON-документы, схема гибкая: в одну коллекцию можно класть документы с разным набором полей. Удобна для каталогов, профилей, контента, где структура записи меняется. Запросы — на своем языке, не на SQL. Community-версия распространяется под лицензией SSPL — это не классическая OSI-лицензия с открытым кодом, что стоит учитывать при коммерческом использовании.
Тот же смысл, что и SQL-пример выше, на языке MongoDB выглядит иначе:
// Заказы клиента за сентябрь 2026, от новых к старым
db.orders.find({
email: "ivan@example.com",
created_at: { $gte: ISODate("2026-09-01") }
}).sort({ created_at: -1 })Redis — хранилище ключ-значение в оперативной памяти, отсюда очень высокая скорость. Классические сценарии: кеш, хранение сессий, счетчики, очереди. Данные умещаются в память, поэтому Redis обычно дополняет основную СУБД, а не заменяет ее. По лицензии Redis прошел полный круг: в 2024 году уходил на несвободные SSPL и RSALv2, а с версии Redis 8 (2025) снова доступен под открытой лицензией AGPLv3.
Cassandra и ClickHouse — под большие объемы: Cassandra это распределенное хранилище с упором на запись, ClickHouse — колоночная аналитическая СУБД для быстрых отчетов по миллиардам строк. Neo4j — графовая, когда основная ценность в связях между сущностями.
Как выбрать СУБД под задачу
Идти стоит от данных и нагрузки, а не от моды. Практический порядок:
- Данные структурированы, важны транзакции и целостность? (заказы, деньги, учет) — берите реляционную. По умолчанию PostgreSQL; MySQL если стек типовой веб; MS SQL при экосистеме Microsoft.
- Структура записей гибкая и часто меняется? (каталоги, профили) — документная, например MongoDB.
- Нужен сверхбыстрый доступ к простым данным? (кеш, сессии) — ключ-значение, например Redis, поверх основной СУБД.
- Тяжелая аналитика по огромным массивам? — колоночная, например ClickHouse.
- Главная ценность в связях между сущностями? (соцсети, рекомендации) — графовая, например Neo4j.
Если не получилось выбрать однозначно — это нормально: в реальных системах часто сочетают несколько СУБД (реляционная как основное хранилище + Redis для кеша). Начните с реляционной как безопасного варианта по умолчанию и добавляйте специализированную систему, только когда упретесь в конкретное ограничение (скорость, объем, характер связей).
Выводы
- СУБД — это программа-посредник между приложением и данными; сама база данных — это файлы, а SQL — язык запросов к СУБД. Три разные вещи.
- Базовые функции любой зрелой СУБД: хранение и быстрый доступ, транзакции с гарантиями ACID, контроль целостности, безопасность, многопользовательский доступ.
- Два больших класса — реляционные (строгая схема, ACID) и NoSQL (документные, ключ-значение, колоночные, графовые) с гибкостью и масштабом ценой части гарантий.
- Реляционная СУБД — безопасный выбор по умолчанию; NoSQL берут под конкретную задачу: гибкая схема, кеш, аналитика или связи.
- Выбор идет от характера данных и нагрузки, а крупные системы нередко совмещают несколько СУБД.
Где применяется / связь с практикой
СУБД — фундамент почти любого приложения: интернет-магазин, банковское ПО, соцсеть и мобильное приложение все опираются на базу данных под управлением СУБД. Инженеру данных, бэкенд-разработчику и аналитику важно не только знать синтаксис запросов, но и понимать, какую систему выбрать, как спроектировать схему и настроить производительность.
Освойте тему на практике
Разобраться в этом на практике — от реляционной модели и SQL до NoSQL и оптимизации запросов — помогает системное обучение на курсе СУБД в Otus. Посмотреть формат и уровень подачи можно бесплатно на открытых уроках Otus — там разбирают реальные кейсы работы с базами данных.
FAQ
Чем отличается СУБД от базы данных?
База данных — это сами данные (файлы с таблицами и записями), а СУБД — программа, которая ими управляет: выполняет запросы, следит за целостностью и доступом. БД без СУБД — просто набор файлов.
Обязательно ли знать SQL, чтобы работать с СУБД?
Для реляционных СУБД — да, SQL это основной язык запросов. NoSQL-системы часто используют свои языки и API, но SQL остается базовым навыком: многие NoSQL и аналитические системы добавляют SQL-подобные интерфейсы.
Можно ли использовать несколько СУБД в одном проекте?
Да, это распространенная практика: под каждый тип нагрузки берут свое специализированное хранилище. Например, реляционная СУБД как основное хранилище, Redis для кеша и ClickHouse для аналитики — каждая система под свою задачу.
