Системы управления базами данных (СУБД)
Разработчику
Аналитику
Тестировщику
Архитектору
Инженеру
Вступление
СУБД — движок, который принимает запросы, хранит данные на диске, ведёт журнал изменений, разруливает одновременный доступ и восстанавливается после сбоя. Приложение говорит с СУБД на SQL (или через ORM), а не копирует файлы с диска сервера.
В этом разделе дальше идут темы, без которых продакшен быстро ломается: роль БД в организации, правила Кодда, конкурентный доступ, восстановление после сбоя, администрирование в облаке.
Практика подключения из кода по популярным СУБД — SQLite, PostgreSQL, MySQL, Microsoft SQL Server.
Системы управления базами данных (СУБД)
Play ITЗагрузка интерактивного демо…
Play ITЗагрузка интерактивного демо…
Что такое СУБД?
Система управления базами данных (СУБД, англ. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, которые обеспечивают создание и использование баз данных — вставку, изменение, удаление и выборку данных, безопасность, надёжность хранения, целостность и средства администрирования.
По ГОСТ Р ИСО МЭК ТО 10032-2007 СУБД опирается на схему (описание структуры и ограничений) и управляет доступом к данным, описанным этой схемой.
Типичный набор задач СУБД:
- создание и сопровождение схемы БД;
- хранение данных на диске и в буферах;
- обработка запросов (SQL и API);
- контроль целостности и транзакций (ACID);
- безопасность, аудит, резервное копирование и восстановление после сбоев.
База данных — организованные данные и правила; СУБД — движок, который эти правила исполняет. Каталог с файлами на диске сам по себе транзакций, единого словаря метаданных и ссылочной целостности не даёт.
Основные функции (по классификации учебников)
| Функция | Смысл |
|---|---|
| Управление данными во внешней памяти | Файлы, страницы, индексы на диске |
| Управление данными в ОЗУ | Буферный пул, кэш страниц |
| Журнализация, резервное копирование, восстановление | WAL, контрольные точки — см. главу 8 |
| Поддержка языков БД | DDL (определение), DML (манипулирование), иногда DCL |
Файловое хранение и системы баз данных
До появления СУБД данные часто лежали в файлах — таблицы Excel, CSV, XML, JSON, собственные бинарные форматы. Приложение само открывает файл, читает и пишет байты. Система баз данных — это данные плюс СУБД: единая схема, язык запросов и правила целостности в одном месте.
| Критерий | Файлы на диске | СУБД |
|---|---|---|
| Параллельный доступ | Блокировки ОС, риск повреждения при одновременной записи | Транзакции, блокировки или MVCC на уровне строк |
| Целостность | На совести кода приложения | PRIMARY KEY, FOREIGN KEY, CHECK, домены |
| Запросы и отчёты | Парсинг файла в коде, полный перебор | Декларативный SQL, индексы, план выполнения |
| Метаданные | Часто "в голове" команды или в отдельном README | Системный каталог (information_schema, pg_catalog) |
| Безопасность | Права на файл в ОС | Роли, привилегии на таблицы и столбцы, аудит |
| Сбой и восстановление | Резервная копия файла вручную | WAL, контрольные точки, PITR — глава 8 |
| Когда уместно | Прототип, один пользователь, малый объём | Несколько приложений, рост данных, строгие правила |
Файл-серверная архитектура (Access, старые dBase) — промежуточный вариант — данные в общем файле, но логика целостности слабее, чем у серверной СУБД. Подробнее — раздел "Архитектура доступа к данным" ниже в этой статье.
После подключения клиент читает метаданные из каталога СУБД — список таблиц, столбцов, типов, ключей. В PostgreSQL — схемы information_schema и pg_catalog; в SQL Server — представления sys.*. Это тот же "словарь данных", о котором говорят в теории и на диаграмме выше.
Преимущества и ограничения СУБД
Зачем организации платят за СУБД:
- Независимость данных и приложений — схему можно менять (с осторожностью), не переписывая все клиенты сразу.
- Централизованный контроль — одна политика прав, резервного копирования и аудита.
- Одновременная работа — десятки и тысячи сессий без "каши в общем файле" (конкурентный доступ).
- Надёжность — журнал и восстановление после сбоя питания или падения процесса.
- Стандартный язык — SQL переносим между продуктами (с оговорками по диалектам).
Ограничения и цена внедрения:
- Сложность — установка, настройка, мониторинг, миграции схемы; нужны компетенции DBA или DevOps.
- Ресурсы — RAM под буферы, быстрые диски под журнал, лицензии у коммерческих вендоров.
- Накладные расходы — для десятка строк в учебном проекте SQLite-файл проще, чем кластер PostgreSQL; в проде объём и конкуренция оправдывают СУБД.
- Привязка к экосистеме — T-SQL, PL/SQL, расширения PostgreSQL; миграция между вендорами планируется заранее.
Выбор "файл или СУБД" — инженерное решение по объёму, числу пользователей и требованиям к целостности, а не догма "всегда только PostgreSQL".
Возможности СУБД
- Создание и поддержка структуры базы данных. СУБД позволяет создавать таблицы, поля, связи между ними, задавать ограничения и указывать типы данных столбцов (
INTEGER,VARCHAR,TIMESTAMPи др.) — множество допустимых значений и правил для поля. См. также типы в программах и типизация. Именно так обеспечивается структурированное хранение информации. - Хранение данных. СУБД отвечает за физическое хранение данных на диске, и разумеется для собственной качественной работы она организует хранение так, чтобы данные были доступны, даже если их много. Поэтому программные возможности СУБД включают оптимизацию работы с диском.
- Обработка запросов. Когда пишут запрос к базе данных, СУБД получает текстовую команду, которую парсит, оптимизирует и выполняет. СУБД отлично знает, где лежат данные, как к ним обратиться, благодаря чему от пользователя достаточно лишь сохранять правильность синтаксиса при составлении запросов.
- Контроль безопасности. СУБД обеспечивает защиту данных, проверяя, кто имеет право читать данные, менять их, а если нужно - даже шифровать. Всё, что выполняют с данными пользователи - фиксируется и записывается в журналах, поэтому всегда можно выяснить, кто менял или удалял данные.
- Резервное копирование и восстановление. Резервное копирование (бэкап) — создание копии данных отдельно от оригинала, чтобы при сбое оборудования, ошибке ПО, удалении (случайном или намеренном) вернуть данные в состояние на момент копии или, при PITR, на выбранный момент времени. Восстановление базы данных — функция СУБД, которая после аварии приводит хранилище к согласованному состоянию: через crash recovery (WAL при старте — глава 8), через restore из бэкапа (Резервное копирование и восстановление PostgreSQL, администрирование). Целевые показатели RPO и RTO связывают бизнес-требования с частотой бэкапов и временем простоя.
- Контроль целостности и согласованности. Целостность — соответствие данных схеме и объявленным ограничениям (ключи, домены, внешние ключи,
CHECK). Согласованность шире: значения не противоречат друг другу и правилам модели; при одновременной работе нескольких транзакций ACID и уровни изоляции не допускают "висячих" ссылок и противоречивых остатков. Подробнее — теория, конкурентный доступ.
Типы СУБД
СУБД различают по модели данных — способу хранения записей и связей. В обзорных схемах обычно выделяют четыре семейства (подробная таблица с задачами и примерами — в Знакомстве с базами данных):
| Семейство | Кратко | Примеры продуктов |
|---|---|---|
| Реляционные (SQL) | Таблицы, строгая схема, транзакции ACID, SQL | PostgreSQL, MySQL, SQL Server, SQLite |
| NoSQL | Гибкая схема, горизонтальный масштаб, специализация под нагрузку | MongoDB, Redis, Cassandra, DynamoDB |
| Иерархические | Дерево "один родитель — много детей" | IBM IMS, LDAP, реестр ОС |
| Объектно-ориентированные | Объекты с наследованием, как в ООП-коде | ObjectDB, db4o, GemStone |
Отдельно упоминают NewSQL — попытку совместить SQL и распределённое масштабирование (Google Spanner, CockroachDB). На практике в одной системе часто несколько СУБД — реляционная для учёта, Redis для кэша, MongoDB для каталога с разной структурой полей.
Компоненты СУБД
Современная СУБД обычно включает:
- Ядро — управление данными во внешней и оперативной памяти, журнализация изменений.
- Процессор языка БД — разбор SQL (или другого языка), построение плана, генерация внутреннего кода.
- Подсистема времени исполнения — выполнение операторов манипулирования, интерфейс с приложением.
- Сервисные утилиты — резервное копирование, мониторинг, миграции, иногда отдельные GUI (SSMS, pgAdmin).
На уровне реализации выделяют реляционное ядро (парсер, оптимизатор, исполнитель) и движок хранения (методы доступа, буферный пул, менеджеры транзакций, блокировок и восстановления, подсистема безопасности). Путь запроса — внутри СУБД и четыре подсистемы (Transport, Query Processor, Execution Engine, Storage Engine); физика страниц на диске — внутреннее устройство и теорию.
Процессы и память (клиент–сервер на примере PostgreSQL)
Серверные СУБД вроде PostgreSQL, MySQL или SQL Server — это отдельные процессы ОС, а не одна "монолитная" программа на всех пользователей сразу.
| Элемент | Роль |
|---|---|
Главный процесс (postmaster в PostgreSQL) | Слушает сеть, создаёт процесс на новое подключение, следит за служебными процессами |
| Backend / session process | Один клиент — один процесс: парсит SQL, держит состояние транзакции, отдаёт результат |
| Разделяемая память | Общий кэш страниц и журнала для всех сессий (shared_buffers, WAL buffers) |
| Фоновые процессы | WAL Writer, checkpoint, vacuum, сбор статистики, репликация — без участия пользовательского SQL |
Приложение не пишет в файлы таблиц напрямую — оно шлёт SQL по сети (или через сокет), а СУБД решает, какие страницы прочитать, куда записать изменение и когда сбросить буферы на диск. Запись изменений сначала идёт в журнал (WAL), затем — в файлы данных (глава 8, архитектура PostgreSQL).
У SQLite нет отдельного сервера и postmaster: библиотека в процессе приложения. Модель "одно подключение — один процесс" характерна для классического серверного PostgreSQL.
Архитектура доступа к данным
По способу размещения логики СУБД и данных выделяют:
| Архитектура | Как устроено | Когда встречается |
|---|---|---|
| Файл-сервер | Файлы БД на сервере; на каждой рабочей станции — своя копия СУБД, синхронизация через блокировки файлов | Малые локальные базы (Access, старые Paradox/dBase) |
| Клиент–сервер | СУБД и данные на сервере; клиенты шлют запросы по сети | PostgreSQL, MySQL, Oracle, SQL Server |
| Встраиваемая | СУБД как библиотека внутри приложения, без отдельной установки сервера | SQLite, SQL Server Compact, встроенный Firebird |
Файл-серверная схема для крупных систем с высокой доступностью и централизованной безопасностью обычно не подходит: нагрузка на сеть и слабый единый контроль. Клиент–сервер даёт централизованную политику прав, журналы и резервное копирование.
Распределённые СУБД размещают фрагменты данных на нескольких узлах (сегментирование, репликация, гетерогенные узлы) — отдельная тема в разделе SQL и администрировании.
Запись на диск — сразу или с задержкой
СУБД выбирают стратегию сброса изменённых страниц из буфера на диск:
- Непосредственная запись — при подтверждении транзакции изменённые блоки сразу пишутся во внешнюю память (редко, когда диск очень быстрый).
- Отложенная запись — изменения копятся в буферах до контрольной точки, нехватки места под журнал, остановки СУБД или нехватки RAM под буферы.
Отложенная запись снижает число обращений к диску и ускоряет OLTP; согласованность при сбое обеспечивает журнал предзаписи (WAL) — сначала запись в лог, потом страницы данных.
Microsoft SQL Server в экосистеме СУБД
Microsoft SQL Server — пример клиент–серверной реляционной СУБД с собственным процедурным языком T-SQL, службой Database Engine и набором инструментов администрирования и разработки. В корпоративной среде часто сочетается с Windows, Active Directory, .NET и Azure SQL.
| Компонент СУБД (общий) | Реализация в SQL Server |
|---|---|
| Ядро и хранение | Database Engine |
| Язык запросов | SQL + Transact-SQL |
| GUI для DBA/разработчика | SSMS, Azure Data Studio — см. обзор инструментов |
| Подключение приложений | Драйверы и библиотеки |
Официальный хаб документации: Microsoft SQL на Learn. В энциклопедии: взаимодействие приложений с СУБД, T-SQL и процедурные расширения, справочник SQL Server.
См. также
- Знакомство с базами данных — четыре типа БД, сравнение с файловым хранением
- Архитектура PostgreSQL · PostgreSQL — практика
- Теоретические основы реляционных данных
- Двенадцать правил Кодда
- Роль базы данных в организации
- Конкурентный доступ
- Восстановление после сбоя
- Управление реляционными СУБД