Главная » SQL, Базы данных » КРИТИКА ПОДХОДА, ОСНОВАННОГО НА ИСПОЛЬЗОВАНИИ СВОЙСТВ ACID

0

Как было сказано в главе 15, в настоящей главе будет продолжено описание свойств ACID транзакций. В действительности, у автора сложилось довольно  нестандартное мнение по этой теме, как вскоре станет очевидным.

Вначале напомним, что ACID — это сокращенное обозначение таких свойств транзакций, как неразрывность, правильность, изолированность и устойчивость  (atomicitycorrectness-isolation-durability). Ниже эти свойства кратко описаны повторно.

■     Неразрывность. Любая конкретная транзакция действует по принципу "все или ничего".

■     Правильность (обычно именуемое в литературе как совместимость — consistency).

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

■     Изолированность. Любые обновления, внесенные конкретной транзакцией, оста ются скрытыми от всех других транзакций до тех пор, пока не произойдет фикса ция данной транзакции.

■     Устойчивость. После фиксации любой конкретной транзакции внесенные ею об новления остаются в базе данных, даже если впоследствии произойдет аварийный останов системы.

Итак, на первый взгляд за сокращением ACID стоят весьма желаемые свойства, но так ли действительно выглядят представляемые ими понятия при  более внимательном исследовании? В данном разделе приведены некоторые свидетельства, которые показывают, что в общем ответ на этот вопрос является отрицательным.

Немедленная проверка ограничений

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

не откладываться до конца транзакции. В основе этой позиции лежат по меньшей мере четыре причины, которые описаны ниже.

1.  Как известно, любая база данных может рассматриваться как коллекция высказы ваний (которые в соответствии с принятым соглашением считаются истинными). А если есть хоть какая-то вероятность, что эта коллекция будет включать любые несогласованные, противоречивые высказывания, то все эти предположения ста новятся бессмысленными. Мы не должны ни в коем случае доверять ответам, по лученным из противоречивой базы данных; фактически из подобной базы данных можно вообще получить абсолютно любой ответ (доказательство этого факта дано в аннотации к [9.16] в главе 9). Хотя свойство изолированности (или кратко свой ство "i" — isolation) транзакций может означать, что с любой конкретной несогла сованностью может столкнуться не больше чем одна транзакция, неоспоримым фактом остается то, что все равно с этой несогласованностью столкнется данная конкретная транзакция, поэтому может выработать неправильные ответы. Имен но поэтому прежде всего необходимо ввести в действие ограничения — не по той причине, что путем изоляции следует исключить возможность обнаруживать эти несогласованности больше чем в одной транзакции одновременно, а потому, что с несогласованностями вообще нельзя смириться.

2.  Так или иначе, нельзя гарантировать, что любая конкретная несогласованность (при условии, что допускается их наличие в базе данных) будет обнаружена только одной транзакцией. Подлинной гарантией того, что транзакции остаются изоли рованными друг от друга, может стать только соблюдение в них определенных протоколов, причем эти протоколы не должны вводиться принудительно (а в дей ствительности их невозможно ввести принудительно). Например, если транзакция А обнаруживает противоречивое состояние базы данных и поэтому записывает не согласованные данные в некоторый файл F, после чего транзакция в считывает ту же информацию из файла F, то А и в фактически не являются изолированными друг от друга (независимо от того, выполняются ли они параллельно или в любом другом режиме)8. Иными словами, свойство "I" транзакций находится под сомне нием, если не сказать большего.

3.  В предыдущем издании данной книги было указано, что ограничения переменной отношения проверяются немедленно, а ограничения базы данных проверяются в конце транзакции (с этой позицией соглашаются многие авторы, хотя они обычно используют  другую   терминологию).  Но   из   принципа   взаимозаменяемости (базовых и производных переменных отношения — см. главу 9) следует, что одно и то же практическое ограничение может стать ограничением переменной отноше ния в одном проекте базы данных и ограничением базы данных — в другом! По скольку вполне очевидно, что ограничения переменной отношения должны про веряться немедленно, из этого следует, что и ограничения базы данных также должны проверяться немедленно.

8  В действительности, эта проблема возникает, даже если транзакция А не обнаруживает  несогласованного состояния базы данных; все еще остается возможность того, что транзакция  А  сама записала несогласованные данные в определенный файл, который впоследствии считывается транзакцией В.

626     Часть IV. Управление транзакциями

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

Примечание. Семантическая оптимизация — это метод использования ограничений целостности для упрощения запросов в целях повышения производительности. Очевидно, что если ограничения не удовлетворяются, то и результаты упрощений будут неправильными. Дополнительная  информация по этой теме приведена в главе 18.

Безусловно, здравый смысл подсказывает, что проверку ограничений базы  данных почти наверняка приходится откладывать на более позднее время. В качестве простейшего примера предположим, что на базу данных поставщиков и деталей распространяется ограничение "Поставщик si и деталь Р1 находятся в одном том же городе". Если поставщик S1 переезжает, скажем, из Лондона в Париж, то деталь Р1 также необходимо перевезти из Лондона в Париж. Обычно применяемое решение этой проблемы состоит в том, что оба обновления заключаются в одну транзакцию, как показано ниже.

BEGIN TRANSACTION     ;

UPDATE S WHERE S#     = S# (‘S1′) { CITY := ‘Paris’ } ; UPDATE P WHERE P#     = P# (‘P1′) { CITY :=

‘Paris’ } ; COMMIT ;

В этом обычном решении указанное ограничение проверяется при выполнении оператора COMMIT, а база данных на этапе между двумя операциями UPDATE остается несогласованной. В частности, следует отметить, что если бы в этой транзакции, где выполняются операторы UPDATE, был задан вопрос "Находятся ли поставщик S1 и деталь Р1 в одном и том же городе?" на этапе между выполнением этих двух операторов UPDATE, TO был бы получен отрицательный ответ.

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

UPDATE S WHERE S# = S# (‘S1′) { CITY := ‘Paris’

} , UPDATE P WHERE P# = P# (‘P1′) { CITY := ‘Paris’ } ;

В таком случае никакие проверки целостности не выполняются до завершения обработки обоих операторов UPDATE (т.е., как принято условно обозначать эту ситуацию, "до  достижения точки с запятой").  Следует  также  отметить,  что  в  данном  случае   исключена   вероятность  того,  что указанная  транзакция  обнаружит  противоречивое   состояние  базы  данных  на  этапе  между выполнением  двух  операторов  UPDATE,  поскольку  теперь  понятие  "этап  работы  между  двумя операторами UPDATE" не имеет смысла.

Из   этого   примера   следует,   что   если   бы   поддерживалась   операция   множественного присваивания, то не было бы необходимости осуществлять отложенную проверку в традиционном смысле этого термина (т.е. выполнять ее как проверку, которая отложена до конца транзакции).

Теперь перейдем к анализу свойств ACID как таковых. Но будет проще провести такой анализ, рассматривая данные свойства в последовательности C-I-D-A (Correctness— Integrity-Durability-Atomicity).

Правильность

Автор уже изложил свои соображения (в главе 15) относительно того, почему он предпочитает использовать указанный здесь термин правильность вместо более общепринятого термина согласованность. Создается впечатление, что в литературе эти два понятия приравниваются. Например, ниже приведена цитата из глоссария к книге Грея (Gray) и Рейтера (Reuter) [15.12].

Согласованность. Правильность.

Кроме того, в той же книге дано приведенное ниже определение свойства согласованности транзакций.

Согласованность. Транзакция — это правильное преобразование состояния. С этим состоянием связаны действия, объединенные в группу, которые не нарушают какихлибо ограничений целостности. Для этого требуется, чтобы транзакция представляла собой правильную программу [именно так!].

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

Поэтому, если буква С в аббревиатуре ACID обозначает согласованность (consistency), то смысл этого свойства является тривиальным9, а если оно  обозначает правильность (correctness), то его нельзя достичь, принудительно вводя какие-либо протоколы (см. п. 2 в подразделе "Немедленная проверка ограничений"). Поэтому, так или иначе, это свойство фактически является бессмысленным, по меньшей мере, с формальной точки зрения. Как уже было сказано, сам автор предпочитает рассматривать букву С как сокращенное обозначение свойства правильности, но тщательный анализ показывает, что так называемое свойство правильности фактически следует считать не свойством как  таковым, а всего лишь благим пожеланием.

Изолированность

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

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

транзакцией в системе", она, кроме всего прочего, должна соответствовать перечисленным ниже требованиям.

■     Не предпринимать попыток (преднамеренных или иных) вступать во взаимодей ствие с другими транзакциями (выполняемыми параллельно или иными).

■      Не допускать даже возможности влияния того, что в системе могут существовать другие транзакции (задавая уровень изоляции меньше максимального).

Итак, в действительности свойство изолированности также в большей степени напоминает благие пожелания, чем абсолютную гарантию. Более того, в практически применяемых системах обычно предусмотрены явно заданные механизмы (а именно уровни изоляции меньше максимального), действие которых сводится именно к тому, что они нивелируют свойство изолированности.

Устойчивость

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

BEGIN TRANSACTION (транзакция А) ;

BEGIN TRANSACTION(транзакция В) ; транзакция В обновляет кортеж t ; COMMIT (транзакция В) ;

ROLLBACK (транзакция А) ;

Если выполняется оператор ROLLBACK транзакции А, то фактически  выполняется также откат транзакции в (поскольку в в действительности входит в состав А). Поэтому воздействие транзакции в на базу данных не является устойчивым; по сути, выполнение оператора ROLLBACK транзакции А вызывает восстановление того значения кортежа t, которое он имел до выполнения транзакции А. Иными словами, соблюдение свойства устойчивости больше нельзя гарантировать, по меньшей мере, для транзакций, подобных транзакции в, рассматриваемой в данном примере, которая вложена в некоторую другую транзакцию.

А теперь отметим, что многие авторы, начиная с Дэвиса (Davies) [15.8], фактически предложили предусмотреть возможность вкладывать транзакции в  той  форме, которая показана в приведенном выше примере. А в [15.15] утверждается, что такая поддержка желательна по меньшей мере по трем причинам: распараллеливание работы между транзакциями, управление  восстановлением с учетом нескольких транзакций и повышение модульности системы. Но, как показывает данный пример, в системе с подобной поддержкой операторы COMMIT, выполненные во внутренней транзакции, фиксируют обновления, внесенные в этой транзакции, но только на следующем, более внешнем уровне. По сути, внешняя транзакция обладает правом вето на выполнение  операторов COMMIT внутренними транзакциями, поскольку если внешняя  транзакция выполняет откат, происходит также откат и внутренней транзакции. В данном примере оператор

COMMIT транзакции в является таковым только для транзакции А, но не для внешнего мира, а фактически этот оператор COMMIT впоследствии отменяется  (происходит его откат).

Примечание. Следует отметить, что вложенные транзакции могут рассматриваться как обобщение понятия точек сохранения. Точки сохранения  позволяют структурировать транзакции как линейные последовательности действий, выполняемые одна за другой (и откат к началу любого предыдущего  действия в данной последовательности может произойти в любое время). В  отличие от этого, вложение позволяет структурировать транзакции рекурсивно,  как иерархию действий, которые могут выполняться одновременно. Иными словами, являются справедливыми приведенные ниже утверждения.

■     Оператор BEGIN TRANSACTION расширяется с учетом поддержки субтранзакций (т.е., если оператор BEGIN TRANSACTION вызывается на выполнение, притом что уже функционирует некоторая транзакция, то он запускает дочернюю транзакцию).

■     Оператор COMMIT осуществляет фиксацию, но только в области определения роди тельской транзакции (если транзакция, в которой выполнен этот оператор, явля ется дочерней).

■     Оператор ROLLBACK отменяет выполненную работу, но только вплоть до начала данной конкретной транзакции (включая сами дочерние транзакции, дочерние транзакции этих дочерних транзакций и т.д., но не включая родительскую тран закцию, если она имеется).

Теперь, вернувшись к главной теме данного обсуждения, можно убедиться в том, что свойство устойчивости транзакций является применимым только на  самом внешнем уровне (иными словами, применяется только к транзакциям, не  вложенным в другие транзакции)10. Поэтому в общем мы убедились в том, что это свойство также не гарантируется на все 100%.

Неразрывность

Наконец, рассмотрим свойство неразрывности. Как и свойство устойчивости, данное свойство гарантируется механизмом восстановления системы (даже во вложенных транзакциях). Наши возражения против использования этого свойства несколько отличаются от приведенных выше возражений. А именно: достаточно просто отметить, что если бы система поддерживала множественное присваивание, то не нужно было бы требовать от транзакций как таковых, чтобы они обладали свойством неразрывности; вместо этого, было бы достаточно требовать это только от операторов. Кроме того, все равно необходимо соблюдать условие, чтобы операторы также обладали свойством неразрывности, по причинам, уже подробно описанным в других стандартах11.

10   В [15.15] указано, что такое же утверждение является справедливым и по отношению к свойству согласованности, поскольку в этой статье, как и в большей части литературы, посвященной данной теме, предполагается, что самая внешняя транзакция вовсе не обязательно должна обеспечивать согласован ность на промежуточных этапах. Но мы не разделяем эту позицию по уже описанным выше причинам.

1    Кстати, следует отметить, что свойством неразрывности, в частности, обладают многие операто ры, описанные в стандарте SQL.

Заключительные замечания

Мы можем подытожить этот раздел с помощью приведенных ниже довольно риторических вопросов.

■      Действительно ли транзакция является единицей работы? Да, но только если не поддерживается множественное присваивание.

■   Действительно ли она является единицей восстановления ? Тот же ответ.

■     Действительно ли она является единицей параллельности ?Тот же ответ.3

■     Действительно ли она является единицей целостности? Да, но только если не со блюдается требование, что "проверка всех ограничений должна осуществляться немедленно".

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

Поэтому в целом наш вывод состоит в том, что понятие транзакции является значимым в большей степени с практической точки зрения, чем с теоретической. Автор просит понять его правильно, что этот вывод не следует рассматривать как  стремление перечеркнуть всю работу, сделанную в этой области! У него не  вызывают ничего, кроме глубокого  уважения,  те  многочисленные  изящные  и  полезные  результаты,  которые получены в течение больше чем 25 лет  исследований в области управления транзакциями. Он просто отмечает, что теперь мы обладаем гораздо лучшим пониманием некоторых предпосылок, на которых были основаны эти исследования, — в частности, лучшим пониманием важнейшей роли ограничений целостности, а также признанием того, что необходима поддержка множественного присваивания как примитивного оператора. И действительно, было бы удивительно, если бы смена предпосылок не повлекла за собой пересмотр заключений, сделанных на их основании.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии