ACID 4-qism: Durability nima? WAL va OS cache

Assalamu Alaykum bugun ACIDtamoyillaridagi D ya’ni Durabilityatamasini ko'rib chiqamiz.

Ushbu maqolani o'qishdan oldin bu seriyadagi boshqa maqolalarni o'qishni tavsiya qilaman :

Agenda

  1. Tranzaksiya nima ?

  2. ACID 1-qism (Atomicity)

  3. ACID 2-qism (Isolation, Isolation levels)

  4. ACID 3-qism (Consistency)

Durability

Durability —bu o'zbekchda chidamlilik degani bo'ladi ammo bu unchalik ham to'g'ri emas ammo qisman to'gri , Bu nima degani o'zi biz databazaga ma’lumotni yozib bo'lganimizdan so'ng svet o'chib qolsa databaza qulasa hamma uni qayta yoqqanimda ma’lumotlar shu yerda turishi kerak . Masalan siz databazaga tranzaksiyani commit qildingiz ammo shu paytda hamma joyda internet uzildi ammo internet tiklangandan so'ng u malumotlar turgan bo'lishi kerak chunki ular diskda saqlanadi.

Bu yerda sizga a bu osonku deyishingiz mumkin ammo diskga yozish sizga qimmatga tushishi mumkin ya’ni u juda sekin va databazani sekinlashtiradi, shuning uchun ko'p databazalar oldin men buni xotirada saqlayman va vaqti vaqti bilan orqa tarafdan uni diskga yozib boraman (redisda bu xususiyat mavjud) .Ammo relational databazalarda durability juda muhim, Xo'sh unda durability tarifini ko'ramiz .

Durability— Commit(tugatilgan) bo'lgan tranzaksiya o'zgarishlari o'zgarmas doimiy xotirada (SSD, qattiq disk) saqlanishi kerak.

Durability texnikalari

  1. WAL(write ahead log) —bu holatda har bir o'zgarish birinchi bo'lib WAL ga boradi va bu bizga ma’lumotda bir xillikni taminlashga yordam beradi , ya’ni biz buni hali databazaga yozishga ulgurmadik ammo biror holat bo'lsa (databaza qulasa , svet o'chib qolsa) ma’lumotni qayta tiklay olamiz va avvalgidek o'zgartira olamiz .Buning usulning asosiy yechimi qattiq diskga to'g'ridan to'g'ri ko'p malumot(indexes , data files, columns, rows) yozish juda ko'p vaqt oladi , va bizga yaxshiroq yo'l kerak DBMS o'zgarishlarni compress qilingan versiyasini WAL da saqlaydi va u databazaga nimani qaysi qiymatga o'zgartirishni aytib turadi .

  2. Asynchronous snapshot — bu holatda biz ma’lumotlarni snapshot holida xotirada saqlaymiz va asynchronous holatda uni orqa tarafdan diska yozib boramiz .

  3. AOF— bu ham WAL ga o'xshaydi yani u o'zgarishlarni oldin logga yozib xotiradagai o'zgarishlarni keyin boshlaydi AOFda esa bu o'zgarishlar avval xotirada amalga oshiriladi va keyin loglarda yozib qo'yiladi (redis ishlatadi ).

Bu usullar katta tranzaksiyalarda ma’lumotlarni xotiraga saqlashning oson , tez va ishonchli usuli hisoblanadi .Va bular ma’lumot saqlanishini vada beradi .

Databazalar uchun durabilityni to'liq amalga oshirish uchun bir muammo bor bu OS (operatsion sistema) Cache.

OS Cache muammosi

Bu muammo qanday yuzaga keladi, databaza operatsion sistemadan diskga nimadir yozishni so'raydi , os to'g'ridan to'g'ri uni diskga yozmaydi , uni shunchaki o'zining xotirasiga cache saqlab qo'yadi . Chunki u ularni yig'ib birdaniga (batch) yozishni boshlaydi buning sababi performance , ya'ni agar ular birgalikda yozilsa kamI/Obo'ladi va kam I/O degani bu tezroq . Bu yerda bir muammo bor masalan sizg tranzaksiyani WALga commit qildingiz u osga buni diskda yoz dedi disk uni cachega yozib yozildi dedi va db sizga tranzaksiyani muvafaqqiyatli commit qildik deb sizga ko'rsatadi , va shu payt osda xatolik bo'ldi va siz kompyuterga restart bo'ldi .Va qayta ishga tushurish natijasida siz u ma’lumotni yo'qotasiz chunki u cacheda edi qattiq diskda emas . Xuddi shu vaziyatda(bu holat kamku deyishingiz mumkin ammo bu bo'lishi mumkin va dasturlashda hamma narsa hisobga olinishi zarur) databaza durablehisoblanmaydi chunki u men tranzaksiyani commit qildim deb aytdi amm o'zgarishlarni saqlab qololmadi . Xuddi shu muammoni olish uchun OS cacheni chetlab o'tib to'g'ri diskga yozish uchun fsyncbuyrug'i bor, buni ishlatgan paytimiz databaza durable ammo tez bo'lmaydi chunki har doim diskga yozish sekin.

Sizda savol bo'lishi mumkin os nega bunaqa qiladi bu boshqa dasturlash uchun hech qanday muammo tugdirmaydi masalan siz excelda yoki words bunchalik kerakli narsalar saqlanmaydi va bu holat kam uchragani uchun bu qabul qilinadi . Ko'rib turganingizdek dasturlash har doim trade offlardan iborat nimagadir erishish uchun nimanidir qurbon qilishingiz kerak .