Перейти к основному контенту
NGPP
Кабинет

Учебный конструктор · базы данных

Базы данных: запрос, индекс, транзакция, репликация

Четыре вещи, которые отделяют «пишу запросы наугад» от понимания. Собери SQL-запрос и увидь, что он отберёт; включи индекс и сравни миллион прочитанных строк с двумя десятками; пройди транзакциипо шагам и поймай аномалию; поиграй с репликацией и её лагом. Всё — вживую.

Незнакомые слова (индекс, B-tree, ACID, изоляция, лаг…) → словарь внизу. Где БД в общем пути → карта «с нуля до DevOps».

Собери запрос — движок сам найдёт строки. Ты описываешь ЧТО нужно, а не как искать (это и есть декларативность SQL).

WHERE=
SELECT * FROM users
WHERE city = 'Москва';

Движок прочитал 8 строк, вернул 4. На большой таблице тут помог бы индекс — см. вкладку «Индексы».

Таблица users — подсвечены отобранные
idnamecityageactive
1АннаМосква28true
2БорисКазань41false
3ВераМосква34true
4ГлебСочи23true
5ДинаКазань52true
6ЕгорМосква19false
7ЖаннаСочи37true
8ЗурабМосква45true

📖 Словарь: простыми словами

Встретил незнакомое слово выше — найди его здесь. Коротко — суть; разверни — подробное объяснение с аналогией.

SQLязык запросов: говоришь ЧТО хочешь, а не КАК достать

Декларативный язык: «SELECT … WHERE …» описывает нужный результат, а планировщик СУБД сам решает, как его эффективнее получить (с индексом или сканом). Тот же принцип декларативности, что в Terraform/Kubernetes.

Таблица / строка / столбецданные хранятся как таблицы со строками и колонками

Реляционная БД — это набор таблиц. Строка (row) — одна запись (один пользователь), столбец (column) — одно поле (имя, город). Связи между таблицами — по ключам.

Индексоглавление: найти строку, не читая всю таблицу

Отдельная отсортированная структура (обычно B-tree), указывающая, где лежат строки с нужным значением. Поиск по индексу — это ~log(N) переходов вместо чтения всех N строк. Плата: индекс занимает место и замедляет запись (его тоже надо обновлять).

B-treeсбалансированное дерево — основа индексов

Поиск идёт от корня к листу за высоту дерева (~log от числа строк): на миллион строк — порядка 20 шагов вместо миллиона. Поэтому индекс по нужному столбцу превращает «полный скан» в почти мгновенный поиск.

Транзакция / ACIDгруппа операций «всё или ничего»

Транзакция выполняется целиком или откатывается полностью (Atomicity), не нарушает правил (Consistency), не мешает другим (Isolation) и переживает сбой после фиксации (Durability). Это защита данных от полусделанных изменений.

Уровень изоляциинасколько транзакции «видят» друг друга

Компромисс между скоростью и строгостью. Чем выше уровень (READ COMMITTED → REPEATABLE READ → SERIALIZABLE), тем меньше аномалий (грязное/неповторяемое чтение, потерянное обновление), но больше блокировок/откатов. Выбираешь по задаче.

Аномалия параллелизмабаг от одновременной работы транзакций

Например потерянное обновление (двое прочитали, прибавили, один результат затёрся) или грязное чтение (увидел незафиксированное чужое). Правильный уровень изоляции их предотвращает.

Репликация (primary/replica)копии БД на других серверах

Записи идут в primary и копируются на replica-серверы. Чтения можно раздавать по репликам (масштабирование чтения). При async-репликации реплика чуть отстаёт (лаг) — можно прочитать слегка устаревшее. Если primary упал — реплику повышают (failover).

Лаг репликацииреплика отстаёт от primary на доли секунды

При асинхронной репликации primary подтверждает запись, не дожидаясь реплик. Поэтому сразу после записи чтение с реплики может вернуть старое значение. Синхронная репликация убирает лаг ценой скорости записи.

Дальше по теме

Эти инструменты связаны с текущим — так задачи стыкуются на практике.

Все инструменты — в каталоге.