Представь, что ты проектируешь систему для хранения миллионов записей. Тебе нужно решить: как именно эти данные будут лежать на диске, как быстро они будут читаться и как не потерять их при отключении питания. Именно для этого существуют движки баз данных — та самая штука, которая работает на самом нижнем уровне СУБД.
В англ литературе движок хранения называется storage engines
Зачем разделять СУБД и движок?
Главная фишка современной архитектуры баз данных — это модульность. СУБД берет на себя парсинг SQL, проверку прав и построение плана запроса. А вот физическое сохранение байтов она делегирует движку.
То есть ты можешь взять один и тот же сервер MySQL, но для таблицы с транзакциями подключить надежный движок InnoDB, а для таблицы с временными логами — быстрый, но менее надежный движок. Тебе не нужно переписывать систему с нуля, достаточно сменить движок хранения под конкретную нагрузку.
Из чего состоит движок
Любой современный движок (будь то InnoDB в MySQL или RocksDB) состоит из 5 ключевых менеджеров:
- Менеджер транзакций (Transaction Manager): Следит за тем, чтобы все твои
BEGINиCOMMITработали атомарно («всё или ничего»). - Менеджер блокировок (Lock Manager): Координирует доступ, когда 1000 пользователей одновременно пытаются купить последний билет на концерт. Раздает эксклюзивные и разделяемые блокировки.
- Методы доступа (Access Methods): Сердце движка. Это те самые алгоритмы и структуры данных, которые определяют, как искать инфу. Здесь живут B-деревья и LSM-деревья.
- Менеджер буферов (Buffer Manager): Ходить на диск за каждой строкой — самоубийство для производительности. Этот парень кэширует самые горячие «страницы» данных прямо в оперативной памяти (RAM).
- Менеджер восстановления (Recovery Manager): Отвечает за Durability из ACID. Пишет специальный журнал (WAL - Write-Ahead Log), чтобы восстановить базу, если сервер сгорел во время записи.
