5-bob: NoSQL tizimlari: MongoDB, Cassandra va Redis

Munosabatli ma’lumotlar bazalari TuranMart-ga mijozlar, mahsulotlar, buyurtmalar va to’lovlar uchun ishonchli yozuv tizimini berdi. Bu tizim hali ham muhim, ammo endi kompaniyaga kerak bo’lgan yagona saqlash tizimi emas. Mahsulot katalogi turli toifalar bo’ylab farq qiluvchi moslashuvchan mahsulot atributlariga xizmat qilishi kerak. Mobil ilova tahlilchilar mijoz, mahsulot, mintaqa va vaqt bo’yicha bo’laklarga ajratishni xohlaydigan katta hajmdagi xatti-harakatlar hodisalarini chiqaradi. Veb-saytga sessiyalar, savatchalar, xususiyat bayroqlari (feature flags) va mashhur katalog qismlari uchun past kechikishli kesh kerak. Agar jamoa barcha bu ish yuklarini bitta munosabatli sxemaga kiritishga harakat qilsa, u tez o’zgaruvchan yozuvlarni haddan tashqari normalizatsiya qiladi, operatsion ma’lumotlar bazasini ortiqcha yuklaydi yoki sekin foydalanuvchi tajribasini yaratadi.

Ushbu bob uchta ishlab chiqarish namunasi orqali NoSQL tizimlarini (NoSQL systems) taqdim etadi: hujjatga yo’naltirilgan mahsulot ma’lumotlari uchun MongoDB, so’rov birinchi o’rinda turadigan keng ustunli hodisalarni saqlash uchun Apache Cassandra va xotiradagi kesh hamda tezkor operatsion holat uchun Redis. Maqsad munosabatli fikrlashni almashtirish emas. Maqsad, ma’lumotlar muhandisi (data engineer) kirish namunasi, izchillik (consistency) talabi, kechikish (latency) maqsadi va operatsion xavf uchun to’g’ri saqlash modelini tanlashi uchun ikkinchi saqlash lug’atini qo’shishdir.

Kirish stsenariysi: TuranMartning saqlash bo’linishi¶

TuranMartning kassa tizimi endi 4-bobda ishlab chiqilgan munosabatli ma’lumotlar bazasida ishlaydi. Sxema buyurtmalar va to’lovlarni himoya qiladi, ammo xuddi shu chorakda uchta yangi talab kelib tushadi. Merchendayzing jamoasi poyabzal o’lchami, telefon xotirasi, mato, kafolat muddati va sotuvchi nishonlari kabi toifaga xos mahsulot atributlarini xohlaydi. Tahlil jamoasi huni tahlili uchun har bir mahsulot ko’rish va savatchaga qo’shish hodisasini saqlab qolishni xohlaydi. Platforma jamoasi kampaniya trafigi paytida bosh sahifa tavsiyalari va foydalanuvchi sessiyalari uchun tezroq o’qishlarni xohlaydi.

Bosh ma’lumotlar muhandisi ma’lumotlar bazasini modaga qarab tanlashdan bosh tortadi. Buning o’rniga, jamoa kirish namunalarini yozib chiqadi. Mahsulot sahifalari odatda bitta mahsulot hujjatini SKU bo’yicha oladi va barcha atributlarni birga ko’rsatadi. Hodisa so’rovlari odatda hodisalarni mijoz va vaqt oynasi bo’yicha o’qiydi yoki mahsulot faolligini kun bo’yicha yig’adi. Sessiyani o’qish millisekundlarda yakunlanishi kerak va kesh yo’qolgan taqdirda doimiy ombordan qayta tiklashga toqat qila oladi. Ushbu kuzatishlar saqlash bo’linishiga olib keladi: moslashuvchan katalog hujjatlari uchun MongoDB, ma’lum so’rovlar atrofida ishlab chiqilgan yuqori yozishli hodisalar jadvallari uchun Cassandra va kesh/sessiya holati uchun Redis.

Bo’linish moslashuvchanlik bilan birga mas’uliyatni ham kiritadi. NoSQL tizimi munosabatli cheklovlarni olib tashlashi mumkin, ammo u ma’lumotlar shartnomalariga (data contracts) bo’lgan ehtiyojni olib tashlamaydi. Hujjatlar to’plami hali ham tekshirish va indekslarga muhtoj. Cassandra jadvali hali ham so’rov birinchi o’rinda turadigan birlamchi kalitga (primary key) muhtoj. Redis keshi hali ham muddati o’tish, bekor qilish va tiklash qoidalariga muhtoj. Ishlab chiqarishdagi ma’lumotlar muhandisligida, NoSQL ish yukiga xos atayin modellashtirishni anglatadi, sxemasiz improvizatsiyani emas.

O’quv maqsadlari¶

Ushbu bobni tugatgandan so’ng, siz qachon NoSQL tizimi mos kelishini, MongoDB, Cassandra va Redis qanday farq qilishini va ularni boshqariladigan ma’lumotlar platformasiga qanday integratsiya qilishni tushuntira olishingiz kerak.

5.1 Nima uchun NoSQL mavjud¶

NoSQL tizimlari ommalashdi, chunki veb-miqyosidagi ilovalar har doim ham bitta munosabatli dizaynga mos kelmaydigan ish yuklarini ochib berdi. Ba’zi yozuvlar tabiiy ravishda iyerarxik edi. Ba’zi yozish yo’llari bitta asosiy ma’lumotlar bazasi uchun juda ko’p hodisalarni keltirib chiqardi. Ba’zi foydalanish holatlari global taqsimotni, sozlanishi mumkin bo’lgan replikatsiyani yoki oddiy kalit qidirishlari uchun juda past kechikishni talab qildi. Shuning uchun NoSQL iborasi bitta arxitektura sifatida emas, balki munosabatli bo’lmagan saqlash modellari oilasi sifatida tushunilishi eng yaxshisidir.

Ta’rif. Ushbu kitobda NoSQL tizimi ma’lum bir kirish namunasini, miqyoslash namunasini, mavjudlik maqsadini, ma’lumotlar shaklini yoki kechikish talabini optimallashtirish uchun ba’zi munosabatli taxminlarni yumshatuvchi ish yukiga xos ma’lumotlar omboridir.

“Yumshatadi” so’zi muhim. MongoDB, Cassandra va Redis tuzilmani yo’q qilmaydi. MongoDB hujjatlari JSON-ga o’xshash BSON yozuvlari bo’lib, ular ilova darajasidagi sxema (schema) qoidalariga rioya qilishi kerak. Cassandra jadvallari ehtiyotkorlik bilan bo’lim kaliti va klasterlash kaliti dizaynini talab qiladi. Redis satrlar, xeshlar, ro’yxatlar, to’plamlar, tartiblangan to’plamlar va oqimlar kabi turlangan qiymatlarni saqlaydi. Professional ma’lumotlar muhandisi bu tizimlarga modellashtirish intizomi yo’qoladigan joy sifatida emas, balki turli xil shartnoma mexanizmlari sifatida qaraydi.

NoSQL qarorlari kirish namunalaridan boshlanishi kerak. Mahsulotni tanlashdan oldin, ilova yoki quvur nima o’qishi va yozishini, qancha ma’lumot ishtirok etishini, izchillik talabi qanchalik qat’iyligini, tarmoq bo’linishi paytida nima sodir bo’lishini va nosozlikdan keyin operatorlar qanday tiklanishini so’rang. Mashhurlik va bulutdagi mavjudlik faqat shu savollarga javob berilgandan keyingina foydali filtrlardir.

5.2 NoSQL modelini tanlash¶

Turli NoSQL tizimlari turli jismoniy va operatsion realliklarni optimallashtiradi. MongoDB ichki o’rnatilgan mahsulot atributlarini ifodalashi mumkin bo’lgan hujjatlarni saqlaydi. Cassandra bo’lim kalitlari yordamida qatorlarni klaster bo’ylab taqsimlaydi va so’rov modeli oldindan ma’lum bo’lganda yuqori mavjudlik va kengaytiriladigan yozishlar uchun mo’ljallangan. Redis tez-tez kiriladigan holatni xotirada saqlaydi va tezkor operatsion ish jarayonlari uchun maxsus yaratilgan ma’lumotlar tuzilmalarini taklif qiladi.

Foydali tanlash jarayoni besh bosqichdan iborat. Birinchidan, biznes hodisasi yoki obyektini nomlang. Ikkinchidan, ilova yoki quvur bajarishi kerak bo’lgan aniq o’qish va yozishlarni yozing. Uchinchidan, nosozlik rejimini tavsiflang: eskirgan o’qishlar, takroriy yozishlar, yo’qolgan kesh yozuvlari va kechiktirilgan yarashish turli xil biznes xarajatlariga ega. To’rtinchidan, doimiy haqiqatga qaysi tizim egalik qilishini hal qiling. Beshinchidan, ma’lumotlar operatsion saqlashdan ko’lga, omborga yoki lakehouse’ga (lakehouse) qanday o’tishini hujjatlashtiring.

Tanlov tashkiliy imkoniyatlarni ham tan olishi kerak. Taqsimlangan ma’lumotlar bazasini boshqara olmaydigan jamoa, agar miqyos va mavjudlik talablari buni oqlamasa, Cassandra-ni joriy etishdan qochishi kerak. Kesh kuzatuvchanligi bo’lmagan jamoa zaxira variantlarisiz muhim biznes mantig’ini Redis-ga joylashtirmasligi kerak. Arxitektura nafaqat texnologiya mosligi; bu operatsion yetuklik haqida hamdir.

5.3 Moslashuvchan mahsulot hujjatlari uchun MongoDB¶

MongoDB hujjat ma’lumotlar bazasidir. Uning ma’lumotlarni modellashtirish bo’yicha qo’llanmasi hujjatlar ilovaga kirish namunalari atrofida ishlab chiqilishi kerakligini, tegishli ma’lumotlar ko’pincha birga o’qilganda ichki o’rnatilishi va ma’lumotlar mustaqil ravishda o’zgarganda yoki ortiqcha takrorlanishga olib kelganda havola qilinishi kerakligini ta’kidlaydi.^[1] Bu munosabatli normalizatsiyadan boshqacha boshlang’ich nuqtadir. MongoDB-da modellashtirish birligi ko’pincha ilova olmoqchi yoki yangilamoqchi bo’lgan agregat hujjatdir.

TuranMart uchun mahsulot sahifasi odatda bitta o’qishda mahsulot identifikatori, nomi, toifasi, narxi, sotuvchisi, atributlari, rasmlari va kichik merchendayzing nishonlariga muhtoj. Hujjat modeli bu shaklni tabiiy ravishda ifodalashi mumkin:

{
  "sku": "TM-PHONE-001",
  "title": "Samarkand X5 Smartphone",
  "category": "electronics",
  "price": { "amount": 349.00, "currency": "USD" },
  "attributes": {
    "memory_gb": 128,
    "color": "midnight blue",
    "warranty_months": 24
  },
  "seller": { "seller_id": "seller_17", "name": "Turan Mobile" },
  "status": "active",
  "updated_at": "2026-05-01T10:00:00Z"
}

5.3.1 Ichki o’rnatish va havola qilish¶

Bolalar ma’lumotlari ota-onaning hayot aylanishiga tegishli bo’lsa va u bilan tez-tez o’qilsa, ichki o’rnatish mos keladi. Mahsulot atributlari, rasm metama’lumotlari va kichik nishonlar yaxshi nomzodlardir, chunki sahifa ularni birga ko’rsatadi. Havola qilish tegishli obyekt mustaqil ravishda o’zgarganda, ko’plab hujjatlar tomonidan baham ko’rilganda yoki oldindan aytib bo’lmaydigan darajada o’sganda mos keladi. Sotuvchi hisobi tafsilotlari, inventar zaxiralari, to’lovlar va jo’natish holati odatda o’zlarining operatsion tizimlarida qolishi kerak.

Hujjatlarni modellashtirish indeks intizomini ham talab qiladi. MongoDB indekslari samarali so’rovlarni bajarishni qo’llab-quvvatlaydi, ammo har bir indeks yozish va saqlash xarajatlariga ega.^[2] TuranMart aniq mahsulotni qidirish uchun sku ni, kataloglarni ko’rib chiqish uchun category va status ni va ehtimol umumiy filtrlar bo’lgan tanlangan atributlarni indekslashi kerak. U har bir ichki o’rnatilgan maydonni avtomatik ravishda indekslamasligi kerak, chunki hujjat modeli bunga ruxsat beradi.

5.3.2 Sxemani tekshirish va siljish¶

MongoDB-ning moslashuvchan hujjat modeli foydalidir, ammo moslashuvchanlik siljishga aylanishi mumkin. Xuddi shu tushuncha uchun memory_gb, memoryGB, memory va ram_size ni saqlaydigan mahsulot to’plami oxir-oqibat qidiruv, tahlil va qo’llab-quvvatlash vositalariga zarar yetkazadi. Ma’lumotlar muhandisligi jamoasi hujjat shartnomasini nashr etishi, kerakli maydonlarni tekshirishi va munosabatli migratsiyalarni qanday ehtiyotkorlik bilan kuzatsa, sxema evolyutsiyasini (schema evolution) ham shunday ehtiyotkorlik bilan kuzatishi kerak.

Amaliy namuna - har bir mahsulot uchun kichik kerakli yadroni aniqlash va attributes ostida toifaga xos kengaytmalarga ruxsat berish. Keyin quyi oqim quvurlari sku, category, status, price.amount, price.currency va updated_at ga tayanishi mumkin, ixtisoslashtirilgan transformatsiyalar esa toifa darajasidagi maydonlarni ko’rib chiqadi.

5.4 So’rov birinchi o’rinda turadigan hodisalarni saqlash uchun Cassandra¶

Apache Cassandra tugunlar bo’ylab yuqori mavjudlik va kengaytiriladigan yozishlar uchun mo’ljallangan taqsimlangan keng ustunli ma’lumotlar bazasidir. Uning ma’lumotlarni modellashtirish hujjatlarida aytilishicha, Cassandra modellashtirishi normalizatsiya qilingan obyekt modelidan emas, balki ilova so’rovlaridan boshlanadi.^[3] Bu qoida ixtiyoriy emas. Cassandra ixtiyoriy jadvallar bo’ylab maxsus qo’shilishlarni rag’batlantirmaydi. Buning o’rniga, muhandis birlamchi kalitlari ilova bajarishi kerak bo’lgan o’qishlarga mos keladigan jadvallarni yaratadi.

TuranMart-ning hodisalar platformasi kamida ikkita kirish namunasiga muhtoj. Mijozlarni qo’llab-quvvatlash xizmati mijozning so’nggi mahsulot ko’rishlari va savatcha harakatlarini tekshirishni xohlaydi. Mahsulot menejerlari mahsulot uchun kunlik faollikni xohlaydi. Munosabatli dizayner bitta normalizatsiya qilingan events jadvalini yaratishi va indekslar har bir so’rovni hal qilishini kutishi mumkin. Cassandra dizayneri so’rovga xos jadvallarni yaratadi.

CREATE TABLE events_by_customer_day (
  customer_id text,
  event_day date,
  event_ts timestamp,
  event_id uuid,
  event_type text,
  product_sku text,
  region text,
  PRIMARY KEY ((customer_id, event_day), event_ts, event_id)
) WITH CLUSTERING ORDER BY (event_ts DESC, event_id ASC);

CREATE TABLE events_by_product_day (
  product_sku text,
  event_day date,
  event_ts timestamp,
  event_id uuid,
  event_type text,
  customer_id text,
  region text,
  PRIMARY KEY ((product_sku, event_day), event_ts, event_id)
) WITH CLUSTERING ORDER BY (event_ts DESC, event_id ASC);

5.4.1 Bo’lim kalitlari va klasterlash kalitlari¶

Bo’lim kaliti ma’lumotlarning klasterda qayerga joylashtirilishini belgilaydi. Klasterlash kalitlari bo’lim (partition) ichidagi tartiblash tartibini belgilaydi. Yaxshi Cassandra jadvali ikkita kuchni muvozanatlaydi: bo’limlar issiq nuqtalarning oldini olish uchun yetarlicha tor va samarali oraliq o’qishlarni qo’llab-quvvatlash uchun yetarlicha keng bo’lishi kerak. Hodisa ma’lumotlari uchun keng tarqalgan namuna ob’ekt identifikatorini (customer_id, event_day) yoki (product_sku, event_day) kabi vaqt chelagi bilan birlashtirishdir.

Xarajat takrorlanishdir. Xuddi shu mantiqiy hodisa bir nechta Cassandra jadvallariga yozilishi mumkin. Bu faqat yutish (ingestion) idempotent bo’lsa, hodisa identifikatorlari barqaror bo’lsa va yarashish vazifalari yetishmayotgan yoki mos kelmaydigan qatorlarni aniqlay olsa maqbuldir. Cassandra aniq so’rov dizaynini mukofotlaydi va noaniq “hozir saqla, keyinroq so’ra” fikrlashini jazolaydi.

5.4.2 Izchillik va mavjudlik¶

Cassandra sozlanishi izchillikni taklif qiladi. Amalda, jamoa kechikish, mavjudlik va to’g’rilik ehtiyojlariga asoslanib o’qish va yozish izchillik darajalarini tanlaydi. Mahsulotni ko’rish hodisasi odatda oxir-oqibat izchillikka toqat qila oladi, chunki kechiktirilgan tahliliy hisob yo’qolgan to’lov bilan bir xil emas. Kassadagi to’lov faqat Cassandra yozishlari yaxshi miqyoslanganligi sababli munosabatli ma’lumotlar bazasidan Cassandra-ga o’tkazilmasligi kerak.

CAP teoremasi (CAP Theorem) ko’pincha juda tasodifiy umumlashtiriladi. Brewer-ning CAP doirasi nima uchun tarmoq bo’linishi ostidagi taqsimlangan tizim (distributed system) mavjudlik va izchillik o’rtasida murosaviy yechimlarni amalga oshirishi kerakligini tushuntiradi.^[4] Ma’lumotlar muhandislari uchun amaliy saboq “CP” yoki “AP” kabi shiorlarni yodlash emas. Saboq shundaki, biznes har bir ish yuki uchun qanday eskirgan, kechiktirilgan, takroriy yoki mavjud bo’lmagan xatti-harakatlarga toqat qila olishini so’rashdir.

5.5 Kesh, sessiyalar va tezkor holat uchun Redis¶

Redis - bu xotiradagi ma’lumotlar tuzilmasi serveri bo’lib, odatda keshlash, sessiyalarni saqlash, navbatlar, hisoblagichlar, peshqadamlar ro’yxati, tarif cheklovlari va qisqa muddatli muvofiqlashtirish holati uchun ishlatiladi. Uning hujjatlari satrlar, xeshlar, ro’yxatlar, to’plamlar, tartiblangan to’plamlar, oqimlar va ehtimollik tuzilmalari kabi Redis ma’lumotlar turlarini bitta umumiy blob ombori sifatida emas, balki birinchi darajali modellashtirish vositalari sifatida taqdim etadi.^[5]

TuranMart uchun Redis yozuv tizimiga aylanmasdan kechikishni yaxshilashi mumkin. Mahsulot qismlari MongoDB o’qishlaridan keyin keshlashi mumkin. Sessiya holati TTL (yashash vaqti) bilan saqlanishi mumkin. Savatchani oldindan ko’rish, agar kerak bo’lsa, doimiy kassa tizimidan qayta tiklanishi mumkin. Kampaniya hisoblagichlari Redis-da saqlanishi va vaqti-vaqti bilan tahliliy xotiraga yozilishi mumkin.

5.5.1 Ma’lumotlar tuzilmalari va TTLlar¶

Redis dizayni kalit nomlari, qiymat turlari, muddati o’tish qoidalari va qayta qurish yo’llaridan boshlanadi. Sessiya 30 daqiqalik TTL bilan session:{session_id} da xeshdan foydalanishi mumkin. Mahsulot qismi qisqa TTL bilan product:summary:{sku} kabi satr kalitidan foydalanishi mumkin. Kampaniya peshqadamlar ro’yxati tartiblangan to’plamdan foydalanishi mumkin. Oqim iste’molchi ularni to’kib tashlashidan oldin yengil hodisalarni buferlashi mumkin.

Redis-ning doimiylik variantlari ma’lumotlarni ma’lum vaqtdagi snapshotlar, faqat qo’shiladigan fayllar yoki ikkalasining kombinatsiyasi orqali diskka yozishi mumkin.^[6] Doimiylik tiklanishni yaxshilaydi, ammo u har bir kesh dizaynini xavfsiz yozuv tizimiga aylantirmaydi. Jamoa hali ham Redis kalitni yo’qotsa, qayta ishga tushsa, xotirani chiqarib tashlasa yoki eskirgan ma’lumotlarga xizmat qilsa nima bo’lishini aniqlashi kerak.

5.5.2 Kesh-yonida va bekor qilish¶

Ilova ma’lumotlar platformalaridagi eng keng tarqalgan namuna bu kesh-yonida (cache-aside) namunasidir. Ilova birinchi navbatda Redis-ni tekshiradi. O’tkazib yuborilganda, u doimiy ombordan o’qiydi, TTL bilan keshlangan tasvirni yozadi va natijani qaytaradi. Yangilashda ilova kesh kalitini o’chiradi yoki yangi qiymat yozadi. Bu namuna oddiy, ammo u intizomni talab qiladi. Agar yangilash yo’li keshni bekor qilishni untsa, ma’lumotlar bazasi to’g’ri bo’lsa ham foydalanuvchilar eskirgan katalog ma’lumotlarini ko’rishlari mumkin.

Ma’lumotlar muhandislari kesh xatti-harakati haqida qayg’uradilar, chunki keshni o’tkazib yuborishlar, eskirgan qiymatlar va chiqarib tashlashlar quyi oqimda kechikish cho’qqilari, takrorlangan hodisalar yoki chalkash tahlillar sifatida namoyon bo’ladi. Ishlab chiqarish jamoalari hit rate, xotiradan foydalanish, chiqarib tashlashlar soni, kalit kardinalligi va qayta qurish kechikishini kuzatishlari kerak.

5.6 Izchillik, replikatsiya va nosozlik haqida fikr yuritish¶

NoSQL tizimlari ko’pincha munosabatli ma’lumotlar bazalari bitta standart konfiguratsiya orqasida yashiradigan murosaviy yechimlarni aniq muhandislik tanlovlariga o’tkazadi. MongoDB replika to’plamlari yuqori mavjudlik uchun ma’lumotlarni replikatsiya qiladi. Cassandra ma’lumotlarni tugunlar bo’ylab taqsimlaydi va sozlanishi izchillikni qo’llab-quvvatlaydi. Redis replikatsiya qilishi, doimiy saqlashi va klasterlashi mumkin, ammo ko’plab o’rnatishlar undan asosan past kechikishli o’zgaruvchan holat uchun foydalanadi. Har bir tanlov “yozish muvaffaqiyatli bo’ldi”, “o’qish joriy” va “ma’lumotlarni tiklash mumkin” degan ma’nolarni o’zgartiradi.

Shuning uchun kuchli ma’lumotlar platformasi egalik huquqini qayd etadi. PostgreSQL buyurtmalar va to’lovlarga egalik qiladi. MongoDB moslashuvchan katalog hujjatlariga egalik qiladi. Cassandra doimiy hodisalarni yutish yo’lidan oziqlanadigan, so’rov uchun optimallashtirilgan hodisalar proyeksiyalariga egalik qiladi. Redis qayta qurilishi mumkin bo’lgan issiq hosil qilingan holatga egalik qiladi. Egalik noaniq bo’lganda, hodisalar muhandislik tiklanishlari emas, balki siyosiy tortishuvlarga aylanadi.

5.7 Ma’lumotlar muhandisligi platformasida NoSQL¶

NoSQL tizimlari kamdan-kam hollarda yolg’iz yashaydi. Ular quvurlarni oziqlantiradi va ulardan oziqlanadi. MongoDB mahsulot o’zgarishlari tahlil qilish uchun ob’ektli saqlash (object storage) yoki lakehouse-ga ushlanishi mumkin. Cassandra hodisalar jadvallari Kafka mavzularidan yaratilishi va kunlik Parquet fayllariga zichlashtirilishi mumkin. Redis hisoblagichlari hisobot berish uchun vaqti-vaqti bilan doimiy xotiraga yuvilishi mumkin. Ushbu oqimlar boshqaruv talablarini yaratadi: sxema shartnomalari, kelib chiqish (lineage), kirishni boshqarish, saqlash qoidalari va sifat tekshiruvlari.

Amaliy boshqaruv namunasi - har bir yangi ma’lumotlar bazasi uchun saqlash qarori yozuvini nashr etish. Yozuv ish yuki, egasi, kirish namunalari, ma’lumotlar shartnomasi, saqlash qoidasi, zaxira yoki qayta qurish yo’li, monitoring signallari va quyi oqim iste’molchilarini nomlashi kerak. Ushbu intizom jamoa tezlik uchun NoSQL tizimini joriy qiladigan va kelajakdagi ma’lumotlar muhandislariga ma’lumotlar nimani anglatishini teskari muhandislik qilishni qoldiradigan keng tarqalgan anti-namunaning oldini oladi.

5.8 Amaliy laboratoriya: Mahsulot katalogi, hodisalar jadvallari va kesh qatlami¶

Ushbu bob uchun amaliy laboratoriya shared/labs/ch05_nosql_systems da saqlanadi. U sizga uchta bog’liq saqlash vazifasi uchun deterministik boshlang’ich aktivlarni beradi: MongoDB mahsulot katalogi, Cassandra so’rov birinchi o’rinda turadigan hodisalar jadvallari va Redis kesh/sessiya kalitlari. Laboratoriya qasddan og’ir xizmatlarni ishga tushirmasdan tekshirish uchun yetarlicha kichik, ammo amaliy mahalliy tajriba o’tkazmoqchi bo’lgan jamoalar uchun Docker Compose faylini ham o’z ichiga oladi.

5.8.1 Laboratoriya maqsadi¶

Laboratoriya oxiriga kelib, siz TuranMart-ning saqlash talablarini aniq NoSQL modellariga xaritalagan bo’lasiz. Siz mahsulot hujjatlarini yuklaysiz yoki tekshirasiz, ikkita hodisaga kirish namunasi uchun Cassandra jadvallarini yaratasiz, TTL-lar bilan Redis kesh kalitlarini aniqlaysiz va kutilgan natijalar boshlang’ich ma’lumotlarga mos kelishini tekshirasiz.

5.8.2 Laboratoriya fayllari¶

5.8.3 Tez boshlash¶

Repozitoriy ildizidan, birinchi navbatda xizmatlarni ishga tushirmasdan laboratoriya paketini tekshiring:

python shared/labs/ch05_nosql_systems/tests/validate_lab_assets.py

Agar Docker mavjud bo’lsa va siz xizmatlar bilan tajriba o’tkazmoqchi bo’lsangiz, ularni quyidagi bilan ishga tushiring:

docker compose -f shared/labs/ch05_nosql_systems/docker-compose.yml up -d

Keyin uchta ish yuki modelini tekshiring. MongoDB skripti mahsulot hujjati shartnomasi va indekslarini belgilaydi. Cassandra CQL fayli mijoz va mahsulot bo’yicha hodisalar uchun so’rovga xos jadvallarni yaratadi. Redis buyruq fayli sessiya xeshlarini, mahsulot xulosasini keshlashni, TTL-larni va hisoblagichlarni namoyish etadi.

5.8.4 Kutilgan natija¶

Tekshiruvchi quyidagiga o’xshash deterministik muvaffaqiyat xulosasini chop etishi kerak:

Chapter 5 lab validation passed.
Products: 5
Events: 12
Product-day rows: 7
Redis TTL examples: 3

5.8.5 Tugatish nazorat ro’yxati¶

5.8.6 Tozalash¶

Docker-ga asoslangan ishga tushirishni tugatgandan so’ng, xizmatlarni to’xtating va mahalliy ish vaqti holatini olib tashlang:

docker compose -f shared/labs/ch05_nosql_systems/docker-compose.yml down -v

Umumiy xatolar va operatsion saboqlar¶

Birinchi xato NoSQL-ga modellashtirishdan qochish uchun bahona sifatida munosabatda bo’lishdir. Moslashuvchan hujjatlar hali ham shartnomalarga muhtoj. Cassandra hali ham so’rovga xos jadvallarga muhtoj. Redis hali ham kalit dizayniga muhtoj. Munosabatli sxemaning yo’qligi mas’uliyatni olib tashlamaydi; u mas’uliyatni ilova shartnomalariga, tekshirish qoidalariga va operatsion amaliyotga o’tkazadi.

Ikkinchi xato har bir ish yuki uchun bitta ma’lumotlar bazasidan foydalanishdir. MongoDB hodisalarni saqlashi mumkin, Cassandra profilga o’xshash qatorlarni saqlashi mumkin va Redis JSON satrlarini ushlab turishi mumkin, ammo qobiliyat moslikka teng emas. To’g’ri savol “Bu ma’lumotlar bazasi ma’lumotlarni saqlay oladimi?” emas, balki “Bu ma’lumotlar bazasi kirish namunasiga xavfsiz va ishlaydigan tarzda xizmat qila oladimi?”.

Uchinchi xato qayta qurish yo’llarini e’tiborsiz qoldirishdir. Qayta qurish yo’lisiz kesh yashirin yozuv tizimiga aylanadi. Qayta o’ynashsiz takrorlangan Cassandra proyeksiyasi yarashish muammosiga aylanadi. Eksportsiz hujjatlar to’plami tahliliy ko’r nuqtaga aylanadi. Har bir NoSQL dizayni “Agar bu ombor ishdan chiqsa, siz ... orqali tiklaysiz” iborasini o’z ichiga olishi kerak.

Laboratoriya materiallari¶

Mashqlar¶

1. MongoDB mahsulot modelini reviews_summary maydoni bilan kengaytiring. To’liq sharhlar ichki o’rnatilishi yoki havola qilinishi kerakligini hal qiling va tanlovingizni asoslang.

2. events_by_region_day uchun Cassandra jadvalini qo’shing. Bo’lim kaliti va klasterlash kalitlarini tanlang, so’ngra milliy kampaniya paytida issiq bo’limning qanday oldini olishingizni tushuntiring.

3. Savatchani oldindan ko’rish uchun Redis kalitlarini loyihalang. Kalit nomlari, ma’lumotlar tuzilmalari, TTL-lar va kassadan keyingi bekor qilish qoidalarini kiriting.

4. price.currency yetishmayotgan mahsulot hujjatlarini yoki noma’lum product_sku ga ega hodisalarni aniqlaydigan ma’lumotlar sifati (data quality) tekshiruvini yozing.

5. Mahsulot atributlari uchun munosabatli va hujjat modelini solishtiring. MongoDB-da osonlashadigan bitta so’rovni va qiyinlashadigan bitta boshqaruv vazifasini aniqlang.

Ko’rib chiqish savollari¶

Xulosa¶

NoSQL tizimlari munosabatli ma’lumotlar bazalarini almashtirish emas. Ular turli xil ish yuki muammolarini hal qiladigan ixtisoslashtirilgan saqlash modellari to’plamidir. Yozuvlar tabiiy ravishda hujjat shaklida bo’lganda va agregat sifatida o’qilganda MongoDB yordam beradi. Yuqori hajmli taqsimlangan yozishlar ma’lum so’rov namunalarini qo’llab-quvvatlashi kerak bo’lganda Cassandra yordam beradi. Issiq operatsion holatga juda past kechikish bilan xizmat ko’rsatish kerak bo’lganda va uning muddati o’tishi, bekor qilinishi yoki qayta qurilishi mumkin bo’lganda Redis yordam beradi.

Professional odat birinchi navbatda ish yukini modellashtirishdir. Texnologiyani tanlashdan oldin kirish namunasi, izchillik kutilishi, egalik chegarasi, tiklash yo’li va quyi oqim integratsiyasini aniqlang. NoSQL tizimlari ushbu intizom bilan joriy etilganda, ular boshqarilmaydigan murakkablik manbai emas, balki ma’lumotlar muhandisligi platformasining kuchli qismiga aylanadi.

Adabiyotlar¶