Ishonchli ma’lumot mahsulotlari ishonchli yozuvlardan boshlanadi. Lakehouse mijoz xatti-harakatlarini model qila boshlashidan oldin, oqimli platforma hodisalarni e’lon qilishdan oldin, va tahliliy Boshqaruv paneli (Dashboard) daromadni tushuntirishdan oldin, kimdir biznes yozuvlari qanday yaratilishi, tekshirilishi, so’rov qilinishi, o’zgartirilishi, Zaxira nusxa (Backup) qilib olinishi va Tiklash (Restore) haqida qaror qabul qilishi kerak. Munosabatli ma’lumotlar bazalari bu ish uchun standart asos bo’lib qoladi, chunki ular aniq ma’lumotlar modeli, yetuk so’rov tili, Tranzaksiya (Transaction) kafolatlari va o’nlab yillik operatsion amaliyotni birlashtiradi.
Bu bob I qism asoslaridan II qismning saqlash tizimlariga o‘tadi. Siz PostgreSQL va MySQLni raqobatdosh brendlar sifatida emas, balki munosabat g’oyasining ikki ishlab chiqarish darajasidagi amalga oshirilishi sifatida ishlatasiz. Bob oxiriga kelib, siz kichik operatsion Sxema (Schema)ni loyihalashni, Birlamchi kalit (Primary key), Tashqi kalit (Foreign key) va Cheklov (Constraint)lar haqida mulohaza yuritishni, oddiy So’rov rejasi (Query plan)ni o’qishni, Indeks (Index)larni intizom bilan tanlashni, nazorat ostidagi Migratsiya (Migration)ni amalga oshirishni va nima uchun Zaxira nusxa / Tiklash sinovlari Ma’lumotlar muhandisligi (data engineering)ning bir qismi ekanligini tushuntira olasiz.
Ochilish ssenariysi: TuranMartning to’lovni yakunlash (checkout) muammosi¶
TuranMart, bizning tasavvuriy mintaqaviy e‑commerce kompaniyamiz, jadval fayllar va ilova loglarining yetarli bo’lmagan holatiga yetib keldi. Mobil ilova Toshkent, Samarqand, Buxoro va Farg’ona shaharlaridan buyurtmalarni qabul qiladi. Mijozlar to’lovdan so’ng darhol to’lovni tasdiqlashni kutishadi. Moliya bo’limi har bir hudud bo’yicha kunlik daromadni kutadi. Operatsiyalar bo’limi kutayotgan, yakunlangan, jo’natilgan yoki bekor qilingan buyurtmalar ro’yxatini kutadi. Marketing qaysi ro’yxatdan o’tish kanallari eng qimmatbaho mijozlarni olib kelishini bilmoqchi.
Jamoaning birinchi instinkti har bir bosishni analitika platformasiga oqim orqali yuborishdir. Bu keyinchalik foydali bo’ladi, lekin hozirgi biznes xavfini hal qilmaydi. TuranMart avvalo yozuv tizimi (system of record)ga muhtoj. To’lovni yakunlash xizmati mijoz mavjudligini, mahsulotlar faol ekanligini, buyurtmada kamida bitta item borligini, umumiy summa manfiy emasligini, to’lov ushlab qolinganligini va ma’lumotlar bazasi nosozlikdan keyin tiklanishi mumkinligini bilishi kerak. Bu faqat analitika savollari emas; bu operatsion yaxlitlik savollari.
Figure 1:4-bob Munosabatli modellashtirish (relational modeling), Tranzaksiya (transactions), Indeks (indexing), Migratsiya (migrations) va Tiklash (recovery)ni TuranMartning buyurtma tizimi uchun bitta operatsion ish jarayoniga birlashtiradi.
Arxitektura darsi sodda, lekin muhim. Ma’lumotlar ko’li (data lake) tarixiy faktlarni saqlaydi, ma’lumotlar ombori (data warehouse) analitik so’rovlarga xizmat qiladi, va oqimni qayta ishlovchi (stream processor) voqealarga javob beradi, lekin Munosabatli ma’lumotlar bazasi ko’pincha biznes nima haqiqat ekanligini birinchi belgilaydigan joy bo’lib qoladi. Agar buyurtmalar bazasi mumkin bo’lmagan ma’lumotlarni qabul qilsa, har bir keyingi tizim shu adashuvni meros qilib oladi.
O’rganish maqsadlari¶
Bu bobni tugatgandan so’ng, siz Munosabatli ma’lumotlar bazasi (Relational database) nima uchun ishlab chiqarish ma’lumot platformalarida markaziy ahamiyatga ega ekanligini va ularning kafolatlari faylga asoslangan saqlash, hujjat saqlash tizimlari va analitik dvigatellardan qanday farq qilishini tushuntirib bera olishingiz kerak.
| Maqsad | Amaliyotda nima qila olishingiz kerak |
|---|---|
| Munosabatli ma’lumotlarni model qilish | Biznes obyektlarini jadvallar, birlamchi kalit (Primary key), tashqi kalit (Foreign key), cheklovlar (Constraint) va munosabat naqshlariga o‘tkazish. |
| PostgreSQL va MySQLni solishtirish | PostgreSQL va MySQLning operatsion kuchli tomonlarini tushuntiring, qarorni faqat mashhurlik yoki odatga kamaytirmasdan. |
| Tranzaksiyalarni to’g’ri ishlatish | Atomarlik, izchillik (Consistency), izolyatsiya va chidamlilikni (ACID — atomarlik, izchillik, izolyatsiya, chidamlilik) ta’riflang va tranzaksiya (Transaction) chegaralari ilova ish oqimida qayerda bo‘lishi kerakligini aniqlang. |
| Mas’uliyat bilan optimallashtirish | Asosiy EXPLAIN chiqishini o’qing, foydali indekslarni (Index) tanlang va har bir ustunni indekslash kabi keng tarqalgan xatodan saqlaning. |
| Sxema o’zgarishini boshqarish | Nazorat ostida kichik bir migratsiyani (Migration) qo’llang va nima uchun migratsiyalar ko’rib chiqish, test qilish va qaytarish rejasini talab qilishini tushuning. |
| Tiklashni amaliyotda o’tkazish | Mantiqiy zaxira nusxalari (zaxira nusxa (Backup)), tiklash tekshiruvlari (tiklash (Restore)) va tiklash maqsadlarini — Tiklash nuqtasi maqsadi (RPO) va Tiklash vaqti maqsadi (RTO) — biznes uzluksizligiga bog’lang. |
4.1 Nima uchun Munosabatli ma’lumotlar bazasi (Relational database) hali ham muhim¶
Munosabatli ma’lumotlar bazasi jadvallar sifatida munosabatlarni tashkil qiladi. Har bir jadval satrlardan iborat, har bir satr biror subyekt yoki hodisa haqidagi faktni ifodalaydi, va har bir ustunga belgilangan ma’no va tip taalluqlidir. PostgreSQL’ning o‘z qo‘llanmasi tizimni munosabat kontseptsiyalari va SQL tili orqali tushuntiradi, aynan shuning uchun u ma’lumotlar muhandisi (data engineer) va ilova ishlab chiquvchilar uchun foydali ta’lim platformasi bo’lib qoladi.[^pg-tutorial]
Munosabatli yondashuv barqarordir, chunki u takrorlanuvchi tashkilot muammosini hal qiladi. Korxonalar faqat ma’lumotlarni saqlashi kerak emas; ular "qoidalarga rozi bo’lish"lari lozim. Mijozning yagona shaxsiyati bo‘lishi kerak. Buyurtma mavjud mijozga tegishli bo‘lishi lozim. Mahsulot narxi manfiy bo‘lmasligi kerak. To‘langan to‘lov server qayta ishga tushgan taqdirda yo‘qolmasligi kerak. Bu talablarni ma’lumotlar modeli, Cheklov (constraint), Tranzaksiya (transaction) va tiklash mexanizmlari yozuvlarni himoya qiladigan joyga yaqin bo‘lganda amalga oshirish osonroq bo‘ladi.
Ta’rif. Ushbu kitobda munosabatli ma’lumotlar bazasi jadvallarda tuzilgan strukturalangan yozuvlarni saqlaydigan, ularni SQL orqali taqdim etadigan, kalitlar va Cheklovlar yordamida yaxlitlikni ta’minlaydigan va Tranzaksiya, yozish (logging) va Tiklash orqali holat o’zgarishlarini himoya qiladigan operatsion ma’lumotlar tizimi sifatida tushuniladi.
Munosabatli ma’lumotlar bazasi zamonaviy ma’lumotlar platformasidagi yagona saqlash tizimi emas. Biroq, odatda u operatsion haqiqatni modellashtirish uchun eng intizomli joy hisoblanadi. Shuning uchun ma’lumotlar muhandisi (data engineer) Airflow quvurlari, lakehouse jadvallari, Kafka mavzulari yoki BI semantik qatlamlariga kunlik e’tibor qaratayotgan bo’lsa ham, munosabatli ma’lumotlar bazalarini tushunishi kerak.
| Platforma roli | Odatdagi munosabatli javobgarlik | Keyingi tizimga bog’liqlik |
|---|---|---|
| Chekaut va buyurtma qabul qilish | Buyurtmalar, mijozlar, mahsulotlar, to‘lovlar va holatlarni tekshirish. | Hodisa oqimlari, moliya martlari, yetkazib berish boshqaruv panellari. |
| Mijoz ustav ma’lumotlari | Mijoz shaxsiyatini, rozilikni, aloqa maydonlarini va hisob holatini saqlash. | Marketing segmentatsiyasi, shaxsiylashtirish, muvofiqlik eksportlari. |
| Inventar va katalog | Mahsulot shaxsiyati, mavjudligi, narxi va kategoriya qoidalarini saqlash. | Qidiruv indekslari, tavsiya tizimlari, xarid hisobotlari. |
| Moliya operatsiyalari | Hisob-fakturalar, to‘lovlar, qaytarishlar va muvofiqlashtirishlarni qayd etish. | Buxgalteriya hisobotlari, firibgarlik monitoringi, daromad tahlillari. |
Munosib tushunmovchilik shuki, munosabatli ma’lumotlar bazalari eski, katta ma’lumot tizimlari esa zamonaviy deb hisoblanadi. Yaxshi fikr modeli shundan iboratki, munosabatli ma’lumotlar bazalari va analitik platformalar turli savollarga javob beradi. Munosabatli tizimlar operatsion ish oqimlarida to‘g‘ri holat o‘zgarishlari (state transitions) uchun optimallashtirilgan. Analitik tizimlar esa katta hajmda o‘qish, agregatsiya va tarixiy tahlil uchun optimallashtirilgan. Yetuk ma’lumotlar arxitekturasi ikkalasidan ham foydalanadi.
4.2 Munosabatli model (Relational Model) amaliyoti¶
Munosabatli sxema (schema) biznes va ma’lumotlar bazasi o’rtasidagi shartnoma hisoblanadi. Bu shartnoma obyektlarni nomlaydi, atributlarni belgilaydi va qaysi yozuvlar kombinatsiyalari ruxsat etilganini ko’rsatadi. PostgreSQL’ning cheklovlar (constraints) hujjatlari ma’lumotlar turlari ko’pincha juda noaniq ekanligini ta’kidlaydi; SQL cheklovlari dizaynerlarga aniqroq nazorat beradi va taklif qilingan qator qoida buzilganda xatoliklar chiqaradi.[^pg-constraints]
TuranMart uchun birinchi operatsion sxema (operational schema) to’rt asosiy jadvalni o’z ichiga oladi: customers, products, orders va order_items. Bu ataylab kichik sxema, ammo u ishlab chiqarish tizimlarida ko’p uchraydigan g’oyalarni o’z ichiga oladi.
Figure 2:TuranMart’ning OLTP (onlayn tranzaksiya ishlov berish) sxemasi mijozlar, mahsulotlar, buyurtmalar va satr elementlarini ajratib turadi, shunda identifikatsiya, haqiqiylik va munosabatlarni ma’lumotga yaqin joyda mustahkamlash mumkin.
4.2.1 Jadval, kalitlar va cheklovlar¶
Jadval bitta turdagi obyekt yoki hodisani ifodalashi kerak. Birlamchi kalit (primary key) har bir qatorni aniqlaydi. Tashqi kalit (foreign key) jadvallar orasida qatorlarni bog’laydi. Tekshiruv cheklovi (check constraint) haqiqiy qiymatlarni cheklaydi. Not-null cheklovi ma’lum bir atribut uchun yo’q qiymatlar qabul qilinmasligini bildiradi. Bu ta’riflar nazariy tuyulishi mumkin, ammo ular amalda 02:00 da savdo kampaniyasi vaqtida noto’g’ri ma’lumot kiritishga harakat qilinganda aniq bo’ladi.
| Dizayn elementi | TuranMart misoli | Muhandislik maqsadi |
|---|---|---|
| Birlamchi kalit | customers.customer_id | Har bir mijozga barqaror identifikatsiya beradi. |
| Tashqi kalit | orders.customer_id references customers.customer_id | Buyurtmaning mavjud bo’lmagan mijozga tegishli bo’lishini oldini oladi. |
| Kompozit birlamchi kalit | order_items(order_id, product_id) | Boshlang’ich sxemada bir xil buyurtma uchun takroriy mahsulot satrlarining paydo bo’lishini oldini oladi. |
| Tekshiruv cheklovi | status IN ('pending', 'completed', 'shipped', 'cancelled') | done, complete yoki closed kabi nomuvofiq status qiymatlarini bloklaydi. |
| Not-null cheklovi | orders.order_date NOT NULL | Kerakli biznes faktlarni aniq ko’rsatadi. |
Tashqi kalitlar ma’lumotlar muhandisligi (data engineering) uchun ayniqsa muhim, chunki ular operatsion model ichidagi kelib chiqishni hujjatlashtiradi. MySQL’ning hujjatlari tashqi kalitlarni bog’liq ma’lumotlarni kesishish orqali murojaat qilish va tarqatilgan jadval ma’lumotlarini izchil saqlash usuli sifatida tavsiflaydi; InnoDB shuningdek, tashqi-kalit ustunlarning indeks (index)ga ega bo’lishini talab qiladi, bu esa yaxlitlik dizaynini jismoniy kirish yo’llari bilan bog’laydi.[^mysql-fk]
4.2.2 Munosabat namunalar (Relationship Patterns)¶
Ko’pchilik munosabatli sxemalar kichik to’plamdagi munosabat namunalaridan foydalanadi. Birga-bir (one-to-one) munosabat qatorda ixtiyoriy yoki maxfiy kengaytma bo’lganda foydalidir. Birga-ko’p (one-to-many) munosabat esa kundalik holat: bitta mijozning ko’plab buyurtmalari bo’lishi mumkin, va bitta buyurtmada ko’plab order itemlar bo’lishi mumkin. Ko’pga-ko’p (many-to-many) munosabat esa bog’lovchi jadval orqali ifodalanadi, masalan student_courses, product_promotions yoki user_roles.
Figure 3:Munosabatli sxemalar birga-bir, birga-ko’p va ko’pga-ko’p biznes qoidalarini birlamchi kalitlar, tashqi kalitlar, noyoblik cheklovlari va bog’lovchi jadvallar orqali ifodalaydi.
TuranMart sxemasi mijozlardan buyurtmalarga va buyurtmalardan order itemlarga bo’lgan birga-ko’p munosabatlardan foydalanadi. Shuningdek, u order_itemsni buyurtmalarni mahsulotlarga ulovchi satr-jadval sifatida ishlatadi. Keyingi versiyada jamoa har bir mahsulot elementi uchun bir nechta chegirmalarni, yuklarni bo’lib yuborishni, qaytarishlarni yoki qisman ushlashlarni (partial captures) ruxsat berishi mumkin. Munosabatli model bu o’zgarishlarni qo’llab-quvvatlay oladi, lekin har bir o’zgarish ongli ravishda joriy etilgandagina.
4.2.3 Normalizatsiya (Normalization) va takrorlanish narxi¶
Normalizatsiya (normalization) — har bir fakt to’g’ri joyda, ortiqcha takrorlanishsiz saqlanishini tashkil etish jarayonidir. Agar mahsulot nomi har bir order itemga nusxa qilib yozilsa, keyingi mahsulot nomini o’zgartirish adashishga olib keladi. Agar mijoz hududi (region) mijozlar va buyurtmalar jadvallariga nusxa qilingan bo’lsa, jamoa buyurtma chekaut vaqtidagi hududni yozishi kerakmi yoki mijozning joriy hududinimi yozishi kerak — deb qaror qilishi lozim. Bu qaror texnik tafsilot emas, balki biznes qoidasi hisoblanadi.
Figure 4:Munosabatli dizayn dastlab to’g’rilik (normalizatsiya) tomon harakatlanadi va faqat so’rovlar dalillari bunday savdo-offerni (trade-off) asoslaganda tanlab optimizatsiyalarga o’tadi.
Normalizatsiyalangan sxema avtomatik ravishda tez emas, va denormalizatsiyalangan sxema avtomatik ravishda noto’g’ri emas. Intizom shundan iboratki, to’g’rilikdan boshlash, haqiqiy kirish naqshlarini o’lchash va keyin yuklama ehtiyojini isbotlagan joyda optimallashtirish. Operatsion tizimlarda erta denormalizatsiya ko’pincha uzoq muddatli ma’lumotlar sifati muammolarini keltirib chiqaradi, va bu muammolar uni hal qilish uchun mo’ljallangan tezlik masalasidan qimmatroq bo’ladi.
4.3 Tranzaksiyalar (transactions) va ACID (ACID) kafolatlari¶
Tranzaksiya bir nechta ma’lumotlar bazasi operatsiyalarini yagona ish birligiga birlashtiradi. PostgreSQLning tranzaksiyalar bo‘yicha darsligi asosiy fikrni aniq bayon etadi: tranzaksiya bir nechta bosqichni “barchasi yoki hech biri” tamoyili asosida guruhlaydi, parallel tranzaksiyalardan o‘rta holatlarni yashiradi va agar tranzaksiya to‘liq bajarilmasa qisman o‘zgartirishlarni bekor qiladi.[^pg-transactions]
TuranMart uchun checkout jarayoni (checkout) buyurtma elementlarisiz buyurtma yaratmasligi, buyurtmasiz to‘lovni qayd etmasligi yoki to‘lov muvaffaqiyatsiz bo‘lgan paytda buyurtmani bajarilgan deb belgilamasligi lozim. Ilova muvaffaqiyatli yoki muvaffaqiyatsiz bo‘lishi kerak bo‘lgan holat o‘zgarishini qamrab oluvchi tranzaksiya chegarasini aniqlashi kerak.
| ACID xususiyati | TuranMart checkout jarayoni uchun ma’nosi | Oldini oladigan xato misoli |
|---|---|---|
| Atomiklik (Atomicity) | Bog‘liq yozuvlar birgalikda tasdiqlanadi yoki umuman tasdiqlanmaydi. | Buyurtma sarlavhasi mavjud, lekin satr elementlari yo‘q. |
| Izchillik (Consistency) | Cheklovlar (constraints) ma’lumotlar bazasining yaroqli holatini saqlaydi. | Buyurtma holati qo‘llab‑quvvatlanmaydigan qiymatga o‘rnatilgan. |
| Izolyatsiya (Isolation) | Parallel tranzaksiyalar xavfli o‘rta holatlarni ko‘rmaydi. | Moliya bo‘limi yarim tugallanmagan checkout ma’lumotlarini o‘qiydi. |
| Doimiylik (Durability) | Tasdiqlangan o‘zgarishlar ma’lumotlar bazasining tiklash modeli asosida kutilmagan uzilishlardan keyin ham saqlanadi. | Tasdiqlangan buyurtma qayta ishga tushgandan keyin yo‘qoladi. |
MySQL hujjatlari ACID modelini biznes ma’lumotlari va missiya uchun muhim ilovalar uchun ishonchlilik tamoyillari majmuasi sifatida tavsiflaydi va InnoDB ushbu tamoyillarga yaqindan mos keladigan xususiyatlarni taqdim etadi.[^mysql-acid] PostgreSQL tranzaksiya izolyatsiyasini ko‘p versiyali model (multiversion model) orqali amalga oshiradi. Uning MVCC hujjatida har bir SQL bayonoti ma’lumotlar bazasining kesimini (snapshot) ko‘rishi va o‘qiydiganlar yozuvchilarga, yozuvchilar esa o‘qiydiganlarga normal MVCC xatti‑harakatida to‘sqinlik qilmasligi tushuntiriladi.[^pg-mvcc]
Muhandislik jihatidan bu shuni anglatadiki, tranzaksiya dizayni arxitektura ko‘rib chiqishlarida bo‘lishi kerak. Jamoalar qaysi holat o‘zgarishlari bitta tranzaksiya ichida bo‘lishi kerakligini, qaysi operatsiyalar oxir‑oqibat izchil (eventually consistent) bo‘lishi mumkinligini va qaysi joylarda idempotentlik (idempotency) talab qilinishini so‘rashlari lozim, chunki xabar, ish yoki API so‘rovi qayta urunilishi mumkin.
4.4 PostgreSQL arxitekturasi Ma’lumotlar muhandislari uchun (data engineers)¶
PostgreSQL jamoalar boy SQL, kuchli standartlarga yo’naltirilganlik, rivojlangan indekslash, kengaytiriluvchanlik va pishiq tranzaksion xulq-atvorni xohlaganda ko’pincha tanlanadi. U operatsion ma’lumotlar bazasi sifatida keng qo’llaniladi, lekin ma’lumotlar muhandisligi (data engineering) ish oqimlarida ham metama’lumotlar (metadata) ombori, orkestratsiya (orchestration) ma’lumotlar bazasi, kichik ma’lumotlar ombori, reverse-ETL manzili va change data capture manbai sifatida paydo bo’ladi.
Figure 5:PostgreSQL joylashtirilishi mijoz sessiyalari, SQL rejalashtirish va ijro etish, umumiy xotira, fon jarayonlari, write-ahead logging va doimiy ma’lumot fayllarini birlashtiradi.
Ma’lumotlar muhandisligi (data engineering) nuqtai nazaridan PostgreSQLning uchta g’oyasi darhol muhimdir. Birinchidan, so’rov rejalashtiruvchisi so’rov tuzilishi va statistikaga asoslanib bajarish so’rov rejasi — So’rov rejasi (query plan) ni tanlaydi. PostgreSQLning EXPLAIN hujjatida tizim har bir so’rov uchun reja tuzishi va to’g’ri reja tanlash ishlash uchun muhim ekanligi qayd etilgan.[^pg-explain] Ikkinchidan, MVCC bir vaqtning o’zida o’qiydiganlar va yozuvchilarga oddiy o’qish/yozish bloklanishini talab qilmasdan tizimni amaliy ravishda bo’lishish imkonini beradi.[^pg-mvcc] Uchinchidan, zaxira nusxa — Zaxira nusxa (backup) variantlari SQL dumplari, fayl tizimi darajasidagi zaxiralar va uzluksiz arxivlashni o’z ichiga oladi; har birining o’zaro savdo-offlari mavjud.[^pg-backup]
| PostgreSQL imkoniyati | Nega ma’lumotlar muhandisi buning haqida qayg’urishi kerak |
|---|---|
| Boy SQL va kengaytmalar | Manbaga yaqin murakkab o’zgartirishlar, tekshiruv so’rovlari va operatsion tahlillarni amalga oshirish imkonini beradi. |
| MVCC | Snapshot xulq-atvorini, replikada o’qishlarni, uzoq davom etuvchi so’rovlarni va vacuum bilan bog’liq operatsion muammolarni tushuntirishga yordam beradi. |
EXPLAIN va rejalashtiruvchi statistikasi | So’rov ishlashini taxmin emas, balki o’lchab bo’ladigan muhandislik muammosiga aylantiradi. |
| Mantiqiy dump va uzluksiz arxivlash imkoniyatlari | Bazadagi operatsiyalarni takrorlanuvchi muhitlarga va tiklash rejalashtirishiga bog’laydi. |
| Kuchli cheklov — Cheklov (constraint) qo’llab‑quvvatlashi | Noto’g’ri operatsion yozuvlarning keyingi quvurlarga ifloslik qilishining oldini oladi. |
PostgreSQL mo’jiza emas. Uga vacuum bilan bog’liq texnik xizmat, statistika, ulanishni boshqarish, disk rejalashtirish va zaxira sinovlari kerak bo’ladi. Maqsad shundaki, ma’lumotlar muhandisi to’liq vaqtli ma’lumotlar bazasi administratoriga aylanishi shart emas. Maqsad shuki, ma’lumotlar quvurlari (pipeline) ma’lumotlar bazasining xulq-atvoriga bog’liq va muhandis ushbu xulq-atvorni tushungan sari quvurning ishonchliligi oshadi.
4.5 MySQL arxitekturasi ma’lumotlar muhandislari (data engineers) uchun¶
MySQL veb-ilovalar, savdo tizimlari, kontent platformalari va SaaS mahsulotlarida keng tarqalgan. Uning standart Tranzaksiya (transaction) dvigateli, InnoDB, ishchi ma’lumotlarni tahlil uchun chiqarishda ko’pchilik ma’lumotlar muhandislari duch keladigan qismdir. MySQL hujjatlarida InnoDB uchun ACID xatti-harakati, ko’pversiyali yondashuv (multiversioning), qulflash, xotirada saqlanadigan tuzilmalar, diskdagi tuzilmalar, Zaxira nusxa (backup) va Tiklash (restore), hamda Replikatsiya (replication) haqida ma’lumot berilgan.[^mysql-innodb]
Figure 6:InnoDB bilan MySQL joylashtiruvi SQLni pars qilish va optimallashtirishni buf r hovuzlari, loglar, indekslar, qulflash va doimiy sahifalarni boshqaradigan saqlash dvigatelidan ajratadi.
MySQL ma’lumotlar muhandisligi (data engineering) uchun ayniqsa muhim, chunki ko’plab tashkilotlar ilova ma’lumotlar bazalarini MySQLda yuritadilar, tahlillar esa boshqa joyda amalga oshiriladi. Bir ma’lumotlar quvuri (data pipeline) MySQL binloglarini o’qishi, inkremental ekstraktlarni ishga tushirishi, jadvalarni ma’lumotlar omboriga replikatsiya qilishi yoki MySQL tranzaksiyaviy ma’lumotlarini lakehouse fakt jadvali bilan muvofiqlashtirishi mumkin. InnoDB indekslarini, tranzaksiyalarni va zaxira nusxalarni tushunish ma’lumotlar muhandisiga manbani ortiqcha yuklamaydigan ekstraktlardan saqlanishga yordam beradi.
| MySQL/InnoDB imkoniyati | Nega ma’lumotlar muhandisi bunga e’tibor berishi kerak |
|---|---|
| InnoDB tranzaksiyaviy saqlash | Ko’p ishlab chiqarish MySQL ilova ma’lumotlari InnoDB izchilligi va tiklash semantikalariga bog‘liq. |
| Binary logging va replikatsiya ekotizimi | Ko‘plab CDC va o‘qishni kengaytirish naqshlari MySQL replikatsiya tushunchalaridan kelib chiqadi. |
| Indekslarni optimallashtirish bo‘yicha ko‘rsatmalar | MySQL ortiqcha indekslar joyni behuda iste’mol qilishi va yozish xarajatlarini oshirishi haqida ochiq ogohlantiradi.[^mysql-indexes] |
| Zaxira nusxa va tiklash variantlari | MySQL hujjatlari avariyalar, apparat nosozliklari, tasodifiy o’chirishlar, yangilanishlar, uzatishlar va replikalar uchun zaxira nusxalarini ta’kidlashadi.[^mysql-backup] |
| InnoDBda tashqi kalit (foreign key) qo’llab‑quvvatlanishi | Referensial yaxlitlik ma’lumotlar bazasida bo’lishi yoki ilova tomonidan ta’minlanishi mumkin; ma’lumotlar muhandisi buni tekshirishi lozim. |
Amaliy ma’lumotlar muhandisi universal ravishda PostgreSQL yoki MySQL qaysi biri yaxshiroq deb so’ramaydi. To’g’riroq savol — qaysi tizim dastur ish yukiga, operatsion jamoa tajribasiga, ekotizim talablariga va uzoq muddatli ma’lumotlar arxitekturasiga mos tushishini aniqlashdir.
Figure 7:PostgreSQL va MySQL bo’yicha qarorlar ish yukining shakli, ekotizimga mosligi, operatsion tajriba, kengaytirish ehtiyojlari va mavjud platforma standartlarini hisobga olishi kerak.
4.6 Indekslar, so’rov rejalari va ishlash samaradorligi intizomi¶
Indekslar (index) ma’lumotlar bazasiga jadvallagi har bir qatorni skanerlash shartlarsiz kerakli yozuvlarni topishda yordam beradigan kirish tuzilmalaridir. PostgreSQL hujjatlari indekslarni ishlashni yaxshilashning keng tarqalgan usuli deb ta’riflaydi, biroq ular ortiqcha yuk qo’shishini va oqilona ishlatilishi kerakligini ogohlantiradi.[^pg-indexes] MySQL’ning indekslarni optimallashtirish bo’yicha hujjatlari shu muhandislik kompromisini ochiq-oydin ko’rsatadi: indekslar SELECT amallarini tezlashtirishi mumkin, lekin keraksiz indekslar joyni isrof qiladi va qo’shish, yangilash va o’chirish amallariga xarajat qo’shadi.[^mysql-indexes]
Boshlovchilarning xatosi — so’rov sekin bo’lib tuyulsa har joyga indeks qo’shish. Professional ish jarayoni esa boshqacha. Avvalo, biznes so’rovini aniqlang. Ikkinchidan, So’rov rejasi (query plan)ni o’lchang. Uchinchidan, eng kichik foydali indeksni qo’shing. To’rtinchidan, qayta o’lchang. Beshinchidan, yozish samaradorligi va saqlash hajmini kuzatib boring.
Figure 8:Ishlashni optimallashtirish dalillarga asoslangan sikldir: ish yukini kuzating, rejani tekshiring, bitta dizayn elementini o’zgartiring, qayta o’lchang va o’zgartirishni saqlash yoki bekor qilish to’g’risida qaror qiling.
TuranMart uchun dastlab ikki aniq kirish naqshi paydo bo’ladi. Mijozlarni qo’llab‑quvvatlash ko’pincha mijozning so’nggi buyurtmalarini qidiradi, moliya esa hudud bo’yicha yakunlangan daromadlarni guruhlaydi. Shuning uchun laboratoriya quyidagi kabi indekslarni yaratadi: idx_orders_customer_date va idx_orders_status_region. Bu indekslar tasodifiy bezak emas. Ular ilova va moliya jamoasi takroran so’raydigan haqiqiy savollarga mos keladi.
| So’rov namunasi | Tavsiya etilgan indeks | Nima uchun foydali |
|---|---|---|
| Bir mijozning so’nggi buyurtmalari | orders(customer_id, order_date DESC) | Mijoz bo’yicha filtrlaydi va yozuvlarni qulay sana tartibida qaytaradi. |
| Hudud bo’yicha yakunlangan daromad | orders(status, region) | Holat bo’yicha filtrlaydi va yakunlangan buyurtmalarni hududlarga ko’ra guruhlaydi. |
| Mahsulot darajasidagi buyurtma tahlili | order_items(product_id) | Mahsulot bo’yicha liniya elementlarini birlashtirish (join) yoki filtrlashni osonlashtiradi. |
EXPLAIN oddiygina so’rov yaxshi yoki yomon deb aytmaydi. U optimizer tanlagan reja — qaysi turdagi skanlar, qatorlar bo’yicha baholar, qo’shilishlar, saralashlar va xarajat baholari kabi ma’lumotlarni ko’rsatadi. PostgreSQL hujjatlari rejani reja tugunlari (plan nodes) daraxti sifatida tasvirlaydi: pastki tugunlar qatorlarni oladi, yuqori tugunlar esa ularni birlashtiradi, agregatlaydi yoki saralaydi.[^pg-explain] Ma’lumotlar muhandisi (data engineer) ketma-ket skanlar, indeks skanlari, filtrlar, qo’shilishlar va agregatsiya tugunlarini tanib olishni o’rganishi, so’ngra bu kuzatuvlarni ish yukidagi dalillar bilan bog’lashni o’rganishi kerak.
4.7 Sxema (schema) migratsiyasi (migration)ni ishlab chiqarish intizomi sifatida¶
O’sib borayotgan biznes bilan birinchi aloqadan keyin hech qanday Munosabatli ma’lumotlar bazasi (Relational database) sxemasi o’z holicha qolmaydi. TuranMart’ning birinchi sxemasi buyurtmalarni (orders) qayd etadi, lekin moliya jamoasi tez orada to’lovlarni muvofiqlashtirishni so’raydi. Muhandislik jamoasi payments jadvalini qo’shishi, uni orders bilan bog’lashi va qayd etilgan to’lovlarni yakunlangan buyurtma yig’indilari bilan solishtiruvchi so’rov yaratishi kerak.
Migratsiya (migration) — bu faqat ALTER TABLE bayonotidan ko’proq narsadir. Bu umumiy shartnomaga nazorat ostida kiritilayotgan o’zgarishdir. Ilova kodi, analytics ishlari, boshqaruv panellari, reverse-ETL sinxronizatsiyalari, ma’lumotlar sifati tekshiruvlari va hujjatlar barchasi sxemaga bog’liq bo’lishi mumkin. Shuning uchun xavfsiz migratsiya quyidagilarni o’z ichiga olishi kerak: sabab, ko’rib chiqilgan SQL o’zgarishi, test ma’lumotlar to’plami, orqaga qaytarish yoki oldinga tuzatish rejasi va joylashtirishdan keyingi tekshiruv so’rovi.
| Migratsiya bilan bog’liq masala | Amaliy savol |
|---|---|
| Moslik | Yangi va eski ilova versiyalari joylashtirish davomida ishlay oladimi? |
| Backfill | Mavjud satrlar yangi qiymatlarga muhtojmi va yangilash xavfsiz bajarilishi mumkinmi? |
| Bloklash | O’zgarish katta jadvalga yozish yoki o’qishni bloklaydimi? |
| Tekshirish | Qaysi so’rov yangi jadval yoki ustunning to’g’ri ekanligini isbotlaydi? |
| Orqaga qaytarish | Qaytarib olish, foydalanishni o’chirish yoki oldinga yo’naltirilgan tuzatishni qo’llashdan qaysi biri xavfsizroq? |
4-bob laboratoriya ishida migratsiya fayli 04_migration_add_payments.sql bir Tranzaksiya (transaction)ni boshlaydi, payments jadvalini yaratadi, (order_id, payment_status) bo’yicha bir Indeks (index) yaratadi, namunaviy qayd etilgan to’lovlarni kiritadi va muvofiqlashtirish so’rovini bajaradi. Ushbu kichik migratsiya katta ishlab chiqarish amaliyotining modelini ko’rsatadi: ma’lumotlar bazasidagi o’zgarishlar audit qilinishi va sinovdan o’tkazilishi kerak.
4.8 Zaxira nusxa (Backup), Tiklash (Restore) va Tiklash maqsadlari (Recovery Objectives)¶
Zaxira nusxalar faqat ularni tiklash mumkin bo’lsa foydali bo’ladi. PostgreSQL’ning zaxira hujjatlari qiymatli ma’lumotlarni o’z ichiga olgan ma’lumotlar muntazam ravishda zaxiralangan bo’lishi kerakligini ta’kidlaydi va uchta keng yondashuvni aniqlaydi: SQL chiqimi, fayl tizimi darajasidagi zaxira nusxa va uzluksiz arxivlash.[^pg-backup] MySQL’ning zaxira hujjatlari operatsion motivatsiyani aniq ifodalaydi: zaxiralar ishdan chiqishlardan, apparat xatoliklaridan, tasodifiy o’chirishlardan, yangilashlardan, ko’chirishlardan, replikani sozlashdan, jadvalga qo’yishdan, siqishdan, shifrlashdan va ma’lum vaqtga nuqtaviy tiklashdan (point-in-time recovery) tiklanishni qo’llab-quvvatlaydi.[^mysql-backup]
Ma’lumotlar muhandislari (Data engineer) ikkita tiklash metrikasini bilishi kerak. Tiklash nuqtasi maqsadi (RPO) (Recovery Point Objective (RPO)) biznes qancha ma’lumotni yo’qotishga ruxsat berishini tavsiflaydi. Tiklash vaqti maqsadi (RTO) (Recovery Time Objective (RTO)) xizmat qayta tiklanishidan oldin biznes qancha kutishi mumkinligini tavsiflaydi. Ushbu maqsadlar zaxira nusxalar chastotasi, saqlash muddati, replikatsiya, tiklash avtomatlashtirilishi va voqea mashqlarini belgilashi kerak.
| Tiklash tushunchasi | TuranMart misoli | Arxitektura oqibati |
|---|---|---|
| RPO | “Eng ko’pi bilan besh daqiqalik buyurtma ma’lumotini yo’qotish mumkin.” | Uzluksiz arxivlash, replikatsiya yoki CDC talab qilinishi mumkin. |
| RTO | “Chekaut o’ttiz daqiqa ichida tiklanishi kerak.” | Tiklash ishchi qoidalari va sinovdan o’tgan avtomatlashtirish talab qilinadi. |
| Saqlash muddati | “Moliya bo’limi oy oxiri snapshotlarini so’rashi mumkin.” | Zaxira nusxalar hayoti sikli siyosati audit va hisobot talablari bilan mos bo’lishi kerak. |
| Tiklash testi | “Zaxira nusxa har hafta staging muhitiga tiklanadi.” | Ishonch faqat zaxira fayllaridan emas, balki repetitsiyadan keladi. |
Munosabatli ma’lumotlar bazasi (relational database) uchun zaxiralash strategiyasi ma’lumotlar platformasining (data platform) bir qismidir. Agar operatsion ma’lumotlar bazasi (operational database) yo’qolsa, keyingi tahlillar (downstream analytics) tarixni hisobot qilishi mumkin, lekin barcha o’zgartirishlar qayd etilib, qayta ijro etilishi mumkin bo’lmasa, hozirgi aniq holatni xavfsiz qayta yaratolmaydi. Shu sababli, zaxira/tiklash amaliyoti yuklash (ingestion), orkestratsiya (Orchestration) va kelib chiqish (lineage) masalalari bilan bir xil suhbatda bo’lishi kerak.
4.9 Ishlab chiqarish dizayn andozasi: OLTP manbai orqali analitikani ta’minlash¶
Eng keng tarqalgan ma’lumotlar muhandisligi (data engineering) andozasi OLTP ma’lumotlar bazasidan boshlanib analitik model bilan tugaydi. Ilova normalizatsiyaga qilingan operatsion yozuvlarni PostgreSQL yoki MySQL ga yozadi. Ma’lumotlar quvuri (data pipeline) o’zgarishlarni ajratib oladi, ularni Ob’ektli saqlash (object storage) yoki ma’lumotlar omboriga (warehouse) joylaydi, ularni faktlar va o’lchamlarga (facts and dimensions) o’zgartiradi va biznes metrikalarini xizmat qiladi.
Xavf shundaki, analitik qulayliklarni operatsion sxemaga (operational schema) juda erta singdirib yuborishdir. Masalan, moliya bo’limi mijoz, mahsulot, buyurtma, to’lov va yetkazib berish maydonlari bilan bir keng order_report jadvalini xohlaydi. Bunday shakl omborda foydali bo’lishi mumkin, lekin u asosiy chekaut sxemasi uchun xavfli, chunki u faktlarni takrorlaydi va cheklovlarni zaiflashtiradi. Operatsion sxema holat o’zgarishlarini himoya qilishi kerak. Analitik model esa o’qishni optimallashtirishi lozim.
| Qatlam | Ma’lumotlar shakli | Asosiy optimallashtirish maqsadi |
|---|---|---|
| OLTP ma’lumotlar bazasi | Normalizatsiyalangan jadvallar, cheklovlar va tranzaksiyalar. | Yozuvlarning to’g’riligi va ishonchli operatsion holat. |
| Xom yuklash zonasi | Manbaga mos shakldagi jadvallar yoki fayllar va metama’lumotlar. | To’liqlik, qayta ijro etish imkoniyati, kelib chiqish (lineage) va audit qilish imkoniyati. |
| Saralangan ombor/lakehouse | Faktlar, o’lchamlar, agregatlar yoki ma’lumot mahsulotlari. | Tez analitik so’rovlar va biznes uchun foydalanish qulayligi. |
| BI va teskari ETL | Metrikalar, segmentlar, ekstraktlar va operatsion sinxronizatsiyalar. | Qaror qabul qilishni qo’llab-quvvatlash va faollashtirish. |
Ushbu andoza jamoa mas’uliyatlarini ham aniqlashtiradi. Ilova muhandislari tranzaksiya chegaralariga (tranzaksiya chegaralari) va foydalanuvchiga ko’rsatiladigan to’g’rilikka egalik qiladi. Ma’lumotlar bazasi administratorlari yoki platforma muhandislari ma’lumotlar bazasi operatsiyalariga egalik qiladi. Ma’lumotlar muhandislari (data engineers) esa ajratib olish, tekshirish, o’zgartirish va keyingi tizimlarga oid shartnomalarga egalik qiladi. Bu chegaralar kesishadi, shuning uchun muloqot arxitekturaning bir qismi hisoblanadi.
Yo’naltirilgan laboratoriya: TuranMart uchun Munosabatli buyurtma ma’lumotlar bazasini (relational database) qurish va tekshirish¶
Ushbu laboratoriyada siz 4-bobdagi munosabatli ma’lumotlar bazasi aktivlari bilan ishlaysiz. Laboratoriya mahalliy ravishda ishlatish uchun kichik qilib mo’ljallangan, lekin u ishlab chiqarish faoliyatlarini aks ettiradi: sxema (Schema) yaratish, ma’lumotlarni urug’lash, so’rov rejalarini (Query plan) tekshirish, indekslar (Index) qo’shish, migratsiyani (Migration) qo’llash, to’lovlarni moslashtirish va zaxira nusxa/tiklash (Backup/Restore) amaliyotini ko’rib chiqish.
| Laboratoriya elementi | Joylashuvi |
|---|---|
| Lab README | shared/labs/ch04_relational_databases/README.md |
| Docker Compose services | shared/labs/ch04_relational_databases/docker-compose.yml |
| Schema SQL | shared/labs/ch04_relational_databases/sql/01_schema.sql |
| Seed SQL | shared/labs/ch04_relational_databases/sql/02_seed.sql |
| Indexes and query plans | shared/labs/ch04_relational_databases/sql/03_indexes_and_queries.sql |
| Payments migration | shared/labs/ch04_relational_databases/sql/04_migration_add_payments.sql |
| Backup/restore checklist | shared/labs/ch04_relational_databases/05_backup_restore.md |
| Expected output | shared/labs/ch04_relational_databases/expected_output/revenue_by_region.csv |
| Validator | shared/labs/ch04_relational_databases/tests/validate_lab_assets.py |
Laboratoriya muhiti sozlamasi¶
Repositoriyning ildizidan boshlang va buyruqlarni ishlatishdan oldin laboratoriya paketini tekshiring. Compose fayli PostgreSQL 16 va MySQL 8.4 xizmatlarini taqdim etadi, shunda siz ish faoliyatini solishtira olasiz va bobning asosiy SQL yo’li PostgreSQLga qaratilgan bo’lib qoladi.
cd shared/labs/ch04_relational_databases
python3 tests/validate_lab_assets.py
docker compose up -dValidator sizdan talab qilinadigan SQL, ma’lumotlar, kutilyotgan natija va yordamchi fayllar mavjudligini tasdiqlashi kerak. Agar Docker muhitda mavjud bo’lmasa, SQL fayllarni ketma-ket o’qing va dizayn savollarini qo’lda bajaring. Konseptual o’rganish hali ham amal qiladi.
1-qadam: Sxemani (Schema) yaratish¶
Sxema faylini PostgreSQLga qo’llang. Sxema customers, products, orders, va order_items jadvallarini Birlamchi kalit (Primary key), Tashqi kalit (Foreign key), null bo’lmaslik qoidalari va tekshiruvchi cheklovlar (Cheklov (Constraint)) bilan yaratadi.
psql postgresql://postgres:postgres@localhost:5432/turanmart \
-f sql/01_schema.sqlSxemani qo’llagandan so’ng jadval ta’riflarini tekshiring. orders.customer_id ning customers.customer_id ga ishora qilayotganiga, buyurtma holati qiymatlari cheklov ostida ekanligiga, va order_items kompozit birlamchi kalitdan (kompozit birlamchi kalit: bir nechta ustunni o’z ichiga olgan Birlamchi kalit) foydalanganligiga ishonch hosil qiling.
2-qadam: Operatsion ma’lumotlarni urug’lash¶
Deterministik namunaviy ma’lumotlarni yuklang.
psql postgresql://postgres:postgres@localhost:5432/turanmart \
-f sql/02_seed.sql
```bash
Ushbu ma'lumotlar to'plami maqsadli jihatdan kichik. Kichik to'plam har bir yozuvni millionlab qatorlarga miqyoslashdan oldin diqqat bilan tahlil qilish imkonini beradi.
### 3-qadam: So'rov rejalarini (**Query plan**) tekshirish va indekslar (**Index**) qo'shish
So'rov-reja skriptini ishga tushiring. U indeks yaratishdan oldingi va keyingi holatdagi daromad va qidiruv so'rovlari natijalarini ko'rsatadi.
```bash
psql postgresql://postgres:postgres@localhost:5432/turanmart \
-f sql/03_indexes_and_queries.sqlIndeks bayonotlarini sehr sifatida qabul qilmang. Har bir indeks uchun qaysi so’rov naqshini qo’llab-quvvatlashi va indeks saqlanishi natijasida qaysi yozuv operatsiyasi biroz qimmatroq bo’lishi mumkinligi haqida bitta jumla yozing.
4-qadam: Daromad chiqishini tasdiqlash¶
Oxirgi daromad so’rovini ishga tushiring va uni kutilyotgan natija bilan solishtiring.
region,completed_revenue
Samarkand,420.00
Tashkent,900.00Kutilyotgan natija expected_output/revenue_by_region.csv joylashuvida saqlangan. Mos kelmaslik urug’langan ma’lumotlar o’zgargani, yakunlangan buyurtmalar bo’yicha filtr o’zgargani yoki agregatsiya so’rovi laboratoriya shartnomasiga mos kelmayotgani bilan bog’liq bo’lishi mumkin.
5-qadam: To’lovlar migratsiyasini (Migration) qo’llash¶
payments jadvalini qo’shadigan va reconcilyatsiya so’rovini bajarayotgan migratsiya faylini qo’llang.
psql postgresql://postgres:postgres@localhost:5432/turanmart \
-f sql/04_migration_add_payments.sqlMigratsiyadagi tranzaksiya (Tranzaksiya (Transaction)) chegarasini o’rganing. Maqsad faqat jadval yaratish emas; operatsion shartnomani xavfsiz ravishda o’zgartirishdir. Ishlab chiqarish sharoitida siz qulflash xatti-harakatini, backfill strategiyasini, rollout tartibini, monitoring va qaytarish (rollback) imkoniyatlarini ham ko’rib chiqasiz.
6-qadam: Zaxira nusxa va tiklashni (Backup/Restore) ko’rib chiqish¶
05_backup_restore.md faylini o’qing va zaxira yaratish bilan zaxiraning tiklanishini isbotlash o’rtasidagi farqni tushuntiring. So’ngra TuranMartning checkout ma’lumotlar bazasi uchun qisqa Tiklash nuqtasi maqsadi (RPO) (Tiklash nuqtasi maqsadi (RPO) (Recovery Point Objective (RPO))) va Tiklash vaqti maqsadi (RTO) (Tiklash vaqti maqsadi (RTO) (Recovery Time Objective (RTO))) bayonotini yozing.
Kuchli javob biznes ta’sirini muhandislik dizayniga bog’laydi. Masalan: “TuranMart eng ko’pida besh daqiqalik tasdiqlangan buyurtma ma’lumotini yo’qotishi mumkin va checkoutni o’rtacha o’nta daqiqada tiklashi kerak; shuning uchun faqat kundalik mantiqiy dump’lar ishlab chiqarish checkout bazasi uchun yetarli emas.”
Keng tarqalgan xatolar va operatsion saboqlar¶
Munosabatli ma’lumotlar bazalari (Relational databases) rivojlangan, ammo jamoalar ular bilan oldindan taxmin qilinadigan xatoliklarga barham bera olmaydilar. Ko’pchilik muvaffaqiyatsizliklar ma’lumotlar bazasini passiv saqlash idishi sifatida ko’rib, uni faol izchillik chegarasi sifatida emas, deb muomala qilinishidan kelib chiqadi — faol izchillik chegarasi (Izchillik (Consistency) haqida o’ylash kerak).
| Xato | Nega zarar keltiradi | Yaxshiroq amaliyot |
|---|---|---|
| Cheklovlarning (Constraint) yo’qligi | Noto’g’ri yozuvlar manbaga kirib, keyingi bosqichlarga tarqaladi. | Talab qilinadigan biznes qoidalarini kalitlar, tekshiruvlar, not-null qoidalari va murojaat ma’lumotlari bilan kodlang. |
| Har bir ustun uchun indekslar (Index) yaratish | Yozuvlar sekinlashadi va saqlash hajmi o’sadi, so’rovlar bo’yicha foyda aniq bo’lmaydi. | Kirish/foydalanish naqshlarini o’lchang va ishlatilmayotgan indekslarni ko’rib chiqing. |
| Tranzaksiya (Transaction) chegaralarini e’tiborsiz qoldirish | Qisman holat ko’rinarli yoki doimiy bo’lib qolishi mumkin. | Birgalikda muvaffaqiyatli bo’lishi yoki muvaffaqiyatsizlikka uchrashi kerak bo’lgan operatsiyalarni guruhlang. |
| Migratsiyalarni (Migration) ehtiyotsiz bajarish | Ilova kodi, quvurlar va boshqaruv panellari kutilmaganda buziladi. | Migratsiyalarni versiyalash, ularni sinash va sxema shartnomalarini (Sxema (Schema) foydalanuvchilarga) xabar qilish. |
| Zaxira nusxa (Backup) olib, tiklamaslik | Jamoalar juda kech fursatda zaxira fayllari to’liq emasligini yoki foydalanib bo’lmasligini aniqlaydilar. | Tiklash (Restore) mashqlarini jadvalga qo’ying va tiklash bosqichlarini hujjatlashtiring. |
| Ma’lumotlarni haddan tashqari agressiv chiqarish | Analitika ishlar operatsion manbani ortiqcha yuklaydi. | Replika nusxalar, CDC, inkremental chiqarish va ish yukiga mos jadvaldan foydalaning. |
Eng muhim operatsion dars shundaki, munosabatli ma’lumotlar bazasi boshqa jamoalar uchun umumiy bog’liqlik hisoblanadi. Ilova jamoalari, ma’lumotlar jamoalari, moliya bo’limi va mijozlarga xizmat ko’rsatish barchasi bir xil yozuvlarga tayanishi mumkin. Shu sababli sxema, indekslar, saqlash muddatlari yoki chiqarish jadvalidagi o’zgarishlar shaxsiy amalga oshirish tafsilotlari sifatida emas, foydalanuvchilari bo’lgan mahsulot o’zgarishlari sifatida muomala qilinishi kerak.
Laboratoriya materiallari¶
| Laboratoriya materiali | Maqsad | Havola |
|---|---|---|
| Laboratoriya README | Bosqichma-bosqich ko’rsatmalar, tozalash va muammolarni bartaraf etish. | README |
| Mashqlar | Ushbu bob uchun qo’shimcha amaliy vazifalar. | exercises |
| Yechim qo’llanmasi | Dizayn tanlovlari va kutilayotgan natijalar tushuntiriladi. | solution |
Mashqlar¶
TuranMart sxemasini (schema)
shipmentsjadvali bilan kengaytiring. Birlamchi kalitni (primary key) aniqlang,ordersga bo‘lgan tashqi kalitni (foreign key) belgilang, ruxsat etilgan yetkazib berish holatlarini ko‘rsating va operatsiyalar bo‘yicha qidiruvni qo‘llab‑quvvatlaydigan bitta indeksni (index) aniqlang.Yakunlangan daromad so‘rovini (
revenuequery) qayta yozib, u hudud o‘rnigaregistration_channelbo‘yicha daromadni chiqarsin. Qaysi qo’shilish (join) kerakligini va nega shunday ekanligini tushuntiring — masalan,ordersyokipaymentsjadvalidancustomersjadvaliga qo’shilish orqaliregistration_channelmaydonini olish zarurligini izohlang; to‘lovlar asosida hisoblash qilingan bo‘lsa INNER qo‘shilish, barcha buyurtmalarni ko‘rsatish kerak bo‘lsa LEFT qo‘shilish kerakligini tushuntiring.refundsjadvalini qog‘ozda loyihalashni bajaring. Qaysi jadval(lar)ga murojaat qilishi kerak:orders,paymentsyoki ikkalasiga ham — qaroringizni qabul qiling va bunga asoslangan izoh bering. (Masalan, moliyaviy oqim uchunpayment_idga referens qilish mantiqiy; biznes konteksti uchun esaorder_idham saqlansa qulay — lekin ikki xil referensni uyg‘unligini kafolatlovchi cheklovlar kerak bo‘ladi.)Laboratoriyadan bitta so‘rovni tanlang va indekslashdan oldin va keyin so’rov rejasi (query plan) qanday o‘zgarishini oddiy, tushunarli inglizcha emas — oddiy o‘zbekcha bilan tushuntiring. (Masalan: indeks bo‘lmaganda butun jadval bo‘ylab ketma‑ket o‘qish — sequental scan — sodir bo‘ladi, ko‘proq disk I/O va yuqori kechikish; indeks qo‘shilgandan so‘ng esa selektiv filtrlashlarda indeks skan yoki indeks‑faqat skan ishlaydi, qayta ishlash hajmi va CPU pasayadi; ammo kam selektivlik yoki ko‘p yangilanadigan yozuvlar bo‘lsa indeks overhead mavjudligini ta’kidlang.)
Qisqa insident ssenariysini yozing: zaxira nusxa (backup) mavjud bo‘lsa ham tiklash (recovery) muvaffaqiyatsiz tugaydi. Nima yetishmayapti — operatsion amaliyotdagi qaysi praktika yo‘q? (Masalan: zaxira nusxalarining muntazam tekshirilishi va qayta tiklash mashqlarining yo‘qligi; WAL/transaction log larni saqlamaslik yoki mos kelmaydigan sxema evolyutsiyasi; shifrlash kalitlarining yo‘qolishi; tiklash qo‘llanmasi va ruxsatlar boshqaruvi yetishmasligi kabi sabablarni ko‘rsating.)
Kichik SaaS mahsuloti uchun PostgreSQL va MySQL ni solishtiring. Jamoada kuchli MySQL tajribasi mavjud, ammo amaliy (operatsion) ma’lumotlar bazasida murakkab analitik SQL kerak. Qaror bo‘yicha tavsiya bering va muvozanatni tushuntiring.
Tavsiya (qisqacha): agar uzoq muddatda operativ baza ustida yanada boy analitik imkoniyatlar kerak bo‘lsa — PostgreSQLni tanlashni tavsiya qilaman. Agar loyiha tez bozorga chiqishi va jamoaning mavjud MySQL tajribasidan maksimal foydalanish birinchi darajali bo‘lsa, MySQL bilan davom etish oqilona bo‘lishi mumkin.
Nega PostgreSQL:
Boyroq analitik funksiyalar (takroriy oynali funksiyalar, keng CTE qo‘llab‑quvvatlashi, keng indeks variantlari, JSONB va to‘liq tekshiruv vositalari).
Kengaytirilgan funksiyalar va keng jamoa tomonidan ishlab chiqilgan plaginlar (masalan, materialized view, yaratish va parallel so‘rovlar).
Umuman olganda, murakkab OLAP‑yagona so‘rovlar va analitik yuklamalar uchun qulayroq.
Nega MySQL:
Jamoa allaqachon yaxshi biladi — tezroq ishlab chiqish va kamroq o‘quv xarajatlari.
MySQL 8 bilan analitik imkoniyatlar (window functions, CTE) yaxshilandi; kichik tizimlarda etarli bo‘lishi mumkin.
Migratsiya va operatsion xarajatlarni kamaytiradi.
Savdo‑o‘tish nuqtalari (trade‑offs):
O‘rgatish va migratsiya xarajatlari: PostgreSQLga o‘tish jamoa uchun vaqt va resurs talab qiladi.
Xususiyatlar vs vaqt‑bozorga: PostgreSQL ko‘proq funksionallik beradi, lekin MySQL bilan tezroq iteratsiya qilishingiz mumkin.
Operatsion qo‘llab‑quvvatlash: mavjud monitoring va backup/restore jarayonlari qaysi bazaga moslanganiga qarab o‘zgartiriladi.
Agar qaror PostgreSQL bo‘lsa, bosqichma‑bosqich migratsiya (ma’lumotlar modelini tekshirish, POC, parallel ishlash) va jamoani o‘qitish rejasi kerak; agar MySQL bilan davom etsangiz, analitik so‘rovlar uchun arxiv yoki dedikerlangan analitik qatlamni ko‘rib chiqish (masalan, izolyatsiyalangan read replica yoki OLAP qatlam) oqilona bo‘ladi.
Ko’rib chiqish savollari¶
| Savol | Kuchli javobda nima bo’lishi kerak |
|---|---|
| Zamonaviy ma’lumotlar platformalarida Munosabatli ma’lumotlar bazalari (relational databases) nega muhim bo’lib qolmoqda? | Ular operatsion haqiqatni Sxema (schema), Cheklov (constraint), Tranzaksiya (transaction), SQL va Tiklash (restore) orqali himoya qiladi; pastki tizimlar esa analitikani optimallashtirish va masshtab bo’yicha qayta ishlash uchun moslashtiriladi. |
| Birlamchi kalit bilan Tashqi kalit o’rtasidagi farq nima? | Birlamchi kalit (primary key) o’z jadvalidagi qatorlarni aniqlaydi; Tashqi kalit (foreign key) esa boshqa jadvalning kalitiga ishora qilib munosabatlarni ta’minlaydi. |
| Indekslar nega ehtiyotkorlik bilan qo’shilishi kerak? | Indekslar (index) tanlangan o’qish naqshlarini tezlashtiradi, ammo saqlashni oshiradi va yozish amallariga texnik xizmat xarajatlarini qo’shadi. |
EXPLAIN nima haqida tushunishga yordam beradi? | Optimizator tomonidan tanlangan So’rov rejasi (query plan), jumladan skanlar, birlashuvlar, filtrlashlar, taxminlar va xarajatlar. |
| Migratsiya nega ishlab chiqarish intizomi hisoblanadi? | Migratsiya (migration) umumiy Sxema (schema) shartnomasini o’zgartiradi va ilovalar, quvurlar, Boshqaruv paneli (dashboard), qulflar va Tiklash (restore)ga ta’sir qilishi mumkin. |
| Nega Zaxira nusxalar testlar davomida tiklanishi kerak? | Faqat Zaxira nusxa (backup) fayllari tiklanish mumkinligini isbotlamaydi; Tiklash (restore) mashqlari to’liqlikni, protseduralarni, ruxsatlarni, vaqtni va operatsion tayyorgarlikni tasdiqlaydi. |
Bob xulosasi va keyingi qadam¶
Munosabatli ma’lumotlar bazasi (Relational database) faqatgina ilovalarning ortidagi meros tizimlari emas; ular operatsion haqiqatning faol qo’riqchilari. PostgreSQL va MySQL munosabatli modelning SQL, cheklovlar (Constraint), tranzaksiyalar (Transaction), so’rov rejasi (Query plan), indekslar (Index), migratsiyalar (Migration) va zaxira nusxa (Backup) va tiklash (Restore) amaliyoti orqali ishlab chiqarish infratuzilmasiga qanday aylanishini ko’rsatadi.
Ushbu bobda, TuranMart’ning chekout muammosi bizga normalizatsiyalangan OLTP Sxemasi (Schema) loyihalash, biznes qoidalarni majburiy qilish, so’rov rejalarini o’qish, o’lchangan indekslarni qo’shish, to’lovlar uchun migratsiya kiritish va tiklash haqida fikr yuritishga amaliy sabab berdi. Katta saboq shundaki, ma’lumotlar muhandisligi (data engineering) ma’lumotlar omboriga yetib borguncha boshlanmaydi — u birinchi operatsion yozuv to’g’ri yaratilgan paytdan boshlanadi.
Keyingi bob saqlash haqidagi munozarani munosabatli ma’lumotlar bazalaridan NoSQL va yarim-strukturali ma’lumotlar (NoSQL and semi-structured data) tomon kengaytiradi. Siz hujjatga yo’naltirilgan tizimlar (document), kalit-qiymat tizimlar (key-value), ustun-oila tizimlar (column-family) va graf tizimlar (graph) nima uchun mavjudligini, ular qanday kompromisslarni qabul qilishlarini va qachon munosabatli tuzilma kuchli tomon ekanligini hamda qachon moslashuvchan yoki taqsimlangan modellar yuklamaga yaxshiroq mos kelishini qanday aniqlashni o’rganasiz.