Databazada concurrency control: locks, 2PL va deadlock
Assalamu Alaykum bugun databazadagi concurrency control haqida gaplashib o'tamiz. Bugungi maqolada concurrent tranzaksiyalar qanday ishlaydi va undan kelib chiqadigan muammolar , ularni hal qilish yo'llari bilan tanishamiz.
Databazada bizda bir muammo bor qaysi tranzaksiya oldin tugagani ma'lumotni o'zgartirish uchun juda zarur va bir vaqtda 2 ta tranzaksiya bir xil ma'lumot ustida ishlab uni commit qilish orqali inconsistent holatdagi databaza keltirib chiqarishi mumkin buni har xil yo'llar orqali qilish mumkin :
Haqiqatdan ketma ket qilish
2 Phase locking
Optimistic Concurrency texnikasi.
Ketma-ket qilish
1-usulda haqiqatdan hamma tranzaksiyalar ketma-ket bo'lishi kerak , bu degani 1 vaqtda faqat bitta tranzaksiya ishlaydi va bu performancega juda katta ta'sir qiladi. Oldin tranzaksiyalar shunaqa bo'ladi deb hisoblashgan , vaqtlar o'tib tranzaksiyalar foydalanuvchining kiritgan ma'lumotlariga qarab ishlaydigan bo'lgan va foydalanuvhci bir fikrga kelishi juda qiyin.
Shuning uchun biz foydalanuvchini kutmaslik uchun stored procedura ishlatishimiz mumkin. Ammo bularni hisobga olishimiz kerak :
Har bir databazaning stored procedura uchun o'zining tili mavjud
Databazada ishlayotgan kodni. debug qilish juda qiyin.
Xato yozilgan procedura databaza performanceni tushirib yuborishi mumkin.
2 Phase locking
Xo'sh 2PL haqida bilishdan oldin locklar haqida bilib olishimiz kerak. Bular shared lock and exclusive lock.
Lock nima o'zi ?— Lock bu qator yoki butun jadvalda ushlanishi mumkin . U o'zgartirish yoki o'qishni bloklab qo'yishi mumkin. Bular isolation levellarda ham locklarni ishlatish orqali implimentatsiya qilingan .
Exclusive lock
Exclusive lock — bu men qachonki bir ma'lumotni o'zgartirmoqchi bo'lsam xuddi shu ma'lumotni hech kim o'qiyolmasligi hamda o'zgartirolmasligi kerak. Bu consistency sabablari uchun qilinadi . Agar boshqa tranzaksiya shu ma'lumotni olishga harakat qilsa xatolik qaytadi.
BEGIN;
UPDATE accounts
SET balance = balance - 300
WHERE id = 1;
COMMIT;Yoki
SELECT balance
FROM accounts
WHERE id = 1
FOR UPDATE;Shared lock
Shared lock bu exclusive lockning teskarisi qachonki men databazadan ma'lumot o'qiyotganda uni hech kim o'zgartirmayotgan bo'lishi kerak . Agar o'zgartirmoqchi bo'lsa xatolik qaytadi. shared lock misoli :
BEGIN;
SELECT balance
FROM accounts
WHERE id = 1
FOR SHARE;
COMMIT;
Predicate lock— Bu qaysidir condition uchun lock qilish masalan 10 Avgust 11da xona bron qilmoqchisiz. bu uchun 10 Avgust kuni to'liq blocklanadi bron qilish uchun va tranzaksiya tugagandan so'ng ochiladi.
Tepada asosiy 2 xil turdagi locklar haqida gapirdik databazalar ichida bular implimentatsiyaga qarab ko'p bo'lishi mumkin.
Agarda exclusive lock qilmoqchi bo'lsangiz ushbu rowda shared lock bo'lmasligi kerak.
Dead lock
Dead lock — bu qachonki 2 tranzaksiya bir birini tugatishini kutayotganda bo'ladi va circularlik natijasida hech kim ishni tugatolmaydi. Ko'pchilik databazalar buni automatik tarzda ushlab ularni to'xtatishadi. Oxirgi bo'lib dead lockga qo'shilgan tranzaksiya fail bo'ladi.
2 Phase locking
2 Phase locking g'oyasi bu hamma locklarini birdaniga ishga tushurib ularni birdaniga olib tashlash. Qiziq tomoni qachonki locklar olinganda. keyin uni qayta qo'llolmaysiz. 2PL da ko'p tranzaksiyalar ma'lumotni o'qiy oladi agarda unga hech kim yozmayotgan bo'lsa. U bunday ishlaydi :
Agarda A tranzaksiya ma'lumotlarni o'qiyotgan bo'lsa va B tranzaksiya uni o'zgartirmoqchi bo'lsa Ani tugashini yoki xatolik tufayli abort bo'lishini kutadi.
Agarda A ma'lumot yozayotgan bo'lsa va B uni o'qimoqchi bo'lsa , A ni tugashini yoki fail bo'lishini kutadi .
Bu bizga race condition oldini olishga yordam beradi.
2PL implimentatsiyasi
2PL ning implimentatsiyasi quyidagicha bo'ladi , lock yoki shared yoki exclusive bo'ladi:
Agarda Tranzaksiya ma'lumot o'qimoqchi bo'lsa u ma'lumotga shared lock qo'llashi kerak. Buni bir necha tranzaksiya bir vaqtda qila oladi , agar ma'lumotda exclusive lock bo'lsa kutiladi.
Agarda tranzaksiya ma'lumotni o'zgartirmoqchi bo'lsa u ma'lumotga exclusive lock qo'llashi kerak. Boshqa locklar buni ishlatolmaydi , agarda ma'lumotda lock bo'lsa kutish kerak.
Agar tranzaksiya o'qib keyin o'zgatirsa u shared lockni exclusive lockga o'zgartirishi kerak. Va u tepadagiday ishlaydi.
Lock tranzaksiya oxirigacha amal qiladi.
Agarda A tranzaksiya B ga, B tranzaksiya Aga bog'liq bo'lsa bu dead lock bo'lib u databaza tomonidan abort qilinadi.
Performance
2PL da locklar tufayli performance tushadi, hamda concurrency kamayadi, deadl ock abort bo'lganligi tufayli tranzaksiyada amalga oshirilgan ishlar qayta qilinishi kerak. Agar dead locklar ko'p bo'lsa u performancega yaxshigina ta'sir qiladi.
Pessimistic va optimistic concurrency control
Pessimistic concurrency controlda har bir ish qilishdan oldin lock qilib keyin ish boshlanadi . Bu multi threadingdagi mutual exclusionga o'xshaydi. Pessimestic CC har doim lock qilganligi uchun boshqa tranzaksiyalarni concurrencydan blocklaydi. 2PL bu pessimestic concurrencyning bir misoli.
Optimistic CC esa hamma narsaga qo'yib beradi faqatgina u ma'lumotlat tranzaksiyada commit bo'layotgan payti tekshiradi. Agar ushbu ma'lumot boshqa tranzaksiya tomonidan o'zgartirilgan bo'lsa unda tranzaksiya abort qilinib rollback bo'ladi. Va foydalanuvchi qayta urinishi kerak.
Xulosa
Xulosa qilib aytadigan bo'lsak concurrency databazalar uchun og'riqli mavzu hisoblanadi buni optimistic va pessimestic usulda hal qilish mumkin. Har 2 sini ham yaxshi va yomon tomonlari bor , masalan pessimestic CC da foydalanuvchi kutib turishiga qaramay bir so'rovda hammasi hal bo'ladi, optimistic CC da esa faqat commit jarayonida tekshirgani uchun , hamma ish qilingandan so'ng tranzaksiya orqaga qaytadi ammo concurrency saqlanadi agarda ustma-ust yozilmasa muammosiz ishlayveradi.