Strong va eventual consistency farqi nima?
Assalamu Alaykum bugungi maqolamizda Strong va Eventual Consistency nimaligi va u nimaga kerakligini ko'rib o'tamiz.
Oldingi maqolalarimizda ko'rganimizdek Consistency bu ACIDning 1 xususiyati va u databazada yoki o'qiyotgan paytdagi kutilgan ma’lumotni olish ma’nosini beradi.
Eventual consistency o'zi aslida weak consistency deyiladi ,lekin marketingchi akalarimiz quloqqa yoqishi uchun nomini o'zgartirishgan.
Eventual consistency atamasi paydo bo'lishini asosiy sababi bu distributed systemga o'tganda hamma ma’lumotlar bir joyda saqlanmaydi .Bizga tez ma’lumot berish uchun caching kerak bo'ladi, ma’lumotlar turli xil regionlarda saqlanadi va buning natijasida biz bir necha kompyuterdagi ma’lumotlar bir xil bo'lishini ta'minlashimiz kerak.
Tavsiya qilinadigan maqolalar :
Eventual Consistency
Eventual consistency asosan ma’lumot o'zgartirilganda yuzaga keladi masalan siz usernameni yangiladingiz bu master dbga boradi va yangilaydi ammo shu paytda qolgan replicalarda oldingi ma'lumot saqlanib turadi. Bu holatda master db consistent ammo butun system inconsistent holatda bo'ladi.
Va bu holatda master o'zidagi ma'lumotni olib boshqalarga yangilashga beradi va sizning o'zgarishingiz butun dunyoga ko'rishi uchun bir necha daqiqa ketishi mumkin.
Strong Consistency
Bizda eventual consistencydan boshqa strong consistency ham bor . Bu qanday ishlaydi buni buyurtma qabul qiladigan dastur sifatida ko'rib chiqamiz. Bizda buyurtma qabul qiladigan va uni statistikalarini ko'rsatadigan dastur bor. Biz qachonki yangi buyurtma qabul qilsak u uni buyurtmalarga hamda statistikaga qo'shib keyin buyurtma qabul qilingani haqida foydalanuvchiga ma’lumot beradi. Bu strong consistency.
Bu yerda bir muammo bor agarda statistika databaza javob bermasa yoki murakkabligi tufayli ko'p vaqt olsa , buyurtma yaratilganiga qaramay foydalanuvchi kutib qoladi. Va Buyurtma berish jarayoni cho'zilib ketadi hattoki statistika unga to'g'ridan to'g'ri bog'liq bo'lmasa ham. Shuning uchun biz statistikaga qo'shishni buyurtma berish logikasidan olib tashlaymiz, va bu bizga statistika databaza inconsistent holatga olib keladi (countlar xato) , buni to'g'rilash uchun biz background job ishlatamiz . Bu message queuelar bo'lishi yoki cronjob ham bo'lishi mumkin , ular vaqti vaqti bilan ishga tushib statistika databazasidagi ma’lumotlarni yangilab turadi.Bu esa eventual consistency bo'ladi.
Strong consistency sizga distributed sistemani bir butun deb hisoblash imkonini beradi , ammo bu performance evaziga keladi. Yuqorida ko'rganimmizdek so'rov vaqti cho'ziladi, scalability muammosi chunki hamma ma'lumot master dbdan o'tishi kerak, availability muammosi agar biror dbga bog'lanolmasa ma'lumot databazalarga yozilmaydi. Hamda 2 va 3 replicalardagi ma'lumotlar yangilanayotganda read requestlar bloklanadi.
Strong consistency har bir so'rov uchun eng oxirgi ma’lumotni yoki buni qilolmasa xatolik qaytaradi.
MongoDB bizga strong consistency taklif qiladi ammo unda bir necha replicalar bor keling shuni qanday ishlashini ko'rib chiqamiz. MongoDBda siz faqatgina primary(asosiy) replicaga yoza olasiz , bu bizga yangilanishdagi conflictlarni oldini oladi va u to'g'ridan to'gri primary dbdan ma'lumotlarni o'qiydi bu bizga eng oxirgi ma’lumotlarni olishni imkonini beradi. Xo'sh unda bizga nega replicalar kerak , aslida siz secondary replicalardan ham ma'lumot o'qiy olasiz ammo bu oxirgi ma'lumotlar bo'lmasligi mumkin. Biz bu bilan readni osonlikcha _scale_ qilishimiz hamda shu paytning o'zida strong consistencyga ega _writega_ ega bo'lishimiz mumkin hamda replicalar xatoliklarga chidamliklini oshiradi (MongoDB avtomatik tarzda primary replicani o'zgartira oladi) .
MongoDB Tranzaksiyalarni faqatgina unda replicalar bo'lganida support qiladi.
Ba'zi dasturlarda tanlov bo'lmaydi ular strong consistency bo'lishi kerak masalan moliyaviy dasturlar.
Xulosa
Xulosa qilib aytadigan bo'lsak bizga avialability muhim bo'lsa biz eventual consistency ni tanlaganimiz yaxshi , ammo bizning dastur uchun consistency muhim rol o'ynasa unda strong consistency yaxshi tanlov hisoblanadi.
Agarda maqola yoqqan bo'lsa chapak chaling (ko'p chalsayam bo'ladi :).
Xato va kamchiliklar uchun uzr !!!
linkedin.com =>Ulug’bek Habibov | LinkedIn
telegram channel =>@habibov_ulugbek