ACID 2-qism: Isolation va isolation levellar

Assalamu Alaykum bugun ACID tamoyillaridagi I ya’ni Isolation atamasini ko'rib chiqamiz.

Ushbu mqola tushunarli bo'lishi uchun bundan oldingi 2 maqolani tavsiya qilaman :

1.Tranzaksiya nima ?

2.ACID 1-qism (Atomicity)

Isolation nima ?

Isolation bu izolyatsiya qilish yani tashqi tasirlardan himoyalash va berilgan vazifani aniq aytilganday bajarishga yordam beradigan muhit.

Isolation nimaga kerak ?

Tassavur qiling sizda databaza bir bundan faqatgina bir dona foydalanuvchi foydalanadi bu holatda hamma o'zgarishlar bir odam tomonidan qilingani uchun o'zgarishlar ustma ust yozilmaydi. Endi real loyihalarni tassavur qiling undan ming- millionlab odamlar foydalanadi . Bu holatda biz databazaga bir necha TCP connection orqali ulanib tranzaksiyalar amalga oshiramiz buyerda concurrencyamalga oshish ehtimoli bor. Bu paytda tranzaksiyalar bir xik ma’lumotni o'zgartirish uchun tortishishni boshlaydi xuddi shu joyda bizga isolation kerak bo'ladi.

Concurrency —bu bir vaqtning ichida bir necha amallar bajarilishi.

Endi bir misol siz tranzaksiyada databazadan ma’lumot o'qiyapsiz ammo shu payt boshqa tranzaksiya databazaga ma’lumotni commit qildi . Shu yerda savol tug'iladi biz o'zgarishni ko'rishimiz kerakmi ? yoki boshqa variant men bu o'zgarishlarni ko'rmoqchiman . Bu holatni databazalarda read phenomena deb atashadi.

Read phenomena

Read phenomena bu isolation darajasi bog'liq holatda siz o'qib olgan ma’lumot o'zgarishi jarayoni.

Isolation level (daraja)—bu tranzaksiya shu paytda amalga oshayotgan boshqa qaysi tranzaksiyalar o'zgarishini o'qiy olish darajasi.

Unda read phenomena turlari bilan tanishamiz:

Dirty Reads —Isolation level eng pastki daraja bo'lgan yani hali commit(Read Uncommitted) qilinmagan o'zgarishlarni ham o'qib olish.Bu qanday holat bu siz bir tranzaksiya orqali boshqa tranzaksiya databaza kiritgan ammo hali commit qilishga ulgurmagan ma’lumotni oqib olishi . Bu yerda kelib chiqadigan muammo tranzaksiya ichidaga consistent yani bir xil bo'lmasligi hamda biz o'qigan qiymat databaza yozilmay qolishi yoki rollback bo'lib ketishi mumkin. Pastdagi misol orqali yaxshiroq tushunishingiz mumkin.

Dirty Read misoli

Non-Repeatable Read —bu keyingi darajadagi isolation level(Read Committed)ga ega bo'lgan yani bunda bir tranzaksiya faqat boshqa tranzaksiyalar orqali commit qilingan o'zgarishlarni o'qiy olish (boshqa tranzaksiyalar undan keyin boshlanib tugagan bo'lishi mumkin). Bu qanday bo'ladi siz bir qiymatni hisoblab o'qidingiz va ma’lum vaqtdan keyin yana shu tranzaksiya ichida shu queryni berdingiz ammo boshqa qiymat chiqmoqda. Bu yerda siz hattoki bir tranzaksiya ichida qiymatlarni tekshira olmaysiz.

Shuning uchun Postgres SQL update tableda rowni yangi versiyasini yaratadi va , Oracle va SQL server esa qiymatni o'zgartirib eski qiymatlarni boshqa tableda saqlaydi .

Non-repeatable Read

Phantom Reads —bu bundan oldingi vaziyatdan ham yuqori darajadagi isolation level bo'lib bunda bir xil turdagi query natijalari har doim bir xil bo'lishi taminlanadi. Ammo bu asosan range yani oraliq querylarda vujudga keladi. Masalan siz bugun hozirgacha bo'lgan sotuvni bilmoqchisiz va buni query orqali aniqlab oldingiz ammo shu payt boshqa tranzaksiya tablega yangi sotuvni qo'shidi va bu keyingi umumiy summani topganingzda ikki xillikni yuzaga keltiradi(O'ylashimcha bu juda ko'p amalga oshadi). Bu non-repeatable read emas chunki biz bu qiymatni hali umuman o'qimagandik .

Odatda bu muammolar lock orqali amalga oshiriladi yani boshqalar o'zgartirish kiritmasligi orqali lock bo'ladi va rowlar read qilinganda o'zgarmaydi ammo bu narsa yangi ma’lumotni lock qilolmaydi chunki u lock qilish uchun bu yerda emas edi.

Phantom read

Lost Updates —bu siz tranzaksiyada ma’lumotlarga o'zgartirish kiritdingiz ammo uni commit qilishdan oldin tekshirganimizda u concurrent ishlayotgan tranzaksiya orqali o'zgartirilgan . Chunki ular bir vaqta ishga tushganligi tufayli bir xil boshlang'ich qiymat olishadi ammo ikkalasi ham shuni o'zgartirishga harakat qiladi. Bu muammoni lock qilish orqali hal qilishimiz mumkin va qolgan tranzaksiyalar ushbu rowga o'zgartirish kiritolmaydi .

Lost Update

Endi Isolation levellar haqida gapiramiz.Ular tepadagi muammolarni hal qilish uchun chiqarilgan .Buni SET TRANSACTION ISOLATION LEVEL buyruqi orqali o'zgartirishingiz mumkin.

  1. Read Uncommitted — Bu levelda hamma o'zgarish ko'rinadi commit qilingan yoki yoq . Isolation umuman yoq.

  2. Read Committed —bu levelda siz o'zingizdan oldin tugatilgan hamma tranzaksiya o'zgarishlarini ko'ra olasiz. Dirty Reads oldini oladi.

  3. Repeatable Read —bu levelda query bir rowni o'qiganidan so'ng ushbu row shu tranzaksiya ishlayotgan payti o'zgarmay turishini oldini oladi.Va Non-repeatable Reads oldini oladi(Postgresning repeatable read isolation level snapshot isolation kabi bo'lib hamma narsa versiyalanadi ) .

  4. Snapshot —bu darajadagi tranzaksiya ichidagi querylar faqatgina shu tranzaksiya boshlanganicha commit qilingan o'zgarishlarni ko'ra oladi . Bu xuddi databazaning o'sha versiyadagi malumotlariga o'xshaydi .Bu Phantom Readni oldini oladi .

  5. Serializable —bu levelda tranzaksiyalar seriyalangan bo'ladi bu mantiqan olib qaralsa hech qachon bir vaqtda parallel hisoblanmaydi ular ketma-ket deb hisoblanadi.

Harbir DBMS bu Isolation darajalarini har xil implimentatsiya qiladi . Isolation level Pessimistic/Optimistic Locking yo'llari bilan amalga oshiriladi . DBMS bunga row/table/page level lockqilish orqali erishadi va bu pessimistic locking deyiladi yoki o'zgarishlarni tekshirish orqali va to'g'ri kelmaydigan tranzaksiyalarni rad qilish orqali lock qilmasdan amalga oshiriladi bu Optimistic Lockingdeyiladi.

Repeatable readrowni lock qiladi va bu juda qimmat bo'lishi mumkin (qolgan tranzaksiyalar bu tranzaksiya tugashini kutib turadi) shu sababli Postgres Repeatable readni snapshot sifatida implimentatsiya qilgan va biz bunda phantom Reads muammosiga duch kelmaymiz .

Seriazable isolation level odatda optimistic concurreny control yo'li bilan amalga oshiriladi , ammo siz buni pessimestic yo'l bilan ushbu buyruq orqali SELECT FOR UPDATElock qilib ham amalga oshirishingiz mumkin.

Xulosa

Xulosa qilib aytadigan bo'lsak Isolationbir necha concurrent tranzaksiyalar bir biriga ta’sir qilmasligi uchun kerak.Va bu bizga biz ishlatayotgan query tranzaksiyani qaysi qismida ishlatilishidan qatiy nazar bir xil qiymatni berishiga yordam beradi.