КРИТИКА підхід, заснований на використанні властивостей ACID

Як було сказано в главі 15, в цій главі буде продовжено опис властивостей ACID транзакцій Насправді, у автора склалося досить нестандартне думку з цієї теми, як незабаром стане очевидним

Спочатку нагадаємо, що ACID – це скорочене позначення таких властивостей транзакцій, як нерозривність, правильність, ізольованість і стійкість (atomicitycorrectness-isolation-durability) Нижче ці властивості коротко описані повторно

■ Нерозривність Будь конкретна транзакція діє за принципом все або нічого.

■ Правильність (зазвичай іменоване в літературі як сумісність – consistency)

Будь конкретна транзакція перетворює правильний стан бази даних в інше правильний стан, притому що збереження властивості правильності на всіх проміжних етапах цього перетворення не є обовязковим

■ Ізольованість Будь-які оновлення, внесені конкретної транзакцією, осту ются прихованими від усіх інших транзакцій доти, поки не відбудеться фікса ція даної транзакції

■ Стійкість Після фіксації будь-якої конкретної транзакції внесені нею про новления залишаються в базі даних, навіть якщо згодом станеться аварійний останов системи

Отже, на перший погляд за скороченням ACID стоять вельми бажані властивості, але чи так дійсно виглядають представляються ними поняття при більш уважному дослідженні У даному розділі наведені деякі свідоцтва, які показують, що в загальному відповідь на це питання є негативним

Негайна перевірка обмежень

Почнемо з того, що може здатися відступом від основної теми, – з обгрунтування нашої позиції, вперше явно сформульованої в розділі 9, про те, що всі обмеження цілісності повинні перевірятися негайно (Тобто по закінченні виконання оператора), а

Не відкладайте до кінця транзакції В основі цієї позиції лежать щонайменше чотири причини, які описані нижче

1 Як відомо, будь-яка база даних може розглядатися як колекція вискази ваний (які відповідно до прийнятого угодою вважаються істинними) А якщо є хоч якась вірогідність, що ця колекція буде включати будь-які неузгоджені, суперечливі висловлювання, то всі ці припущення ста новятся безглуздими Ми не повинні ні в якому разі довіряти відповідям, по лучанин з суперечливою бази даних фактично з подібної бази даних можна взагалі отримати абсолютно будь-яка відповідь (доказ цього факту дано в анотації до [916] в розділі 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 як таких Але буде простіше провести такий аналіз, розглядаючи дані властивості в послідовності CIDA (Correctness-Integrity-Durability-Atomicity)

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

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

Узгодженість Правильність

Крім того, в тій же книзі дано наведене нижче визначення властивості узгодженості транзакцій

Узгодженість Транзакція – це правильне перетворення стану З цим станом повязані дії, обєднані в групу, які не порушують какихлибо обмежень цілісності Для цього потрібно, щоб транзакція представляла собою правильну програму [саме так]

Але якщо обмеження цілісності завжди перевіряються негайно, то база даних завжди є узгодженою (але не обовязково правильної) І транзакції завжди свідомо перетворюють базу даних з одного узгодженого стану в інший узгоджений стан

Тому, якщо буква С в абревіатурі ACID позначає узгодженість (consistency), то сенс цієї властивості є трівіальним9, а якщо воно позначає правильність (correctness), то його не можна досягти, примусово вводячи будь-які протоколи (див п 2 в підрозділі Негайна перевірка обмежень) Тому, так чи інакше, це властивість фактично є безглуздим, щонайменше, з формальної точки зору Як вже було сказано, сам автор воліє розглядати букву С як скорочене позначення властивості правильності, але ретельний аналіз показує, що так зване властивість правильності фактично слід вважати не властивістю як таким, а всього лише благим побажанням

Ізольованість

Тепер розглянемо властивість ізольованості Як вже було зазначено в даному розділі, в підрозділі Негайна перевірка обмежень, це властивість також є досить сумнівним Але, по крайней міру, не можна заперечувати того, що якщо кожна транзакція діє за таким же принципом, як якби вона була єдиною транзакцією в системі, то бездоганно діючий механізм управління паралельним виконанням гарантує ізольованість (і упорядочіваемость) транзакцій Проте, для того щоб транзакція могла діяти як якби вона була єдиною

9 Насправді, він був би тривіальним, навіть якби перевірка обмежень не здійснювалася негайно, оскільки все одно виконувався б відкат транзакції, а це було б рівнозначно тому, що вона не виконувалася у разі порушення будь-якого обмеження Іншими словами, все одно залишається в силі таку умову, що транзакції надають довгостроковий вплив на базу даних, тільки якщо вони не порушують ніяких обмежень

транзакцією в системі , вона, крім усього іншого, повинна відповідати перерахованим нижче вимогам

■ Чи не робити спроб (навмисних чи інших) вступати у взаємодій ствие з іншими транзакціями (виконуваними паралельно чи іншими)

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

Отже, насправді властивість ізольованості також більшою мірою нагадує благі побажання, ніж абсолютну гарантію Більш того, в практично застосовуваних системах зазвичай передбачені явно задані механізми (а саме рівні ізоляції менше максимального), дія яких зводиться саме до того, що вони нівелюють властивість ізольованості

Стійкість

Тепер розглянемо властивість стійкості Ця властивість є досяжним завдяки використанню механізму відновлення системи, за умови, що відсутня вкладеність транзакцій І дійсно, до теперішнього часу передбачалося, що ця вимога дотримується Але припустимо, що підтримується вкладеність транзакцій А саме: припустимо, що транзакція в вкладена в транзакцію А і відбувається показана нижче послідовність подій

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

BEGIN TRANSACTION (транзакція В) транзакція У оновлює кортеж t COMMIT (транзакція В)

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

Якщо виконується оператор ROLLBACK транзакції А, то фактично виконується також відкат транзакції в (оскільки в насправді входить до складу А) Тому вплив транзакції в на базу даних не є стійким по суті, виконання оператора ROLLBACK транзакції А викликає відновлення того значення кортежу t, яке він мав до виконання транзакції А Іншими словами, дотримання властивості стійкості більше не можна гарантувати, щонайменше, для транзакцій, подібних транзакції в, розглянутої в даному прикладі, яка вкладена в деяку іншу транзакцію

А тепер відзначимо, що багато авторів, починаючи з Девіса (Davies) [158], фактично запропонували передбачити можливість вкладати транзакції в тій формі, яка показана в наведеному вище прикладі А в [1515] стверджується, що така підтримка бажана щонайменше з трьох причин: розпаралелювання роботи між транзакціями, управління відновленням з урахуванням декількох транзакцій і підвищення модульності системи Але, як показує даний приклад, в системі з подібною підтримкою оператори COMMIT, виконані у внутрішній транзакції, фіксують оновлення, внесені до цієї транзакції, але тільки на наступному, більш зовнішньому рівні По суті, зовнішня транзакція володіє правом вето на виконання операторів COMMIT внутрішніми транзакціями, оскільки якщо зовнішня транзакція виконує відкат, відбувається також відкат і внутрішньої транзакції У даному прикладі оператор

COMMIT транзакції в є таким тільки для транзакції А, але не для зовнішнього світу, а фактично цей оператор COMMIT згодом скасовується (відбувається його відкат)

Примітка Слід зазначити, що вкладені транзакції можуть розглядатися як узагальнення поняття точок збереження Точки збереження дозволяють структурувати транзакції як лінійні послідовності дій, виконувані одна за одною (і відкат до початку будь-якого попереднього дії в даній послідовності може відбутися в будь-який час) На відміну від цього, вкладення дозволяє структурувати транзакції рекурсивно, як ієрархію дій, які можуть виконуватися одночасно Іншими словами, є справедливими наведені нижче твердження

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

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

■ Оператор ROLLBACK скасовує виконану роботу, але тільки аж до початку даної конкретної транзакції (включаючи самі дочірні транзакції, дочірні транзакції цих дочірніх транзакцій і тд, але не включаючи батьківську тран ЗАКЦ, якщо вона є)

Тепер, повернувшись до головної теми даного обговорення, можна переконатися в тому, що властивість стійкості транзакцій є застосовним тільки на самому зовнішньому рівні (іншими словами, застосовується тільки до транзакціях, що не вкладеним в інші транзакції) 10 Тому в загальному ми переконалися в тому, що це властивість також не гарантовано на все 100%

Нерозривність

Нарешті, розглянемо властивість нерозривності Як і властивість стійкості, дана властивість гарантується механізмом відновлення системи (навіть у вкладених транзакцій) Наші заперечення проти використання цієї властивості дещо відрізняються від наведених вище заперечень А саме: достатньо просто зазначити, що якби система підтримувала множинне присвоювання, то не потрібно було б вимагати від транзакцій як таких, щоб вони мали властивістю нерозривності замість цього, було б достатньо вимагати це тільки від операторів Крім того, все одно необхідно дотримуватися умова, щоб оператори також володіли властивістю нерозривності, з причин, вже докладно описаним в інших стандартах11

10 В [1515] зазначено, що таке ж твердження є справедливим і по відношенню до властивості узгодженості, оскільки в цій статті, як і в більшій частині літератури, присвяченій даній темі, передбачається, що сама зовнішня транзакція зовсім не обовязково повинна забезпечувати узгоджений ність на проміжних етапах Але ми не поділяємо цю позицію по вже описаних вище причин

1 До речі, слід зазначити, що властивістю нерозривності, зокрема, володіють багато операто ри, описані в стандарті SQL

Заключні зауваження

Ми можемо підсумувати цей розділ за допомогою наведених нижче досить риторичних питань

■&nbsp&nbsp&nbsp&nbsp&nbsp Чи справді транзакція є одиницею роботи Так, але тільки якщо не підтримується множинне присвоювання

■&nbsp&nbsp Чи справді вона є одиницею відновлення Той же відповідь

■&nbsp&nbsp&nbsp&nbsp Чи справді вона є одиницею паралельності Той же ответ3

■&nbsp&nbsp&nbsp&nbsp Чи справді вона є одиницею цілісності Так, але тільки якщо не зі блюдается вимога, що перевірка всіх обмежень повинна здійснюватися негайно.

Примітка Наведені тут відповіді є такими незважаючи на багато зауваження, зроблені в попередніх розділах (а також в попередніх виданнях даної книги), які більшою мірою слідували здоровому глузду, накопиченому в цій галузі знань

Тому в цілому наш висновок полягає в тому, що поняття транзакції є значущим більшою мірою з практичної точки зору, ніж з теоретичною Автор просить зрозуміти його правильно, що цей висновок не слід розглядати як прагнення перекреслити всю роботу, зроблену в цій області У нього не викликають нічого, крім глибокої поваги, ті численні витончені і корисні результати, які отримані протягом більше ніж 25 років досліджень в галузі управління транзакціями Він просто зазначає, що тепер ми володіємо набагато кращим розумінням деяких передумов, на яких були засновані ці дослідження, – зокрема, кращим розумінням найважливішої ролі обмежень цілісності, а також визнанням того, що необхідна підтримка множинного присвоювання як примітивного оператора І дійсно, було б дивно, якби зміна передумов не спричинила за собою перегляд висновків, зроблених на їх підставі

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*