Журнал упреждающей записи

Журнал упреждающей записи (англ. Write-Ahead Log, WAL) — это механизм обеспечения целостности и атомарности транзакций в системах управления базами данных (СУБД) и других системах, работающих с постоянным хранением данных. Основной принцип WAL заключается в том, что любые изменения данных сначала записываются в специальный журнал (лог), и только после этого применяются к основным файлам базы данных. Это гарантирует, что в случае сбоя система сможет восстановить своё состояние до согласованного, используя записи в журнале.

История и развитие

Концепция упреждающей записи возникла как развитие идей журналирования в операционных системах и базах данных. В ранних СУБД (например, в IMS компании IBM) для обеспечения надёжности использовались теневые страницы (shadow paging), но этот подход имел недостатки, связанные с фрагментацией и сложностью управления. В 1970-х годах, с развитием реляционных СУБД, таких как System R (IBM) и Ingres, стал активно применяться метод WAL.

Теоретическое обоснование журнала упреждающей записи было дано в работах Джима Грея и других исследователей в области транзакционных систем. В 1980-х годах WAL стал стандартом де-факто для большинства коммерческих СУБД, включая Oracle, DB2, Sybase и Microsoft SQL Server. В 1990-х годах механизм был адаптирован для открытых СУБД, таких как PostgreSQL и MySQL (с движками InnoDB и MyISAM). В 2000-х годах WAL начал применяться в нереляционных системах (NoSQL), например, в Apache Cassandra, MongoDB и RocksDB, для обеспечения долговечности данных.

Принцип работы

Основная идея WAL заключается в соблюдении правила «сначала журнал, потом данные» (англ. write-ahead logging). Процесс обновления данных в системе с WAL выглядит следующим образом:

Начало транзакции: Система создаёт запись о начале транзакции в журнале.
Модификация данных: Вместо непосредственного изменения данных на диске, система записывает в журнал информацию о том, какие изменения будут произведены (например, «вставить строку с ключом 42 в таблицу T» или «изменить значение поля X с A на B»). Эта запись называется лог-записью (log record).
Фиксация журнала на диске: Лог-запись сбрасывается на диск (синхронизируется с физическим носителем). Только после этого система может приступить к применению изменений к основным файлам данных.
Применение изменений к данным: Система модифицирует страницы данных в буферном кэше (оперативной памяти) и, в зависимости от политики сброса, может записать их на диск немедленно или отложить.
Фиксация транзакции: Когда все изменения применены, в журнал записывается отметка о фиксации (commit). После этого транзакция считается завершённой.

В случае сбоя (например, отключения питания) во время шага 4, при следующем запуске система читает журнал и восстанавливает согласованное состояние. Если транзакция была зафиксирована (commit записан), но не все изменения были применены к данным, система повторно применяет изменения из журнала (этап redo). Если транзакция не была зафиксирована, система откатывает её изменения (этап undo), используя информацию из журнала.

Типы лог-записей

Лог-записи могут быть разных типов, в зависимости от того, какую информацию они хранят:

Физические записи: Содержат точные копии изменяемых страниц данных (например, «страница 42 была изменена с A на B»). Просты в реализации, но требуют много места.
Логические записи: Содержат описание операции (например, «вставить запись с ключом 42»). Компактнее, но сложнее в обработке при восстановлении.
Физико-логические записи: Комбинируют оба подхода, например, хранят идентификатор страницы и логическое описание изменения внутри неё.

Преимущества и недостатки

Преимущества

Надёжность: WAL гарантирует, что данные не будут потеряны или повреждены при сбое, если журнал записан на диск.
Производительность: Запись в журнал обычно быстрее, чем запись в произвольные места на диске, так как журнал часто пишется последовательно. Это позволяет использовать буферизацию записи данных.
Атомарность: WAL позволяет реализовать атомарные транзакции, когда либо все изменения применяются, либо ни одно.
Восстановление: Упрощает процесс восстановления после сбоя, так как не требуется сканировать всю базу данных.
Репликация: Журнал WAL может использоваться для репликации данных на другие серверы (например, в PostgreSQL через потоковую репликацию).

Недостатки

Дополнительные накладные расходы: Запись в журнал требует дополнительных операций ввода-вывода и дискового пространства.
Сложность реализации: Корректная обработка граничных случаев (например, сбой во время записи в журнал) требует тщательного проектирования.
Зависимость от журнала: Если журнал повреждён или утерян, восстановление данных может быть невозможным или крайне затруднительным.
Увеличение задержки: При синхронной записи журнала (каждый commit сбрасывается на диск) увеличивается время выполнения транзакций.

Применение в различных СУБД

PostgreSQL

В PostgreSQL журнал упреждающей записи называется WAL (Write-Ahead Log). Он используется для обеспечения атомарности и долговечности транзакций, а также для репликации (потоковая репликация на основе WAL). WAL-файлы хранятся в каталоге pg_wal (ранее pg_xlog). PostgreSQL поддерживает несколько уровней архивации WAL (например, archive_mode), что позволяет создавать резервные копии на основе непрерывного архивирования.

MySQL (InnoDB)

В MySQL движок InnoDB использует redo log (журнал повторного выполнения) и undo log (журнал отката). Redo log — это аналог WAL, который записывает изменения перед их применением к страницам данных. InnoDB также использует doublewrite buffer для защиты от частичной записи страниц, что дополняет механизм WAL.

SQLite

SQLite использует журнал упреждающей записи в режиме WAL (доступен с версии 3.7.0). В этом режиме изменения записываются в отдельный файл (-wal), а не в основной файл базы данных. Это позволяет нескольким читателям одновременно работать с базой, пока один писатель вносит изменения. В отличие от других СУБД, SQLite не требует отдельного процесса восстановления — WAL-файл автоматически применяется при следующем открытии базы.

Другие системы

Apache Cassandra: Использует commit log, который является аналогом WAL, для обеспечения долговечности данных перед записью в memtable.
MongoDB: Использует журнал (journal) для WAL, который хранится в каталоге journal.
RocksDB: Встраиваемая СУБД от Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ), использует WAL для обеспечения атомарности и долговечности транзакций.

Влияние на производительность

Производительность системы с WAL зависит от нескольких факторов:

Синхронность записи: При синхронной записи (каждый commit сбрасывает журнал на диск) надёжность максимальна, но производительность снижается из-за задержек ввода-вывода. При асинхронной записи (журнал сбрасывается периодически) производительность выше, но возможна потеря данных при сбое.
Размер журнала: Слишком маленький журнал может привести к частым переключениям между файлами, что увеличивает накладные расходы. Слишком большой — к избыточному потреблению дискового пространства.
Тип носителя: Использование SSD-накопителей значительно ускоряет запись в журнал по сравнению с HDD.
Буферизация: Многие СУБД используют буферный кэш для журнала, что позволяет группировать записи и уменьшать количество операций ввода-вывода.

Критика и альтернативы

Несмотря на широкое распространение, WAL не лишён критики. Основные недостатки:

Избыточность: Запись одних и тех же данных дважды (в журнал и в основное хранилище) увеличивает нагрузку на дисковую подсистему.
Сложность управления: В распределённых системах (например, в Google Spanner) WAL может быть заменён на более сложные протоколы, такие как Paxos или Raft, которые обеспечивают консенсус между узлами.

Альтернативы WAL включают:

Теневые страницы (Shadow Paging): Используются в некоторых СУБД (например, в ранних версиях SQLite). Изменения записываются в новые страницы, а указатели на старые страницы заменяются атомарно. Не требует журнала, но может приводить к фрагментации.
Copy-on-Write (COW): Применяется в файловых системах (ZFS, Btrfs) и некоторых СУБД (например, в LMDB). Изменения записываются в новые блоки, а старые блоки остаются неизменными до фиксации.
Журналирование на уровне приложения: В некоторых системах WAL может быть реализован на уровне приложения, а не СУБД, что даёт большую гибкость, но требует дополнительных усилий разработчика.

Интересные факты

Термин «упреждающая запись» (write-ahead) подчёркивает, что запись в журнал выполняется до применения изменений к данным, а не после.
В PostgreSQL WAL-файлы имеют фиксированный размер (по умолчанию 16 МБ) и нумеруются последовательно. Это позволяет легко архивировать и восстанавливать данные.
В некоторых СУБД (например, в Oracle) WAL называется redo log, а журнал отката — undo log.
Механизм WAL используется не только в СУБД, но и в файловых системах (например, в ext4 и NTFS) для обеспечения целостности метаданных.

Источники

Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.
Документация PostgreSQL: «Write-Ahead Log (WAL)».
Документация MySQL: «InnoDB Redo Log».
Документация SQLite: «Write-Ahead Logging».
Stonebraker, M. (1981). «Operating System Support for Database Management». Communications of the ACM, 24(7), 412–418.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →