Ўсім прывітанне. На сувязі Уладзіслаў Родзін. У цяперашні час я з'яўляюся кіраўніком курса «Архітэктар высокіх нагрузак» у OTUS, а таксама выкладаю на курсах, прысвечаных архітэктуры ПЗ.
Апроч выкладання, як вы маглі заўважыць, я займаюся напісаннем аўтарскага матэрыялу для блога OTUS на хабры і сённяшні артыкул хачу прымеркаваць да запуску курса , на які прама зараз адкрыты набор.
Увядзенне
В мы з вамі пагаварылі пра тое, што транзакцыі ў базах дадзеных служаць для рашэння дзвюх задач: забеспячэння адмоваўстойлівасці і доступу да дадзеных у канкурэнтным асяроддзі. Для паўнавартаснага выканання гэтых задач транзакцыя павінна валодаць уласцівасцямі ACID. Сёння мы падрабязна пагаворым пра літару I (isolation) у дадзенай абрэвіятуры.
Ізаляцыя
Ізаляцыя вырашае задачу доступу да дадзеных у канкурэнтным асяроддзі, фактычна падаючы абарону ад race condition'ов. У ідэале, ізаляцыя азначае серыялізацыю, гэта значыць уласцівасць, якое забяспечвае тое, што вынік выканання транзакцый раўналежна такі ж, як калі б яны выконваліся паслядоўна. Асноўная праблема дадзенай уласцівасці складаецца ў тым, што яно вельмі цяжка забяспечваецца тэхнічна і як следства моцна б'е па прадукцыйнасці сістэмы. Менавіта таму ізаляцыю часта саслабляюць, прымаючы рызыкі ўзнікнення некаторых анамалій, пра якія гаворка пойдзе ніжэй. Магчымасць узнікнення тых ці іншых анамалій як раз і характарызуе ўзровень ізаляцыі транзакцый.
Найбольш вядомымі анамаліямі з'яўляюцца: dirty read, non-repeatable read, phantom read, але на самой справе іх яшчэ 5: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Сутнасць анамаліі ў тым, што транзакцыі могуць перазапісваць незакаммічаныя дадзеныя.
Дадзеная анамалія небяспечная не толькі тым, што дадзеныя могуць канфліктаваць пасля коміта абедзвюх транзакцый (як на малюнку), але і тым, што парушаецца атамарнасць: таму што мы дазволім перазапісваць незакаммічаныя дадзеныя, то незразумела, як адкаціць адну транзакцыю, не закрануўшы пры гэтым іншую .
Лячыцца анамалія досыць проста: вешаем блакаванне на запіс перад пачаткам запісу, забараняючы іншым транзакцыям змяняць запіс датуль, пакуль блакаванне не будзе знятая.
Dirty read
Dirty read азначае чытанне незакаммічаных дадзеных.
Праблемы ўзнікаюць, калі на аснове выбаркі неабходна ажыццявіць нейкія дзеянні ці прыняць рашэнні.
Для выпраўлення анамаліі можна павесіць блакаванне на чытанне, але гэта моцна стукне па прадукцыйнасці. Значна прасцей сказаць, што для rollback'а транзакцыі зыходны стан дадзеных (да пачатку запісу) абавязкова павінна быць захавана ў сістэме. Чаму б не чытаць адтуль? Гэта дастаткова нядорага, таму большасць баз дадзеных прыбіраюць dirty read па-змаўчанні.
Lost update
Lost update азначае страчаныя абнаўленні, і пераклад дастаткова дакладна адлюстроўвае сутнасць праблемы:
Фактычна вынік транзакцыі Т2 быў адменены. Выпраўляецца такая сітуацыя відавочнымі або няяўнымі блакіроўкамі запісу. Гэта значыць, мы або проста ажыццяўляем абнаўленне запісу, і тады ўзнікае няяўная блакіроўка, або мы выконваем выбраць для абнаўлення, выклікаючы ўзнікненне блакіроўкі на чытанне і на запісы. Звернеце ўвагу на тое, што такая аперацыя досыць небяспечная: сваім "нявінным" чытаннем, мы блакуем іншыя чытанні. Некаторыя базы прапануюць больш бяспечны select for share, які дазваляе чытаць дадзеныя, але не які дазваляе іх змяняць.
Cursor lost update
Для больш тонкага кантролю базы могуць прапанаваць іншыя прылады, напрыклад, курсор. Курсор-гэта структура, якая змяшчае набор радкоў і якая дазваляе па іх итерироваться. declare cursor_name for select_statement. Змесціва курсора апісваецца select'ам.
Навошта патрэбен курсор? Справа ў тым, што некаторыя базы дадзеных прапануюць блакаванне на ўсе запісы, абраныя select'ам (read stability), альбо толькі на той запіс, на якой знаходзіцца ў дадзены момант курсор (cursor stability). Пры cursor stability ажыццяўляецца short lock, што дазваляе зменшыць колькасць блакаванняў у тым выпадку, калі мы итерируемся па вялікай выбарцы дадзеных. Таму анамалію lost update вылучаюць для курсора асобна.
Non-repeatable read
Non-repeatable read заключаецца ў тым, што падчас выканання нашай транзакцыі 2 паслядоўныя чытанні аднаго і таго ж запісу прывядзе да атрымання розных вынікаў, таму што іншая транзакцыя ўмяшалася паміж гэтымі двума чытаннямі, памяняла нашы дадзеныя і была закаммічана.
Чаму гэта ўвогуле праблема? Уявіце сабе, што мэта транзакцыі Т2 на малюнку абраць усе тавары, кошт якіх менш, чым 150 у.а. Хтосьці іншы абнавіў кошт да 200 у.а. Такім чынам, усталяваны фільтр не спрацаваў.
Дадзеныя анамаліі перастаюць узнікаць пры даданні двухфазных блакіровак або пры выкарыстанні механізму MVCC, пра што хацелася б пагаварыць асобна.
Phantom read
Фантомным называецца чытанне дадзеных, якія былі дададзены іншай транзакцыяй.
У якасці прыкладу можна назіраць няправільную выбарку самага таннага тавара пры ўзнікненні дадзенай анамаліі.
Пазбавіцца ад фантомных чытанняў ужо дастаткова складана. Звычайнай блакіроўкі недастаткова, бо б не можам заблакаваць тое, чаго яшчэ няма. 2PL-сістэмы выкарыстоўваюць прэдыкатыўную блакіроўку, тады як MVCC-сістэмы планавальнік транзакцый адмяняе транзакцыі, якія могуць быць парушаны ўстаўкай. Як першы, так і другі механізмы дастаткова цяжкавагавыя.
Read skew
Read skew узнікае калі мы працуем з некалькімі табліцамі, змест якіх павінен мяняцца ўзгоднена.
Дапусцім, маюцца табліцы, якія прадстаўляюць пасты і іх метаінфармацыю:
Адна транзакцыя чытае з табліц, іншая іх змяняе:
У выніку выканання транзакцыі Т1, у паста title = Good, а updated_by = T2, што з'яўляецца некаторай неадпаведнасцю.
Фактычна, гэта non-repeatable read, але ў складзе некалькіх табліц.
Для выпраўлення, Т1 можа вешаць блакіроўкі на ўсе радкі, якія яна будзе чытаць, што не дасць транзакцыі Т2 мяняць інфармацыю. У выпадку MVCC транзакцыя Т2 будзе адменена. Абарона ад дадзенай анамаліі можа стаць важнай, калі мы выкарыстоўваем курсоры.
Write skew
Гэтую анамалію таксама прасцей растлумачыць на прыкладзе: выкажам здагадку, што ў нашай сістэме хаця б адзін доктар павінен быць на дзяжурстве, але абодва доктары вырашылі сваё дзяжурства адмяніць:
Анамалія прывяла да таго, што ніводны з дактароў не выйдзе на дзяжурства. Чаму так атрымалася? Таму што транзакцыя правярала ўмову, якая можа быць парушана іншай транзакцыяй, а з-за ізаляцыі мы не ўбачылі гэтую змену.
Гэта той самы non-repeatable read. Як варыянт, select'ы могуць вешаць блакіроўкі на гэтыя запісы.
Write skew і read skew з'яўляюцца камбінацыямі папярэдніх анамалій. Можна разгледзець write skew, які з'яўляецца ў сутнасці phantom read'ом. Разгледзім табліцу, у якой ёсць імёны супрацоўнікаў, іх заробак і праект, на якім яны працуюць:
У выніку, мы атрымліваем наступную карціну: кожны мэнэджар думаў, што яго змена не прывядзе да выхаду за бюджэт, таму яны ўнеслі кадравыя змены, якія ў суме прывялі да перарасход.
Прычына ўзнікнення праблемы сапраўды такая ж, як і ў фантомным чытанні.
Высновы
Паслабленне ўзроўню ізаляцыі транзакцый у базе даных з'яўляецца кампрамісам паміж бяспекай і прадукцыйнасцю, да выбару дадзенага ўзроўню трэба падыходзіць зыходзячы з патэнцыйных рызык для бізнесу пры ўзнікненні тых ці іншых анамалій.
Крыніца: habr.com