Mundarija (36)
- Bu darsda
- 1. Nega bu kerak?
- 2. Bazalar xaritasi
- 2.1 Sakkiz tur bitta jadvalda
- 2.2 Document: bitta obyekt — bitta hujjat
- 2.3 Key-value: kalit bo'yicha juda tez
- 2.4 Wide-column: ulkan yozuv oqimi
- 2.5 Graph: bog'lanishlarning o'zi asosiy
- 2.6 Time-series: vaqt bo'yicha o'lchovlar
- 2.7 Qidiruv: matn ichidan topish
- 2.8 Vektor: ma'no bo'yicha qidirish
- 3. SQL vs NoSQL: haqiqiy farqlar
- 3.1 To'rt asosiy farq
- 3.2 Afsonalar
- 3.3 Dasturchilar nimani ishlatadi
- 4. Polyglot persistence
- 4.1 Bir ilovada bir nechta baza
- 4.2 Narxi
- 4.3 "Postgres yetadimi?" — kengaytmalar
- 5. Qanday tanlash kerak
- 5.1 Savollar ketma-ketligi
- 5.2 Maxsus baza qachon kerak
- 6. SQL qadami: vazifalar uchun baza tanlovi
- 7. Ko'p uchraydigan xatolar
- 7.1 Bazani reklamaga qarab tanlash
- 7.2 "Sxemasiz" ni "loyihalashsiz" deb tushunish
- 7.3 Keshni asosiy baza qilish
- 7.4 Ikki bazani "o'zi sinxron bo'ladi" deb o'ylash
- 8. Mashqlar
- 1-mashq (oson): juftlang
- 2-mashq (o'rta): taklifni baholang
- 3-mashq (qiyin): hujjatni yangilash narxi
- 4-mashq: SQL qadami — o'z loyihangiz
- 9. Real ishda
- Xulosa
- Manbalar
DB turlari xaritasi: SQL vs NoSQL va qachon qaysi baza
Qisqacha: Ma'lumotlar bazalarining bir necha turi bor: relatsion (PostgreSQL, MySQL), document (MongoDB), key-value (Redis), wide-column (Cassandra), graph (Neo4j), time-series, qidiruv (Elasticsearch) va vektor bazalar. Har biri ma'lum turdagi savolga tez javob berish uchun qurilgan. Yangi loyiha uchun ko'p holatda to'g'ri boshlang'ich tanlov — PostgreSQL: u relatsion, lekin JSON, kalit-qiymat, vaqt qatorlari va matn qidiruvini ham ko'taradi. Boshqa baza — aniq o'lchangan ehtiyoj paydo bo'lganda.
Bu darsda
- Sakkizta asosiy DB turini va har birining mashhur vakilini taniysiz.
- "SQL vs NoSQL" bahsidagi haqiqiy farqlarni (sxema, tranzaksiya, masshtablash) afsonalardan ajrata olasiz.
- Bitta PostgreSQL'da document, key-value, time-series va qidiruv misollarini o'qiysiz.
- Polyglot persistence nima ekanini, foydasi va narxini tushuntirasiz.
- Loyiha uchun baza tanlash savollarini bera olasiz.
Oldin bilishingiz kerak: Relatsion model, Nega ma'lumotlar bazasi.
1. Nega bu kerak?
Relatsion model darsida ma'lumotni jadvallarga joylab, kalitlar bilan bog'ladik. Lekin internetda tez-tez shunday gaplarni uchratasiz: "SQL eskirgan, hamma MongoDB'ga o'tgan", "Redis eng tez baza", "katta loyihada faqat NoSQL". Bularning qaysi biri to'g'ri?
Yangi boshlagan dasturchi uchun bu xavfli savol. Noto'g'ri tanlov bir yildan keyin bilinadi: hisobotlarni chiqarib bo'lmaydi, ma'lumot yo'qoladi yoki ikki baza orasidagi ma'lumot mos kelmay qoladi. Bazani almashtirish esa ilovaning yarmini qayta yozish degani.
Hayotiy o'xshatish: transport. Taksi, avtobus, yuk mashinasi, poyezd — hammasi "transport", lekin har biri o'z ishi uchun. Shahar ichida har kuni yurish uchun yengil mashina yetadi. Yuk mashinasini kunlik yurish uchun sotib olmaysiz. Ammo 20 tonna yuk tashish kerak bo'lsa, yengil mashina yordam bermaydi. Bazalar ham shunday.
2. Bazalar xaritasi
2.1 Sakkiz tur bitta jadvalda
| Tur | Ma'lumot shakli | Mashhur vakillar |
|---|---|---|
| relatsion | jadvallar, kalitlar | PostgreSQL, MySQL, SQLite |
| document | JSON'ga o'xshash hujjatlar | MongoDB, Couchbase |
| key-value | kalit → qiymat | Redis, Valkey, DynamoDB |
| wide-column | qator kaliti → ko'p ustun | Cassandra, ScyllaDB |
| graph | tugunlar va qirralar | Neo4j, Memgraph |
| time-series | vaqt → o'lchov | TimescaleDB, InfluxDB |
| qidiruv | matn indeksi | Elasticsearch, OpenSearch |
| vektor | sonlar massivi (embedding) | pgvector, Qdrant |
Relatsiondan boshqa hamma turni umumiy nom bilan NoSQL deyishadi. Nom chalg'itadi: u "SQL yo'q" emas, "Not only SQL" — "faqat SQL emas" deb tushuntiriladi. Ba'zi NoSQL bazalarda SQL'ga o'xshash til ham bor (Cassandra'da CQL).
Endi har turni bitta savol orqali ko'ramiz: u qaysi savolga tez javob beradi? Ba'zi turlarni kanon bazamizda — oddiy PostgreSQL 18.6 da — taqlid qilib ko'rdik. SQL'ning har qatorini hozir tushunish shart emas: biz faqat g'oyani ko'ryapmiz, sintaksis keyingi darslarda keladi.
2.2 Document: bitta obyekt — bitta hujjat
Document (hujjat) baza ma'lumotni JSON'ga o'xshash hujjatlarda saqlaydi. Vazifa va uning egasi bitta hujjatda, ichma-ich. Eng mashhuri — MongoDB (27-qismda o'rganamiz).
Kuchli tomoni: ilovadagi obyekt bazada xuddi shu shaklda turadi, sxema qat'iy emas. Zaif tomoni: Relatsion model darsidagi muammo — egasining ma'lumoti har hujjatda takrorlanadi.
PostgreSQL'da ham jsonb turi bor — ustunga butun JSON hujjat yoziladi. Kanon tajribasi:
CREATE TABLE t06_hujjat (id int PRIMARY KEY, hujjat jsonb NOT NULL);
INSERT INTO t06_hujjat VALUES
(1, '{"matn": "Bozor", "teglar": ["bozor"],
"egasi": {"ism": "Aziz", "shahar": "Toshkent"}}'),
(2, '{"matn": "IELTS", "teglar": ["ingliz", "oqish"],
"egasi": {"ism": "Dilnoza"}}');
CREATE INDEX ON t06_hujjat USING gin (hujjat jsonb_path_ops);
SELECT id, hujjat->'egasi'->>'ism' AS ism
FROM t06_hujjat
WHERE hujjat @> '{"teglar": ["ingliz"]}';Natija:
CREATE TABLE
INSERT 0 2
CREATE INDEX
id | ism
----+---------
2 | Dilnoza
(1 row)Birinchi uch qator — psql har buyruqdan keyin beradigan qisqa javob: jadval yaratildi, 2 qator qo'shildi, indeks yaratildi. @> — "ichida shu bo'lak bormi" amali, -> va ->> — hujjat ichiga kirish. Ikkinchi hujjatda shahar yo'q — baza buni qabul qildi, sxema qat'iy emas. GIN — JSON ichidan tez qidirish uchun maxsus indeks. jsonb ni JSONB darsida chuqur o'rganamiz.
2.3 Key-value: kalit bo'yicha juda tez
Key-value (kalit-qiymat) baza — eng oddiy model: kalit beriladi, qiymat qaytadi. JS'dagi Map kabi. Qiymat ichida nima borligini baza ko'pincha bilmaydi ham. Redis ma'lumotni operativ xotirada saqlaydi, shuning uchun sessiya, kesh va hisoblagichlar uchun ishlatiladi (27-qismda).
Postgres'da buni oddiy ikki ustunli jadval bilan taqlid qilish mumkin. Kanon UNLOGGED jadval ishlatdi — u tezroq yoziladi, lekin server kutilmaganda o'chsa, ichi bo'shab qoladi (keshga mos xususiyat):
CREATE UNLOGGED TABLE t06_kv (
kalit text PRIMARY KEY, qiymat text, tugash timestamptz);
INSERT INTO t06_kv
VALUES ('sessiya:42', 'aziz', now() + interval '30 minutes');
SELECT qiymat FROM t06_kv
WHERE kalit = 'sessiya:42' AND tugash > now();Natija:
CREATE TABLE
INSERT 0 1
qiymat
--------
aziz
(1 row)Ishlaydi. Lekin Redis'ning o'z imkoniyatlari bor: kalitning avtomatik o'chishi (TTL), navbatlar, ro'yxatlar, juda kichik kechikish. Postgres'dagi jadval buni bermaydi — tugagan sessiyani kimdir o'chirib turishi kerak.
2.4 Wide-column: ulkan yozuv oqimi
Wide-column (keng ustunli) baza — Cassandra, ScyllaDB. Ma'lumot ko'plab serverlarga bo'lib tashlanadi, har qator kaliti bo'yicha qaysi serverda turishi aniq. Sekundiga yuz minglab yozuvni ko'taradi va bitta server o'chsa ham ishlayveradi.
Narxi katta: jadvalni oldindan savollarga qarab loyihalash kerak. "Foydalanuvchining oxirgi 50 xabari" so'rovi tez, lekin oldindan rejalashtirilmagan savol (masalan, "hamma xabarlarda 'osh' so'zi") juda qiyin. Birlashtirish (JOIN) yo'q. Bunday bazani kanon sinamadi — u bitta noutbuk uchun emas, o'nlab server uchun.
2.5 Graph: bog'lanishlarning o'zi asosiy
Graph (graf) baza — Neo4j. Ma'lumot tugunlar (odam, shahar, mahsulot) va ular orasidagi qirralar ("do'st", "yashaydi", "sotib oldi"). Savol: "Ali'ning do'stlarining do'stlari ichida Toshkentda yashaydigan dasturchilar". Relatsion bazada bu bir necha marta o'z-o'ziga birlashtirish bo'ladi, graf bazada — bitta yurish.
Postgres'da daraxt va graflarni rekursiv so'rov bilan yurish mumkin. Kanon vazifalar dagi kichik vazifalar daraxtini aynan shunday o'qiydi (Rekursiv CTE darsida). Graf kengaytmasi Apache AGE esa postgres:18 image'ida yo'q (kanon tekshirdi, pastda).
2.6 Time-series: vaqt bo'yicha o'lchovlar
Time-series (vaqt qatori) baza — sensor ko'rsatkichi, server yuklamasi, valyuta kursi kabi "vaqt → qiymat" yozuvlari uchun. Ular asosan qo'shiladi, deyarli o'zgarmaydi va vaqt oralig'i bo'yicha o'qiladi. Vakillar: TimescaleDB (Postgres kengaytmasi), InfluxDB, Prometheus.
Kanon oddiy jadvalda 1-oktabrdan 2-oktabrgacha har soatlik "harorat"ni yaratib, kunlik o'rtachani hisobladi:
CREATE TABLE t06_olchov (vaqt timestamptz NOT NULL,
harorat numeric(4,1));
INSERT INTO t06_olchov
SELECT t, 15 + 10 * sin(extract(epoch FROM t) / 3600)
FROM generate_series('2026-10-01'::timestamptz, '2026-10-02',
'1 hour') t;
SELECT date_trunc('day', vaqt) AS kun, round(avg(harorat), 1)
FROM t06_olchov GROUP BY 1 ORDER BY 1;Natija:
CREATE TABLE
INSERT 0 25
kun | round
------------------------+-------
2026-10-01 00:00:00+00 | 14.6
2026-10-02 00:00:00+00 | 22.2
(2 rows)25 ta o'lchov yozildi, ikki kunlik o'rtacha chiqdi. +00 — vaqt UTC'da ko'rsatilgani (kanon serverining sukut zonasi). Zona natijaga ta'sir qiladi: xuddi shu blok Toshkent zonasidagi serverda (biz ishga tushirdik, PG 17.6) — kunlar +05 bilan chiqdi, ikkinchi kunning o'rtachasi esa 22.2 emas, 23.7 bo'ldi. Sabab: date_trunc('day', …) kun chegarasini sessiya zonasida qo'yadi, shuning uchun qatorlar kunlarga boshqacha bo'linadi. Buni SQL'da sana va vaqt zonalari darsida chuqur ko'ramiz. Milliardlab o'lchovda maxsus baza siqish va avtomatik eskirgan ma'lumotni o'chirish beradi. Bir necha million qatorgacha Postgres'ning o'zi bemalol yetadi.
2.7 Qidiruv: matn ichidan topish
Qidiruv (search) baza — Elasticsearch, OpenSearch, Meilisearch. Matnni so'zlarga ajratib, "teskari indeks" quradi: har so'z qaysi hujjatlarda bor. Xatoli yozuvni topish, natijani muvofiqligi bo'yicha saralash, filtr panellari — shu bazalarning ishi.
Postgres'da ham to'liq matnli qidiruv (full-text search) bor:
SELECT to_tsvector('simple', 'Bozordan kartoshka va piyoz olish')
@@ plainto_tsquery('simple', 'kartoshka piyoz') AS topildi;Natija:
topildi
---------
t
(1 row)Topildi. Lekin 'simple' sozlamasi so'zni faqat aynan solishtiradi: o'zbekcha uchun o'zak ajratish (stemming) Postgres'da yo'q — "bozor" so'rovi "Bozordan" ni topmaydi. Ingliz, rus va boshqa ko'p tillar uchun lug'atlar bor. Matnli qidiruvni Indeks turlari: GIN, GiST, BRIN va pg_trgm darsida chuqurlashtiramiz.
2.8 Vektor: ma'no bo'yicha qidirish
Vektor baza — AI davrining yangi turi. Matn yoki rasm sun'iy intellekt modeli orqali sonlar massiviga (embedding) aylantiriladi. Ma'nosi yaqin matnlarning sonlari ham yaqin bo'ladi. Savol: "shu savolga ma'nosi eng yaqin 5 ta hujjat". AI yordamchilar va semantik qidiruv shu asosda ishlaydi. Vakillar: pgvector (Postgres kengaytmasi), Qdrant, Pinecone.
Masalan, IlmHamroh saytidagi kurs bo'yicha AI yordamchi dars bo'laklarini aynan embedding'lar bilan topadi. pgvector'ni 27-qismda o'rganamiz.
Tekshirib ko'ring: Qaysi tur mos: (a) taksi ilovasida haydovchilarning har 5 soniyadagi koordinatasi, (b) "siz bilishingiz mumkin bo'lgan odamlar" tavsiyasi, (c) foydalanuvchi sessiyasi 30 daqiqaga?
Javob
(a) time-series — vaqt bo'yicha uzluksiz yoziladigan o'lchovlar (koordinata uchun PostGIS kabi geo-kengaytma ham kerak bo'ladi). (b) graph — "do'stning do'sti" bog'lanishlar bo'yicha yurish. (c) key-value — kalit (sessiya ID) bo'yicha tez o'qish va avtomatik o'chish (TTL). Lekin kichik ilovada uchalasini ham PostgreSQL ko'tara oladi — maxsus baza hajm o'sganda kerak bo'ladi.
3. SQL vs NoSQL: haqiqiy farqlar
3.1 To'rt asosiy farq
"SQL vs NoSQL" deganda odatda relatsion bazani document yoki key-value baza bilan solishtirishadi. Haqiqiy farqlar:
| Relatsion (SQL) | Ko'p NoSQL bazalar | |
|---|---|---|
| Sxema | yozishda tekshiriladi | o'qishda, ilova kodida |
| Bog'lanish | JOIN, tashqi kalit | ichma-ich hujjat yoki ilova kodida |
| Tranzaksiya | bir nechta jadvalda, kuchli | ko'pincha bitta hujjat ichida |
| Masshtablash | avval bitta katta server | boshidan ko'p serverga |
Sxema. Relatsion bazada noto'g'ri qator bazaga kirmaydi. Document bazada hammasi kiradi — tekshiruv ilovaga qoladi. Boshida bu tezlik beradi, bir yildan keyin esa bazada uch xil shakldagi "foydalanuvchi" yotgan bo'ladi.
Tranzaksiya. "Aziz hisobidan 30 000 so'm ayir, Dilnoza'ga qo'sh" — ikkalasi ham bo'lishi yoki ikkalasi ham bo'lmasligi kerak. Relatsion bazalar buni o'nlab yillardan beri kafolatlaydi. Bu kafolatni ACID, BASE, CAP va PACELC darsida ko'ramiz.
Masshtablash. Ma'lumot bitta serverga sig'may qolsa, uni ko'p serverga bo'lish kerak. Ko'p NoSQL bazalar shu uchun yaratilgan. Relatsion bazani bo'lish ham mumkin, lekin murakkabroq.
3.2 Afsonalar
- "NoSQL tezroq." Tezlik savolga bog'liq. Kalit bo'yicha bitta qiymat — Redis juda tez. "Har oy nechta vazifa bajarilgan, foydalanuvchi bo'yicha" — relatsion baza indeks va JOIN bilan yaxshiroq.
- "NoSQL'da sxema yo'q." Sxema baribir bor — faqat u bazada emas, kodingizda yashiringan. MongoDB'da ham sxema tekshiruvini yoqish mumkin.
- "SQL masshtablanmaydi." Bitta zamonaviy Postgres serveri yuzlab gigabayt va sekundiga minglab so'rovni ko'taradi. Ko'p startap bu chegaraga hech qachon yetmaydi.
- "Endi hamma NoSQL ishlatadi." Raqamlar boshqacha — keyingi bo'limda.
3.3 Dasturchilar nimani ishlatadi
Stack Overflow har yili dasturchilar so'rovnomasini o'tkazadi. 2025-yilgi natijada professional dasturchilarning qaysi qismi qaysi bazani ishlatganini ko'ring:
- PostgreSQL58,2 %
- MySQL39,6 %
- SQLite36,9 %
- MS SQL Server30,9 %
- Redis30,7 %
- MongoDB24,3 %
Manba: Stack Overflow Developer Survey 2025, Technology — Databases (survey.stackoverflow.co/2025/technology, 2026-10-24 da tekshirildi)
Nimaga qarang: birinchi to'rttasi — relatsion. Yig'indisi 100 dan oshadi, chunki bitta dasturchi bir necha baza ishlatadi. Redis va MongoDB ham keng tarqalgan, lekin ko'pincha relatsion bazaning yonida, uning o'rnida emas.
4. Polyglot persistence
4.1 Bir ilovada bir nechta baza
Polyglot persistence ("ko'p tilli saqlash") — har ma'lumot turini o'ziga eng mos bazada saqlash. Atamani 2011-yilda Martin Fowler ommalashtirgan. Odatiy onlayn do'kon sxemasi:
flowchart LR
I[Ilova] --> P[(PostgreSQL<br/>buyurtma, to'lov)]
I --> R[(Redis<br/>kesh, sessiya)]
I --> E[(Qidiruv bazasi<br/>mahsulot qidiruvi)]
P -. nusxa .-> ENimaga qarang: asosiy, aniq bo'lishi kerak bo'lgan ma'lumot (buyurtma, pul) PostgreSQL'da. Redis'da yo'qolsa ham qayta tiklanadigan narsa (kesh). Qidiruv bazasi esa Postgres'dagi mahsulotlarning nusxasini saqlaydi — nuqtali chiziq "nusxalanadi" degani.
4.2 Narxi
Har yangi baza — yangi xarajat:
- Sinxronlash. Mahsulot narxi Postgres'da o'zgardi, qidiruv bazasiga yetib bormadi — mijoz eski narxni ko'radi. Ikki bazani bir xil holatda ushlab turish — alohida murakkab vazifa.
- Operatsiya. Har baza uchun zaxira, monitoring, yangilash, xavfsizlik sozlamasi kerak.
- Bilim. Jamoa har bazani chuqur bilishi kerak, aks holda kechasi soat 3 da kelgan xatoni hech kim tuzata olmaydi.
Shuning uchun ko'p tajribali jamoalar qoidasi: bitta bazadan boshlang va ikkinchisini faqat o'lchangan ehtiyoj bilan qo'shing.
4.3 "Postgres yetadimi?" — kengaytmalar
PostgreSQL'ning kuchli tomoni — kengaytmalar (extensions): bazaga yangi turlar, indekslar va funksiyalar qo'shadigan plaginlar. Kanon postgres:18 rasmiy Docker image'ida qaysilari borligini tekshirdi:
SELECT name FROM pg_available_extensions
WHERE name IN ('vector', 'age', 'timescaledb', 'postgis',
'pg_trgm', 'ltree', 'hstore', 'pg_stat_statements')
ORDER BY 1;Natija:
name
--------------------
hstore
ltree
pg_stat_statements
pg_trgm
(4 rows)To'rttasi bor: hstore (kalit-qiymat), ltree (daraxt yo'llari), pg_trgm (o'xshash matn qidiruvi), pg_stat_statements (sekin so'rovlarni topish). vector (pgvector), age (graf), timescaledb, postgis (geografiya) — rasmiy image'da yo'q: ular uchun alohida image yoki o'rnatish kerak. Kanon ularni sinamadi.
Tekshirib ko'ring: Kichik internet-do'kon 2 000 ta mahsulot bilan ishga tushmoqda. Dasturchi "qidiruv uchun Elasticsearch, kesh uchun Redis, asosiy baza — MongoDB" deb taklif qildi. Qanday savol berasiz?
Javob
"Bu bazalarning har biri qaysi o'lchangan muammoni hal qiladi?" 2 000 mahsulotni Postgres'ning o'z matn qidiruvi va pg_trgm bemalol topadi. Kesh hali kerakmi — sekinlik o'lchanmagan. Buyurtma va to'lovlarda tranzaksiya muhim — bu relatsion bazaning kuchli tomoni. Uchta baza = uchta zaxira, uchta monitoring va sinxronlash muammosi. Boshlash uchun bitta PostgreSQL, keyin raqamlar bilan qaror.
5. Qanday tanlash kerak
5.1 Savollar ketma-ketligi
Baza tanlashda "qaysi biri zamonaviy?" emas, "ma'lumotim qanday va unga qanday savol beraman?" deb so'rang:
flowchart TD
A[Yangi loyiha] --> B{Ma'lumotlar<br/>bog'langanmi?}
B -- ha --> P[PostgreSQL]
B -- yo'q --> C{Faqat kalit<br/>bo'yicha o'qish?}
C -- ha --> K[Key-value]
C -- yo'q --> P
P --> D{O'lchangan<br/>muammo bormi?}
D -- yo'q --> Q[Postgres bilan qoling]
D -- ha --> M[Maxsus baza qo'shing]Nimaga qarang: deyarli hamma yo'l PostgreSQL'ga keladi. Maxsus baza — oxirgi qadam va faqat "o'lchangan muammo" bo'lsa.
5.2 Maxsus baza qachon kerak
- Redis: juda tez kesh, sessiya, rate limiting, navbat; ma'lumot qayta tiklanadigan bo'lsa.
- MongoDB: hujjat shakli tez-tez o'zgaradigan, bog'lanishlari kam ma'lumot (kontent, log, katalog).
- Cassandra/ScyllaDB: sekundiga yuz minglab yozuv, bir necha ma'lumot markazi.
- Elasticsearch/OpenSearch: murakkab matn qidiruvi, filtrlar, millionlab hujjat.
- Neo4j: asosiy savollar — bog'lanishlar bo'yicha chuqur yurish.
- Qdrant, Pinecone: juda ko'p vektor; kichik hajmda pgvector yetadi.
6. SQL qadami: vazifalar uchun baza tanlovi
Bu darsda kod va commit yo'q. Lekin kanon qarorini asoslaymiz. vazifalar ma'lumotlari:
| Ma'lumot | Bog'lanish | Tanlov |
|---|---|---|
| foydalanuvchi, vazifa | vazifa → egasi | relatsion |
| teglar | vazifa ↔ teg (ko'p-ko'p) | relatsion |
| izohlar, tarix | vazifaga | relatsion |
| sessiya, kesh | yo'q | hozircha kerak emas |
Hamma asosiy ma'lumot bog'langan, hisobot kerak ("bu hafta nechta vazifa bajarildi"), ikki foydalanuvchi bir vaqtda yozadi. Demak — PostgreSQL. Redis (kesh, sessiya) va MongoDB'ni 27-qismda alohida ko'ramiz — vazifalar ga ular hozir ehtiyoj emas.
7. Ko'p uchraydigan xatolar
7.1 Bazani reklamaga qarab tanlash
"Katta kompaniya X ishlatadi" — sizda ularning muammosi yo'q. Ularning milliardlab foydalanuvchisi va yuzlab muhandisi bor. Sizda esa 100 foydalanuvchi va bitta dasturchi.
7.2 "Sxemasiz" ni "loyihalashsiz" deb tushunish
Document bazada ham hujjatlar shaklini oldindan o'ylash kerak. Aks holda bir yildan keyin user.phone, user.telefon, user.contact.phone — uch xil maydon bir xil ma'lumot uchun yotadi.
7.3 Keshni asosiy baza qilish
Redis ma'lumotni xotirada saqlaydi. Sozlamaga qarab, server qayta yonganda ma'lumotning bir qismi yo'qolishi mumkin. Pul, buyurtma, foydalanuvchi — keshda emas, asosiy bazada.
7.4 Ikki bazani "o'zi sinxron bo'ladi" deb o'ylash
Postgres'ga yozib, keyin qidiruv bazasiga yozish — ikkinchi yozuv yiqilsa, bazalar bir-biridan farq qiladi. Bunga alohida naqshlar kerak (navbat, "outbox"). Ularni kursning keyingi qismlarida ko'ramiz.
8. Mashqlar
Mashqlar kurs/mashqlar/26/06-db-turlari/ da.
1-mashq (oson): juftlang
Har vazifaga baza turini tanlang: relatsion, document, key-value, graph, time-series, qidiruv, vektor.
- Bank o'tkazmalari va hisob qoldiqlari.
- "Shu savolga ma'nosi yaqin dars bo'laklari" (AI yordamchi).
- Server CPU yuklamasi har 10 soniyada.
- Kirish urinishlari soni 1 daqiqa uchun (rate limiting).
- Kitoblar katalogida "Navoiy g'azallari" so'rovi bo'yicha qidiruv, xatoli yozuv bilan ham.
Yechim
- Relatsion — tranzaksiya va aniqlik muhim.
- Vektor — embedding bo'yicha ma'no yaqinligi.
- Time-series — vaqt bo'yicha uzluksiz o'lchov.
- Key-value — kalit (
urinish:IP) va avtomatik o'chish. - Qidiruv — matn indeksi, xatoli yozuvni topish, muvofiqlik bo'yicha saralash.
2-mashq (o'rta): taklifni baholang
Do'stingiz «Bahor» oshxonasi uchun buyurtma ilovasini yozmoqda: menyu (30 taom), buyurtmalar, mijozlar, kunlik hisobot. U "MongoDB tezroq, hamma narsani unda saqlayman" demoqda. To'rtta savol bilan javob bering: ma'lumot bog'langanmi, tranzaksiya kerakmi, hisobot qanday, hajm qancha?
Yechim
- Bog'langanmi: ha — buyurtma mijozga va menyudagi taomlarga ishora qiladi. Taom narxi o'zgarsa, hamma joyda to'g'ri bo'lishi kerak.
- Tranzaksiya: ha — buyurtma va to'lov birga yozilishi kerak.
- Hisobot: "kunlik tushum, taom bo'yicha" — guruhlash va birlashtirish, relatsion bazaning kuchli tomoni.
- Hajm: kuniga yuzlab buyurtma — bitta Postgres uchun juda kichik.
Xulosa: PostgreSQL. MongoDB xato emas, lekin bu ma'lumotga uning afzalligi yo'q, kamchiligi (bog'lanish va hisobot) esa bor.
3-mashq (qiyin): hujjatni yangilash narxi
Uchta vazifa hujjat shaklida, egasining shahri har hujjat ichida. Yechim faylida ular jsonb ustunli jadvalga yozilgan. Ikki savolga javob bering:
- "bozor" tegli hujjatlarning matni va egasi ismi qaysi?
- Dilnoza Buxoroga ko'chdi. Hujjat modelida nechta qatorni yangilash kerak? Relatsion modelda-chi?
Yechimdagi SQL: @> — "ichida shu bo'lak bormi" (yuqorida «Document: bitta obyekt — bitta hujjat» bo'limida), jsonb_set — hujjat ichidagi bitta qiymatni almashtiradi.
Yechim
SELECT id, hujjat->>'matn' AS matn, hujjat->'egasi'->>'ism' AS ism
FROM hujjatlar
WHERE hujjat @> '{"teglar": ["bozor"]}'
ORDER BY id;
UPDATE hujjatlar
SET hujjat = jsonb_set(hujjat, '{egasi,shahar}', '"Buxoro"')
WHERE hujjat->'egasi'->>'ism' = 'Dilnoza';
SELECT hujjat->'egasi'->>'shahar' AS shahar, count(*)
FROM hujjatlar GROUP BY 1 ORDER BY 1;Natija (PostgreSQL 17.6):
id | matn | ism
----+---------------------+---------
1 | Bozordan meva olish | Dilnoza
3 | Kartoshka olish | Sardor
(2 rows)
shahar | count
-----------+-------
Buxoro | 2
Samarqand | 1
(2 rows)Hujjat modelida Dilnoza'ning har hujjati yangilandi — bu yerda 2 ta, haqiqiy ilovada yuzlab bo'lishi mumkin. Bittasi tushib qolsa — Dilnoza ikki shaharda "yashaydi". Relatsion modelda shahar foydalanuvchilar jadvalida bitta qatorda — 1 ta yangilash. Hujjat modeli o'qishni osonlashtiradi (hammasi bitta joyda), yangilashni esa qiyinlashtiradi.
4-mashq: SQL qadami — o'z loyihangiz
Relatsion model darsining 4-mashqidagi loyihangiz uchun «SQL qadami» bo'limidagi kabi jadval tuzing: ma'lumot, bog'lanish, tanlangan baza turi. Bitta qatorda "hozircha kerak emas" bo'lgan narsa bo'lsin va sababini yozing.
Yechim
Namuna (portfolio): loyihalar, postlar, xabarlar — relatsion (post ↔ teg bog'lanishi, "eng ko'p o'qilgan postlar" hisoboti). Post matni bo'yicha qidiruv — hozircha Postgres'ning matn qidiruvi yetadi (postlar soni yuzta ham emas). Sahifa keshi — hozircha kerak emas: sekinlik o'lchanmagan. Asosiy fikr: har "keyinroq" qatorida qaysi raqam o'zgarsa qaror qayta ko'rilishini yozing ("postlar 10 000 dan oshsa").
9. Real ishda
- Qayerda: O'zbekistondagi ish e'lonlarida backend vakansiyalarining ko'pida PostgreSQL yoki MySQL, ko'pincha Redis bilan birga so'raladi. MongoDB — ayniqsa Node.js loyihalarida uchraydi. Elasticsearch — katta qidiruvli xizmatlarda (marketplace, e'lonlar sayti).
- Arxitektura muhokamasi: jamoada "qaysi baza?" savoli kelganda kuchli dasturchi brend nomini emas, ma'lumot shakli, savollar, hajm va jamoa tajribasini so'raydi.
- Intervyu savollari: "SQL va NoSQL farqi?", "MongoDB'ni qachon tanlaysiz?", "Polyglot persistence nima va uning narxi?". Yaxshi javobda "bog'liq" so'zidan keyin aniq mezon bor.
Xulosa
- Bazalar turlari: relatsion, document, key-value, wide-column, graph, time-series, qidiruv, vektor — har biri o'z savoliga tez javob beradi.
- NoSQL — "faqat SQL emas"; asosiy farqlar: sxema qayerda, bog'lanish qanday, tranzaksiya qamrovi, masshtablash usuli.
- PostgreSQL jsonb, kalit-qiymat jadval, vaqt qatorlari va matn qidiruvini ham ko'taradi; ba'zi kengaytmalar (pgvector, PostGIS) rasmiy image'da yo'q.
- Polyglot persistence foydali, lekin har baza — sinxronlash, operatsiya va bilim narxi.
- Qoida: bitta PostgreSQL'dan boshlang, maxsus bazani o'lchangan ehtiyoj bilan qo'shing.
Keyingi dars: ACID, BASE, CAP va PACELC — bazalar qanday kafolat beradi va taqsimlangan tizimda nimadan voz kechiladi.
Manbalar
- Stack Overflow Developer Survey 2025 — Technology: https://survey.stackoverflow.co/2025/technology
- Martin Fowler — PolyglotPersistence (2011): https://martinfowler.com/bliki/PolyglotPersistence.html
- PostgreSQL 18 hujjati — JSON Types: https://www.postgresql.org/docs/18/datatype-json.html
- PostgreSQL 18 hujjati — Full Text Search: https://www.postgresql.org/docs/18/textsearch.html
- PostgreSQL 18 hujjati — UNLOGGED (CREATE TABLE): https://www.postgresql.org/docs/18/sql-createtable.html
Izohlar (0)
Izoh yozish uchun kiring.
- Hozircha izoh yo'q. Birinchi bo'ling!