Транзакции в реляционных базах данных

Содержание

1. 1. Роль транзакций в целостности данных3
2. 2. Свойства ACID и их реализация5
3. 3. Управление параллельным доступом и изоляцией8
4. 4. Восстановление после сбоев и резервное копирование10
5. Список литературы13

1. Роль транзакций в целостности данных

Реляционная модель данных строится на строгих правилах: каждая таблица описывает сущность, каждая строка уникальна, каждый атрибут хранит атомарное значение. Но сами по себе эти правила не защищают базу от разрушения в процессе работы. Если банк переводит деньги со счёта на счёт, то операция списания без зачисления создаст состояние, в котором баланс клиента просто исчезнет. Именно для таких случаев вводится понятие транзакции.

Транзакция это логическая единица работы, последовательность операций над данными, которая выполняется целиком или не выполняется вовсе. Определение из книги Кристофера Дейта «Введение в системы баз данных» звучит как «неделимая единица работы». Представьте, что вы бронируете авиабилет: система списывает деньги, резервирует место и отправляет подтверждение. Если после списания денег сервер упадёт, а место останется свободным, вы потеряете и деньги, и билет. Транзакция не позволяет этому случиться: при сбое все три операции откатываются, и база возвращается к исходному состоянию.

Необходимость транзакций становится особенно очевидной при конкурентном доступе. В современных системах сотни пользователей одновременно читают и пишут данные. Без управления такими операциями два кассира могут продать один и тот же последний билет: оба прочитают число 1, оба уменьшат его до нуля, и оба получат подтверждение. Транзакции изолируют эти процессы друг от друга, чтобы каждый работал с согласованным снимком данных.

Целостность данных в реляционных базах обеспечивается не только транзакциями, но и декларативными ограничениями. Первичные ключи гарантируют уникальность каждой строки, внешние ключи следят за тем, чтобы ссылки на родительские записи не вели в никуда, CHECK-ограничения проверяют допустимость значений, например возраст не может быть отрицательным. Транзакция здесь выступает как

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

В архитектуре СУБД транзакции занимают центральное место. Подсистема управления транзакциями координирует их начало, выполнение и завершение. Рядом с ней работает подсистема управления буферами, которая решает, когда страницы данных записывать на диск, а когда держать в оперативной памяти. И наконец, журналирование фиксирует каждое изменение в специальном журнале, чтобы после сбоя можно было восстановить согласованное состояние. Эти три механизма работают в связке: буферный менеджер может задержать запись данных на диск ради производительности, но журнал обязан быть сохранён первым.

Именно поэтому проектировщики СУБД уделяют столько внимания транзакциям. Они образуют тот слой, который отделяет логику приложения от физических деталей хранения. Разработчик пишет простой SQL-код, а СУБД сама решает, как обеспечить атомарность и согласованность при любых обстоятельствах, будь то отключение питания или переполнение диска. Без этого слоя реляционные базы не могли бы служить фундаментом для банковских систем, интернет-магазинов или медицинских информационных систем.

2. Свойства ACID и их реализация

Свойства ACID сформулировали в конце 1970-х годов. Тогда банковские и корпоративные системы остро нуждались в надежной обработке данных. Аббревиатура объединяет четыре независимых гарантии, которые вместе определяют поведение любой транзакционной системы. Каждое свойство решает свою конкретную проблему, но реализуются они через общие механизмы ядра СУБД.

Атомарность, это принцип «все или ничего». Если транзакция прервана на середине выполнения, база данных не должна остаться в состоянии, где часть операций применена, а часть потеряна. Представьте перевод денег между счетами: списание с одного и зачисление на другой должны произойти одновременно. Если система выйдет из строя между этими двумя операциями, деньги просто исчезнут. В реальных СУБД механизм атомарности строится на журнале транзакций. Туда каждая операция записывается до того, как реально изменит данные на диске. При сбое система просматривает журнал и откатывает незавершенные транзакции, возвращая базу к исходному состоянию.

Согласованность гарантирует, что транзакция переводит базу данных из одного корректного состояния в другое. Корректность определяется набором ограничений целостности: первичные и внешние ключи, CHECK-ограничения, уникальность значений. Разработчик может написать транзакцию, которая нарушает эти правила, но СУБД просто не даст ей зафиксироваться. Важно понимать: согласованность, это ответственность не только системы, но и прикладного кода. База данных проверяет формальные ограничения, а бизнес-логика (например, правило «сумма всех счетов равна нулю») должна поддерживаться самим программистом. Кристофер Дейт в своей классической работе «Введение в системы баз данных» пишет, что согласованность, это свойство транзакции как единицы корректности, а не отдельной операции.

Изоляция решает проблему параллельного выполнения. Когда несколько транзакций одновременно работают с одними и теми же данными, они не должны видеть промежуточные состояния друг друга. Пока транзакция А изменяет запись, транзакция Б должна видеть либо старое значение, либо дождаться завершения А. Полная изоляция достигается за счет того, что каждая транзакция работает с собственной версией данных, а изменения становятся видимыми только после фиксации. В современных СУБД (PostgreSQL, MySQL) для этого применяется многоверсионное управление конкурентным доступом (MVCC). Каждая транзакция получает снапшот данных на момент своего начала и работает с ним, не блокируя других участников. Промежуточные состояния скрыты: читатели никогда не увидят наполовину обновленную строку.

Долговечность, это обещание, что зафиксированная транзакция переживет любой сбой, включая внезапное отключение питания. Как только система подтвердила клиенту успешную фиксацию, данные обязаны сохраниться. На практике это достигается за счет журнала упреждающей записи (Write-Ahead Logging, WAL). Идея проста: сначала запись об изменении попадает в журнал на диске, и только потом изменяется сама страница данных в буферном пуле. Если система упадет между этими двумя шагами, при восстановлении она прочитает журнал и применит изменения, которых нет на диске. Поэтому долговечность тесно связана с управлением буферами: нельзя сбрасывать измененные страницы на диск раньше, чем соответствующие записи окажутся в журнале.

Реализация всех четырех свойств опирается на два ключевых компонента: журнал транзакций и протоколы управления буферами. Журнал, это последовательный файл, в который записывается каждое изменение данных вместе с идентификатором транзакции. Управление буферами определяет, когда и как страницы данных записываются на диск. Классический протокол WAL требует, чтобы журнал был сброшен на диск до фиксации транзакции. Это правило сформулировал Джим Грей, лауреат

премии Тьюринга 1998 года, в своих работах по отказоустойчивым системам. Грей показал, что атомарность и долговечность достижимы только при строгом соблюдении порядка записи: сначала журнал, потом данные. Нарушение этого порядка приводит к тому, что после сбоя невозможно определить, какие изменения были применены, а какие нет.

Стоит подчеркнуть: ACID, это не абстрактная теория, а инженерная необходимость. Без атомарности финансовая система теряла бы деньги, без долговечности результаты работы пропадали бы при каждой перезагрузке, без изоляции параллельные пользователи портили бы данные друг друга. Каждое свойство имеет четкую реализацию в коде СУБД, и эти реализации не являются тривиальными. Они включают сложные алгоритмы синхронизации, оптимизации ввода-вывода и структуры данных, обеспечивающие быстрый доступ к журналу. В следующих главах мы рассмотрим, как именно СУБД обеспечивают изоляцию при параллельном доступе и какие методы используются для восстановления после сбоев.

3. Управление параллельным доступом и изоляцией

Свойства ACID декларируют изоляцию, но если бы транзакции выполнялись строго последовательно, производительность СУБД упала бы до нуля. Поэтому базы данных разрешают параллельную работу. И тут возникает главный вопрос: как гарантировать корректность результата, когда несколько операций одновременно читают и меняют одни и те же строки.

Ещё в 1970-х годах Джим Грей в работе над System R описал аномалии параллельного доступа. Их четыре. Потерянное обновление случается, когда две транзакции читают одно и то же значение, меняют его и пишут обратно. Вторая запись просто затирает результат первой. Грязное чтение, это когда одна транзакция видит данные, которые другая ещё не зафиксировала и вполне может откатить. Неповторяющееся чтение разрушает консистентность внутри одной транзакции: строка, прочитанная дважды, оказывается разной из-за чужих изменений. С фантомами сложнее: при повторном выполнении запроса с условием появляются строки, которых раньше не было, хотя уже существующие не тронуты.

В 1992 году стандарт SQL закрепил четыре уровня изоляции, и каждый запрещает свой набор аномалий. Read Uncommitted разрешает все четыре, то есть фактически работает вообще без контроля параллелизма. Read Committed исключает только грязное чтение; это уровень по умолчанию в PostgreSQL и Oracle. Repeatable Read дополнительно запрещает неповторяющееся чтение, но фантомы остаются возможны. Serializable устраняет все аномалии, но требует максимальных накладных расходов.

Классический способ реализовать уровни изоляции, блокировки. Разделяемая (S) ставится при чтении: другие читатели допускаются, писатели, нет. Исключительная (X) ставится при записи и запрещает любые другие операции. Протокол двухфазной блокировки (2PL) требует, чтобы транзакция сначала набрала все нужные блокировки (растущая

фаза), а потом освобождала их (фаза сжатия). Если блокировки держатся до фиксации или отката, протокол гарантирует сериализуемость. Плата за это высока: взаимные блокировки порождают тупики, и СУБД приходится принудительно откатывать одну из транзакций.

Альтернативу предложил менеджер транзакций PostgreSQL, внедрив многоверсионное управление (MVCC). Идея в том, что каждая запись создаёт новую версию строки, а старые не удаляются. Читающая транзакция получает снапшот состояния базы на момент своего старта и работает только с теми версиями, которые были зафиксированы к этому моменту. Писатель не блокирует читателя: читатель просто не видит незавершённых изменений, работая со старым снапшотом. Это заметно повышает параллелизм в системах с преобладанием чтения. Правда, устаревшие версии надо периодически чистить (в PostgreSQL это делает vacuum).

Выбор уровня изоляции всегда компромисс. Банковская система не может позволить потерю обновления, поэтому там нужен как минимум Repeatable Read. Интернет-магазин, где каталог читают в сотни раз чаще, чем пишут, спокойно работает на Read Committed, мирясь с риском неповторяющегося чтения ради скорости. Администратор базы выбирает не абстрактно «лучший» уровень, а тот, что даёт приемлемую согласованность при допустимой производительности для конкретного приложения.

4. Восстановление после сбоев и резервное копирование

Если свойства ACID описывают, какой должна быть транзакция, то механизмы восстановления отвечают на вопрос, как этого добиться на практике, когда оборудование отказывает, а питание пропадает. Долговечность, заявленная в главе 2, не была бы достижима без продуманной системы журналирования. Её суть проста и радикальна: никакое изменение данных не считается выполненным, пока запись о нём не попала на диск.

Этот принцип известен как Write-Ahead Logging (WAL), или журналирование с упреждающей записью. Работает он так: перед тем как модифицировать страницу базы данных в оперативной памяти, СУБД сохраняет в специальный журнал информацию о том, что именно будет изменено. Только после успешной записи в журнал транзакция может быть зафиксирована. Если система упадёт в этот момент, журнал содержит всю информацию для повторения операции. Классическое описание этого механизма можно найти в работе Джима Грея, который ещё в 1970-х годах заложил теоретические основы протоколов восстановления. Его алгоритмы, такие как ARIES, до сих пор используются в PostgreSQL, MySQL и других системах.

Но журнал растёт, и восстанавливать базу, прокручивая его с самого начала, было бы слишком долго. Поэтому СУБД периодически создают контрольные точки. Контрольная точка, это момент, когда все изменённые страницы из буферов принудительно сбрасываются на диск, а в журнале делается специальная пометка. После этого все транзакции, завершившиеся до контрольной точки, гарантированно сохранены в базе данных. Восстановление после сбоя начинается не с нуля, а именно с последней контрольной точки, что сокращает время простоя системы с десятков минут до секунд. В PostgreSQL, например, этот процесс настраивается параметрами checkpoint_timeout и max_wal_size, которые определяют компромисс между частотой

записи на диск и скоростью восстановления.

Сам процесс восстановления после внезапного отказа выглядит как двухфазная процедура. Сначала СУБД анализирует журнал, начиная с последней контрольной точки. Она находит транзакции, которые не успели зафиксироваться, и выполняет их откат: отменяет все изменения, которые они успели внести. Это необходимо, чтобы не нарушить атомарность. Затем система повторно применяет изменения из журнала для тех транзакций, которые успели получить подтверждение о фиксации, но чьи данные ещё не были записаны в основную базу. Именно так обеспечивается долговечность: результат завершённой транзакции не теряется даже при полном отключении питания.

Однако журналирование бессильно перед физическим повреждением носителя: перегоревший диск или случайно удалённый файл данных не восстановить из журнала, если сам журнал тоже уничтожен. Для таких случаев существует резервное копирование. Полная резервная копия создаёт слепок всей базы данных в определённый момент времени. Она служит базой для восстановления, но делать её каждый час накладно из-за объёма данных. Поэтому применяются инкрементальные копии, которые содержат только изменения, произошедшие с момента последней копии любого типа, и дифференциальные, фиксирующие изменения относительно последней полной копии. Инкрементальное копирование экономит место, но требует последовательного применения всех копий по цепочке, что медленно. Дифференциальное восстанавливается быстрее, но занимает больше места.

Современные СУБД, такие как Oracle или SQL Server, используют комбинацию всех этих методов. Ежедневное полное резервирование, почасовые дифференциальные копии и непрерывная архивация журналов транзакций позволяют восстановить базу данных до состояния на любую минуту, а не только на момент последней копии. При этом журнал, который служит для восстановления после сбоя,

одновременно используется и для репликации, когда изменения передаются на резервный сервер. Такая многоуровневая стратегия минимизирует потери данных до нескольких секунд и обеспечивает защиту от большинства возможных катастроф, от программной ошибки до пожара в дата-центре.

СПИСОК ЛИТЕРАТУРЫ

1. Реляционные базы данных в примерах — https://svyatoslav.biz/relational_databases_book/

2. Введение в системы баз данных — https://citforum.ru/book/date/date_c.shtml

3. Введение в системы управления базами данных — https://citforum.ru/database/dblearn/index.shtml

4. Базы данных — http://infosec.spb.ru/wp-content/uploads/2020/06/bazy-dannyh.pdf

5. Введение в реляционные базы данных и СУБД — https://kpfu.ru/staff_files/F_307454421/Vvedenie_v_SUBD.pdf

6. Управление параллельным доступом. Базы и банки данных — https://siblec.ru/informatika-i-vychislitelnaya-tekhnika/bazy-i-banki-dannykh/8-upravlenie-parallelnym-dostupom

7. Управление параллельным доступом - СУБД «Квант-Гибрид» — https://repo.quantom.info/qhb/std-1/doc/1.5.2/ru/Internal/mvcc.html

8. Глава 5. Обработка и восстановление транзакции — http://onreader.mdl.ru/DatabaseInternals/content/Ch05.html