Katta Loyihalar Siri: Database Middleware

Hech o'ylab ko'rganmisiz, dasturingizga millionlab foydalanuvchilar oqib kirdi, DBingizga so'rovlar soni keskin ko'tarilib ketdi. Natijada dasturingiz sekin ishlayapti. CPU, RAM va diskingizdagi IO juda ko'tarilib ketgan. Bazangiz qulab tushdi, endi butun servisingiz to'xtab qoldi.
Nega Amazon, Netflixlar o'tirib qolmayapti, ularning ham million foydalanuvchisi borku, deyapsiz.

Gap shundaki, ularning barcha so'rovlari bitta joyga yuborilmaydi va bitta baza hamma ishni bajarmaydi. Ular odatda bazaga yuklamani (load) taqsimlashadi.

Asosiy Muammo: Write vs. Read

Baza bilan ishlashda ikki turdagi operatsiya bor:
Write: Yangi ma'lumot qo'shish, mavjud ma'lumotni o'zgartirish yoki o'chirish. Masalan, buyurtma berish, profilni yangilash, nimadirni o'zgartirish. Bu operatsiyalar bazaning ishlashiga kuchliroq ta'sir qiladi.

Read: Ma'lumotlarni shunchaki ko'rish. Masalan, mahsulot ro'yxatini yoki buyurtmalar tarixini ko'rish. Odatda, dasturlarda "Read" so'rovlari "Write" so'rovlaridan ancha ko'p bo'ladi.

Bitta bazaga ham "write", ham "read" so'rovlari kelaversa, baza ikkita vazifani birdan bajarishga qiynaladi va sekinlashadi. Bu xuddi soat 19:00 da Havasga kirsangiz, kassada bitta kassir ham mahsulotlarni skanerdan o'tkazishi, ham borib tovarlarni sortirovka qip kelishi, ham narxlar haqidagi savollarga javob berib o'tirishga ulgurmay qolganiga o'xshaydi.

Yechim: Read Replica Pattern

Bunday muammoni hal qilish uchun odatda Read Replica modelidan foydalaniladi.

Primary DB: Asosiy baza faqatgina "write" operatsiyalari uchun ajratiladi. U "write" ishlari bilan band bo'ladi.

Secondary DB (Replica): Asosiy bazani nusxalarini saqlaydi. Ular faqat "read" operatsiyalari uchun xizmat qiladi.

Replikatsiya (Replication): Primary DBga yozilgan har qanday yangi ma'lumot avtomatik ravishda barcha Secondary DB'larga nusxalanadi.

Bu model loadni taqsimlanishiga moslangan. Write so'rovlari asosiy bazaga, minglab-millionlab bo'lgan Read so'rovlari endi nusxalangan bazalarga borishni boshlaydi.

Kodda, mijoz buyurtma bersa Primary DBga yoz, buyurtma tarixini yoki narxni ko'rmoqchi bo'lsa Secondary DBga to'g'irla deb chiqish juda noqulay va kodni murakkablashtiradi. Aynan shu yerda Database Middleware ishlatiladi.

U huddi agentga o'xshab, dasturingiz va bazalaringiz o'rtasida turadi. Dasturingiz endi faqat Middlewarega murojaat qiladi, u esa so'rov turini tahlil qilib avtomatik tarzda to'g'ri bazaga yo'naltiradi.

Misol uchun, buyurtma berish bu write so'rovi, middleware uni Primary DB ga yo'naltiradi. Buyurtma tarixini ko'rish bu read so'rovi. Middleware uni so'rovlari kam bo'lgan Secondary DBlardan biriga yo'naltiradi. Bu usul dastur kodini soddalashtirib, databaseni boshqarishni soddalashtiradi.

Lekin buni kamchiliklariyam bor:

Database Middlewarening o'zi ham alohida, murakkab tizim. Uni sozlash (configuration) va doimiy monitoring qilish kerak. Noto'g'ri sozlansa, butun tizim ishdan chiqishi mumkin.
Barcha baza so'rovlari middleware orqali o'tganligi sababli, agar u qulasa, barcha DB'ga ulanish to'xtaydi. Shuning uchun, uni high availabilitysini qilishga klaster qilib o'rnatilishi shart. Bu esa o'z-o'zidan qo'shimcha resurs va xarajat degani.

@mabrur_dev