Перейти к основному содержимому

Масштабирование БД — опорные темы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Инженеру

Масштабируемая база данных — это не один приём, а связка механизмов хранения, журналирования, индексов, репликации и согласования между узлами. Ниже — конспект тем, которые стоит пройти после основ СУБД и внутреннего устройства, перед углублённым администрированием и system design.

1. Структуры хранения и журнал​

ТемаЗачем изучатьГде в энциклопедии
B⁺-деревоТочечный и диапазонный поиск по ключу на диске; основа OLTP-индексовВосемь структур, B-деревья
LSM-деревоВысокая пропускная способность записи; уровни SSTable и compactionТаблица структур, NoSQL — WAL и LSM
Журнал упреждающей записи (WAL)Durability при сбое; основа репликации и PITRВосстановление после сбоя, теория

B⁺-дерево хранит данные только в листьях; внутренние узлы — навигация. Страница на диске (4–16 КБ) соответствует узлу дерева: одно чтение с диска — один случайный I/O. Диапазон WHERE id BETWEEN … эффективен, потому что соседние ключи лежат в соседних листьях.

LSM (Log-Structured Merge) сначала пишет в memtable в RAM (часто на skip list), затем сбрасывает неизменяемые SSTable на диск и периодически компактирует уровни. Запись последовательная и быстрая; цена — фоновое слияние файлов и усложнение чтения «свежих» данных до compaction.

WAL — принцип «сначала журнал, потом страницы таблиц». При перезагрузке СУБД проигрывает хвост журнала (redo/undo). Тот же поток WAL питает streaming replication в PostgreSQL и аналоги в других СУБД.

2. Репликация и разделение данных​

ТемаСутьГде углубиться
Репликация лидер–подчинённыйОдин primary принимает записи; replica/standby копируют журналРепликация РСУБД, MongoDB replica set
Реплики только для чтенияSELECT и отчёты на копии; запись только на primary§ ниже в 3.08, MSA-стек
ШардингДанные одной логической БД на нескольких серверах по ключуШардинг в 3.08, 12 концепций
Кэширование запросовГорячие ответы в Redis/Memcached до обращения к primaryКэш вне СУБД

Лидер–подчинённый (primary–replica, master–slave) — доминирующая схема в реляционных и документных СУБД: один источник истины для записи, несколько копий для чтения и DR. Failover переводит роль лидера на реплику (Patroni, Always On, MongoDB elections).

Read replica — реплика, на которую намеренно направляют только чтение. Учитывают replication lag: клиент после записи может не увидеть данные на replica, если читать сразу. Решения — чтение с primary после записи, sticky session, read your writes в драйвере.

Шардинг увеличивает ёмкость и запись; репликация — отказоустойчивость и чтение. На практике каждый шард часто имеет свой набор реплик.

3. Индексы для масштабирования чтения​

ТемаРольГде углубиться
Кластерный индексФизический порядок строк на диске; один на таблицу (обычно PK)Типы по роли
Вторичные индексыПоиск по не-PK полям; цепочка secondary → PK → строкаТипы по роли, практика, сложные индексы
Векторные индексы (HNSW, FAISS)Приближённый поиск ближайших соседей в многомерном пространствеВекторные БД, pgvector HNSW

Кластерный индекс задаёт порядок хранения строк (InnoDB — PK). Вторичный индекс — отдельное B⁺-дерево по email, статусу и т.д.; в InnoDB в листе всегда есть PK для доступа к строке в кластере.

HNSW — многослойный граф для ANN-поиска; параметры M, efConstruction, efSearch задают компромисс точность/скорость/память. FAISS — библиотека Meta с IVF, PQ и GPU-вариантами; часто встраивают в пайплайн, а не заменяют полностью СУБД.

4. Запросы в распределённой среде​

ТемаПроблемаПодход
Распределённые соединения (JOIN)Строки разных таблиц на разных шардах — нет локального JOIN§ в 3.08, денормализация, Shared Nothing
Материализованные представленияТяжёлый отчётный SELECT каждый разSQL — MV, семь стратегий

При шардинге запрос без ключа шарда вынуждает scatter-gather — опрос всех узлов и слияние на координаторе. JOIN между шардами ещё дороже: данные тянут по сети. Архитектурный ответ — проектировать доступ по shard key, денормализовать витрины, выносить аналитику в отдельный контур (CDC → DWH).

Материализованное представление физически хранит результат запроса; обновление — REFRESH по расписанию или инкрементально. В event-driven системах ту же роль играют проекции из потока событий.

5. Согласованность между узлами​

ТемаФазы / идеяКогда применяют
Двухфазный коммит (2PC)Prepare → Commit/Abort у всех участниковРедко в микросервисах; иногда внутри СУБД и legacy EJB
Трёхфазный коммит (3PC)Добавлен pre-commit; меньше блокировок при сбое координатораУчебная модель; на практике чаще Saga и eventual consistency

2PC — координатор спрашивает участников «готовы?», затем фиксирует или откатывает. Гарантирует атомарность распределённой транзакции, но блокирует ресурсы и падает по доступности при потере координатора.

3PC вводит дополнительную фазу, чтобы участники могли завершить транзакцию, если координатор недоступен после prepare. В промышленных микросервисах чаще выбирают Saga (локальные транзакции + компенсации) или outbox + события вместо глобального 2PC.

Подробнее — распределённые транзакции, MSA и 2PC, Saga.

6. Поток изменений и событийная модель​

ТемаСутьГде углубиться
Событийная модель хранения (event store)Состояние = replay цепочки событий; журнал append-onlyEvent Sourcing
Захват изменений данных (CDC)Поток INSERT/UPDATE/DELETE из журнала БД во внешние системыCDC в миграции MSA, outbox

Event store хранит факты (OrderPlaced, PaymentCaptured), а не перезаписывает строку. Текущее состояние для UI — материализованная проекция, которую можно пересобрать из лога.

CDC читает WAL/binlog (Debezium, logical replication) и публикует изменения в Kafka или другой bus. Это мост между OLTP-БД и поисковыми индексами, кэшем, витринами и микросервисами без опроса primary каждые N секунд.

Как темы складываются в систему​

На практике путь такой: индексы и WAL на одном узле → реплики и кэш под рост чтения → партиции и шарды под объём и запись → MV, CDC и проекции под отчёты и интеграции → Saga/outbox вместо 2PC между сервисами.

Рекомендуемый порядок чтения​

  1. Как СУБД выполняет запрос — B⁺, LSM, партиции.
  2. WAL и восстановление.
  3. Управление РСУБД — репликация и шардинг.
  4. NoSQL — репликация — если кластер не только SQL.
  5. System Design — карта — кэш, очереди, CDN в общем контуре.

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Освоение главы0%