Примеры ACID в базах данных
Следующие ниже примеры дополнительно иллюстрируют свойства ACID. В этих примерах таблица базы данных имеет два столбца, A и B. Ограничение целостности требует, чтобы сумма значения в A и значения в B равнялась 100. Следующий код SQL создает таблицу, как описано выше:
CREATE TABLE acidtest
(A INTEGER, B INTEGER, CHECK (A + B = 100));
Атомарность
Атомарность - это гарантия того, что серия операций с базой данных в атомарной транзакции либо будет выполнена (успешная операция), либо ничего не произойдет (неудачная операция). Серии операций нельзя разделить, выполняя только некоторые из них, что делает серию операций "неделимой". Гарантия атомарности предотвращает частичное обновление базы данных, что может вызвать более серьезные проблемы, чем полный отказ от всей серии. Другими словами, атомарность означает неделимость и несводимость. В качестве альтернативы мы можем сказать, что логическая транзакция может состоять из одной или нескольких физических транзакций или состоять из них. Если и до тех пор, пока не будут выполнены все физические транзакции компонентов, логическая транзакция не произойдет - это будет сказываться на базе данных. Скажем, наша логическая транзакция состоит из перевода средств со счета A на счет B. Эта логическая транзакция может состоять из нескольких физических транзакций, состоящих из сначала удаления суммы со счета A в качестве первой физической транзакции, а затем, в качестве второй транзакции, внесения указанной суммы в счете B. Мы не хотели бы, чтобы сумма была удалена со счета A, пока мы не убедимся, что она была переведена на счет B. Затем, если и пока не произошли обе транзакции и сумма не была переведена на счет B, перевода нет, к эффектам базы данных, не произошло.
Нарушение согласованности
Согласованность - это очень общий термин, который требует, чтобы данные соответствовали всем правилам проверки. В предыдущем примере для проверки требуется, чтобы A + B = 100. Все правила проверки должны быть проверены для обеспечения согласованности. Предположим, что транзакция пытается вычесть 10 из A без изменения B. Поскольку согласованность проверяется после каждой транзакции, известно, что A + B = 100 до начала транзакции. Если транзакция удаляет 10 из A успешно, атомарность будет достигнута. Однако проверка покажет, что A + B = 90, что несовместимо с правилами базы данных. Вся транзакция должна быть отменена, а затронутые строки откатятся до состояния до транзакции. Если бы были другие ограничения, триггеры или каскады, каждая отдельная операция изменения проверялась бы так же, как указано выше, до того, как транзакция была бы зафиксирована. Подобные проблемы могут возникнуть и с другими ограничениями. Возможно, нам потребовалось, чтобы типы данных A и B были целыми числами. Если мы затем введем, скажем, значение 13,5 для A, транзакция будет отменена, или система может вызвать предупреждение в форме триггера (если/когда триггер был написан для этого эффекта). Другой пример - ограничения целостности, которые не позволят нам удалить строку в одной таблице, первичный ключ которой упоминается хотя бы одним внешним ключом в других таблицах.
Нарушение изоляции
Чтобы продемонстрировать изоляцию, мы предполагаем, что две транзакции выполняются одновременно, каждая из которых пытается изменить одни и те же данные. Один из двух должен дождаться завершения другого, чтобы поддерживать изоляцию.
Рассмотрим две транзакции: T1 передает 10 от A к B. T2 передает 20 от B к A.
В совокупности есть четыре действия:
- T1 вычитает 10 из A.
- T1 добавляет 10 к B.
- T2 вычитает 20 из B.
- T2 добавляет 20 к A.
Если эти операции выполняются по порядку, изоляция сохраняется, хотя Т2 должен ждать. Подумайте, что произойдет, если T1 выйдет из строя на полпути. База данных исключает эффекты T1, и T2 видит только действительные данные.
Посредством чередования транзакций фактический порядок действий может быть следующим:
- T1 вычитает 10 из A.
- T2 вычитает 20 из B.
- T2 добавляет 20 к A.
- T1 добавляет 10 к B.
Опять же, подумайте, что произойдет, если T1 откажет при изменении B на шаге 4. К моменту отказа T1 T2 уже изменил A; его нельзя восстановить до значения, которое было до T1, не оставив недопустимой базы данных. Это известно как сбой записи-записи, потому что две транзакции пытались выполнить запись в одно и то же поле данных. В типичной системе проблема может быть решена путем возврата к последнему известному рабочему состоянию, отмены неудачной транзакции T1 и перезапуска прерванной транзакции T2 из хорошего состояния.
Отказ долговечности
Рассмотрим транзакцию, которая передает 10 из A в B. Сначала она удаляет 10 из A, затем добавляет 10 к B. На этом этапе пользователю сообщается, что транзакция прошла успешно. Однако изменения все еще находятся в очереди в дисковом буфере, ожидая фиксации на диске. Сбой питания, и изменения теряются. Пользователь предполагает (по понятным причинам), что изменения сохраняются.
Читайте также:
Комментарии
Отправить комментарий