БД и СУБД: кто за что отвечает
Чему научишься
- отличать базу данных (организованное хранилище) от — программы, которая выполняет SQL-запросы и управляет данными
- объяснять путь запроса «SQL → СУБД → результат» и почему файлы с Excel не выдерживают тысячи одновременных пользователей
- перечислять, что СУБД даёт помимо «просто файлов»: , журнал восстановления (), права доступа (
GRANT), проверки целостности
Глава 1 — «Карта архива»
Снимок «Котомаркета» больше не сигнал из мёртвого сектора — он лежит в карантинном отсеке «Хранилища-9», и под последней строкой его всё та же подпись: «К.». Утром на твоей голопанели вспыхивает новая запись: «Допуск: опись архива. Выдал: модуль S.Q.L.» Дверь хранилища отъезжает в сторону; за ней в янтарной подсветке ровно гудят серверные стойки.
КВЕРИ: Прежде чем читать чужую память, пойми, как она устроена. Начнём с главного: что здесь хранилище, а кто хранитель.
База данных и СУБД
База данных (БД) — это организованное хранилище. В «Котомаркета» лежат покупатели, товары, заказы и события: не россыпью в файлах, а в понятной структуре — поэтому их можно читать даже спустя сто шестьдесят лет.
Но само хранилище не отвечает на вопросы. Нужна программа, которая умеет создавать таблицы, записывать новые заказы, читать данные и следить, чтобы связи не ломались. Это (система управления базами данных). Примеры: PostgreSQL, MySQL, ClickHouse. Наш снимок — база PostgreSQL, и разговаривает она на том же SQL, что и при жизни магазина.
Ты пишешь запрос на SQL → отправляешь его в СУБД → СУБД достаёт нужные данные и возвращает результат. Excel хорош для личной таблицы, но не для магазина, где тысячи пользователей одновременно смотрят товары, оформляют заказы и оставляют события в системе.
Что СУБД умеет такого, чего не могут «просто файлы»
Кажется, магазин мог бы жить и без : писать заказы в CSV или Excel. На масштабе личного блокнота так и делают — пока не приходят задачи, ради которых СУБД и придумали.
- Конкурентный доступ. В живом «Котомаркете» покупатели оформляли заказы одновременно. Два процесса, пишущие в один файл, затирают изменения друг друга; СУБД исполняет изменения как и сама разводит параллельные операции. PostgreSQL делает это через механизм : читающие не блокируют пишущих, и наоборот.
- Восстановление после сбоя. Питание мигнуло на середине записи — файл побился, и неизвестно, какая половина заказа успела сохраниться. СУБД сначала фиксирует изменение в журнале (в PostgreSQL — , write-ahead log) и после сбоя доигрывает его: заказ либо записан целиком, либо не записан вовсе.
- Права доступа. Файл открыт либо целиком, либо никак. В СУБД права гранулярные — вплоть до отдельной таблицы:
-- Аналитику — только чтение заказов, без права их менять
GRANT SELECT ON orders TO analyst;
- Целостность. СУБД не примет заказ с ценой-строкой или со ссылкой на несуществующего покупателя: типы столбцов и ограничения проверяются при каждой записи. Файлу всё равно, что в нём лежит.
- Декларативные вопросы. «Покажи заказы дороже 5000» — одна строка SQL. С файлом ту же работу делает программа, которую кто-то должен написать и не ошибиться.
— рабочий посредник между тобой и данными: принимает SQL-запросы, исполняет их и не даёт базе превратиться в хаос. В курсе мы учимся на PostgreSQL — его часто ждут в аналитических и backend-вакансиях. С хранителем ты теперь знаком. Но прежде чем открывать опись нашего , КВЕРИ ведёт тебя к соседней секции: реестру других архивов старой Земли — чтобы ты понял, почему целиком уцелел именно наш.
Вопрос с собеседования
Вопрос с собеседования: чем база данных отличается от ? Почему приложению не хранить данные просто в файлах?
Сильный ответ: база данных — организованные данные, СУБД — программа, которая ими управляет (PostgreSQL, MySQL, ClickHouse). Файлы не дают конкурентного доступа (параллельные записи затирают друг друга), восстановления после сбоя (СУБД ведёт журнал и доигрывает незавершённые изменения), гранулярных прав и проверок целостности. И главное — СУБД отвечает на декларативные SQL-запросы, а файл пришлось бы разбирать собственным кодом.