🧠 PostgreSQL: Architecture haqida
Assalomu alaykum, hurmatli dasturchilar! Bugun sizlar bilan PostgreSQL arxitekturasi mavzusini ko‘rib chiqamiz.
Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

💡 PostgreSQL umumiy ishlash prinsipi:
PostgreSQL Client-Server modeli asosida ishlaydi. Client tomoni: Backend dasturlar (PHP, Yii2, Laravel, Java), pgBouncer kabi ilovalar orqali Postgresga bog'lanish amalga oshiriladi va SQL so‘rovlar yuboriladi. Server tomoni: Turli xil jarayonlar orqali SQL so‘rovlar qabul qilinadi va qayta ishlanadi.

🛠 Server tomonidagi asosiy jarayonlar:

1. Postmaster Process
- Postmaster barcha kiruvchi ulanishlarni tinglaydi va ular bilan ishlaydi.
- Kiruvchi clientlar pg_hba.conf fayli orqali autentifikatsiya qilinadi.
- Har bir yangi ulanilgan client uchun yangi alohida process ochiladi.
- PostgreSQL odatda har bir ulanish uchun alohida process ochadi (process-per-connection modeli asosida).

Clientni tomonidan ip, port, user, ma'lumotlar bazasi nomi tekshiriladi. PostgreSQL default ishlashida har bir ulanish yangi process ochiladi va ushbu ulanishlar yopilgandan keyin resurslar (connectionlar) butunlay tozalanadi.

2. Backend Process
Postmaster har yangi ulanish uchun yangi backend process ochadi. Har bir yangi ulanilgan client unique PID (id) ga ega bo'ladi.

Backend process quyidagilarni bajaradi:
- SQL query’ni qabul qiladi.
- Sintaksis tahlil qiladi va query plan tayyorlaydi.
- Natijani hisoblaydi va clientga qaytaradi.
- Har bir HTTP so‘rov (masalan Laravel’da) alohida connection hosil qiladi.

Clientlarning real vaqt holatini ko‘rish:

SELECT * FROM pg_stat_activity;

(pg_stat_activity haqida keyingi maqolalarda to‘liq o‘rganamiz.)

3. Shared Memory
Postgresqlda tez tez ishlatiladigan ma'lumotlar uchun ajratilgan xotira maydoni. OS (operation system) - tomonidan taqdim etilgan maxsus xotira xisoblanadi. Postgresql multi-process arxitekturasi asosida ishlaydi. Multi-process - yani bir vaqtda bir qancha clientlar parallel ishlay olishadi. Aynan ushbu xolatda ma'lumotlarni yaxlitligini ta'minlash maqsadida bazi bir jarayonlar aynan ushbu ajratilgan (shared memory) xotirada bajariladi. postgresql.conf faylda shared_buffers deb nomlangan key mavjud. share_buffers ga qiymat sozlash orqali xotira maydoni aniqlanadi. Odatda Serverni RAMni 25-40% qismini ajratish yetarli hisoblanadi. Masalan 16GB RAM bo'lsa shundan 4GB ajratiladi. Bu narsani ajratishda ma'lumotlar bazasidagi yuklamaga qarash tavsiya etiladi. Connectionlar soni ham juda muhim hisoblanadi.

✅ Foydasi:
- Tez tez ishlatiladigan ma'lumotlar cachelanadi.
- I/O (diskka yozish va o'qish) kamayadi

4. WAL (Write-Ahead Log)
Barcha yangi ma''lumotlar, yangilangan ma'lumotlar, o'chirilgan ma'lumotlar barchasi shu WALga yoziladi.
Oddiy qilib aytganda:
- Har qanday o‘zgarish (insert, update, delete) birinchi navbatda WAL log fayliga yoziladi.
- Shundan keyingina ma'lumotlar asosiy ma'lumotlar fayliga (disk faylga) yoziladi.
- Bu jarayon avariya (masalan, server to'satdan o'chib qolsa) holatida oson va tez tiklanish imkonini beradi.
WAL haqida batafsil keyingi maqolalarimizda tanishib chiqamiz.

5. DATA FILES - faol ma'lumotlar bazasi diskda saqlanadi joyi hisoblanadi.

6. Background Process
PostgreSQL bir nechta muhim background jarayonlarga ega:
- Autovacuum — ma'lumotlarni tozalash va statistikani yangilash.
- WAL Writer — WAL fayllarni diskka yozish.
- Background Writer — buffer’dan diskka ma'lumotlarni yozish.
- Checkpointer — muhim xotira ma'lumotlarini saqlab turish.
- Archiver — WAL fayllarni arxivlash.
(Background Process’lar haqida ham alohida maqolalar tayyorlaymiz.)

7. Transaction Manager.

✅ Xulosa:
PostgreSQL kuchli, ishonchli va barqaror ishlashi uchun har bir komponent muhim rol o‘ynaydi. Har bir qismni chuqur tushunish — tizimni yanada samarali boshqarishga yordam beradi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: WAL haqida

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan PostgreSQL WAL mavzusini ko‘rib chiqamiz.

Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

WAL (Write-Ahead Logging) – Ma'lumotlarni o‘zida saqlab turadi.
Misol uchun, biror foydalanuvchi ma'lumotlar bazasida INSERT, UPDATE, DELETE amallaridan birini bajarmoqchi bo‘lsa, birinchi bo‘lib WAL logga yoziladi. Shundan keyingina diskka yoziladi.

📁 Barcha loglar pg_wal papkasida saqlanadi

Maqsadi:
Masalan, client tomonidan INSERT qilindi. Ma'lumotlar diskka yozilishiga ulgurmay, server ishdan chiqdi.
Serverni qayta ishga tushirilganda — pg_wal dan oxirgi ma’lumotlar tiklanadi.

➡️ Foydali tomoni: Crash recovery.

🧩 Keyingi ishlatilish maqsadi — REPLICA
Masalan, 1 ta master DB server va 1 ta slave DB server mavjud.

Master server: INSERT, UPDATE, DELETE (yozish).

Slave server: SELECT (o‘qish).

📌 Master’ga yangi ma’lumotlar qo‘shilsa, slave serverga yuborish kerak — bu jarayon WAL orqali bajariladi.

✅ WAL – master va slave o‘rtasida ma’lumotlar yaxlitligini ta’minlaydi.

⚙️ Muhim konfiguratsiyalar:
wal_buffers - ma'lumotlarni diskka yozilgunicha wal loglari saqlanib turish uchun belgilanadigan xotira hajmi RAMdan ajratiladi.

wal_level - wal loglarida qanday ma'lumotlar saqlanish kerakligini belgilab beradi. 3 xil turi mavjud 1- minimal faqatgina crash recovery uchun 2 - replica replica va crash recovery uchun default qiymati shu 3 - logical.

archive_mode = on qilib qo'ysak wal fayllar arxivlanib saqlab boriladi saqlanish joyini

archive_command ga berish kerak bo'ladi bash script orqali.

max_wal_size va min_wal_size diskda saqlanish uchun kerak hajmni nazorat qilib turadi.

wal_keep_size - Wal fayllarni hajmini belgilab beradi.

🔄 Ishlash sxemasi:
1️⃣ Client tomonidan INSERT INTO SQL query yuboriladi
2️⃣ Bu query natijasi wal_buffer (RAM) ga yoziladi
3️⃣ Keyin wal_buffer dan pg_wal papkasidagi WAL faylga — diskka yoziladi
4️⃣ Bu vaqtda ma’lumotlar hali diskka yozilmagan bo‘lishi mumkin

🛠 Diskka yozishni esa checkpointer boshqaradi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Checkpoint haqida

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan PostgreSQL Checkpoint mavzusini ko‘rib chiqamiz.

Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

📌 Checkpoint nima?

Checkpoint - Ma'lumotlar bazasida WAL log faylga pg_wal papkasidagi ma'lumotlarni diskka yozish jarayonini boshqaradi. checkpoint_timeout - yani qancha vaqtda checkpoint qilib turish kerakligini aniqlaydi yani WALga yozilgan ma'lumotlarni qancha vaqtda diskka sinxron ko'chirib qo'yish kerakligini belgilab beradi default 5min bo'ladi. Har 5 minutda WALdan ma'lumotlarni diskka yozib turadi. Yozib bo'lingan ma'lumotlarni pg_wal o'chirib tashlaydi.

postgresql.conf fayldagi sozlamasi:

checkpoint_timeout = 45s #default=5min
max_wal_size = 64MB #2GB
min_wal_size = 32MB # 2MB

har 45 sekundda checkpoint ishlab waldagi ma'lumotlarni diskka yozib turadi. Bazida checkpoint vaqti 10min qo'yilsa ushbu xolatda max_wal_size=64MB yani wal fayllarni hajmi 64MB ga yetganida checkpoint default o'zi ishga tushadi va wal segmentlarni (fayllarni) tozalab tashlaydi. Postgresql min_wal_size=32MB 32MB wal fayllarni oldindan tayyorlab qo'yadi. Tizimda kerak bo'lmasa ham WAL fayllar minimal 32MB lik faylar saqlab turiladi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: SELECT query haqida gaplashamiz.

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan PostgreSQL SELECT querylarni mavzusini ko‘rib chiqamiz.

Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

💡 Kundalik hayotda postgresqlda select query bilan ishlashda ko'pchilik ahamiyat bergan bo'lsa kerak. Birinchi sql select query ishlaganida ketgan vaqt keyingilari ishlagan vaqtiga nisbatan ko'proq vaqt ketadi birinchisida. Bu jarayonni yoritib o'tmoqchimiz. Birinchi select query ishlaganida ma'lumotlarni diskdan o'qib oladi. Qaytarilgan natija esa aynan shared_buffers ga saqlanadi vaqtincha. Keyingi safar esa ushbu query orqali aynan shu RAMda saqlangan ma'lumot qaytariladi natija oldingisiga qaraganda tezro ma'lumot olinadi. Deylik select birinchi marta ishladi qaytarilgan ma'lumotlar RAMga saqlanadi. Keyingi safar ikkinchi marta select ishlashidan oldin jadvalga ma'lumotlar qo'shildi va yana select query 2 marta ishga tushirilsa ma'lumotlarni ayrimlarini diskdan o'qib oladi va RAMga joylab umumiy RAMda saqlangan ma'lumotlarni qaytarib beradi. Buni sinab ko'rish uchun amaliy misol keltirib o'tamiz

✅ Tekshiruv uchun:

EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM employees limit 1000;

📊 ushbu so'rovni natijasi:

"Limit (cost=0.00..33.76 rows=1000 width=239) (actual time=0.409..0.719 rows=1000 loops=1)"
" Buffers: shared read=15"
" -> Seq Scan on employees (cost=0.00..13504.05 rows=400005 width=239) (actual time=0.409..0.682 rows=1000 loops=1)"
" Buffers: shared read=15"
"Planning:"
" Buffers: shared hit=119 read=13"
"Planning Time: 1.696 ms"
"Execution Time: 0.794 ms"

" Buffers: shared read=15" - bu degani barcha ma'lumotlarni diskdan o'qib beryabdi. read berilsa demak ma'lumotlar to'g'ridan to'g'ri diskdan o'qilyabdi deb tushunsak bo'ladi. Bir marta sql so'rov bajarilganidan keyin postgresqlda natija shared_buffersda saqlab turiladi. Yuqoridagi queryni qayta bajarilsa read o'rniga hit qo'shiladi. hit - ma'lumotlarni endi shared_buffers dan olayotganini ko'rsatib beradi. So'rovni qayta bajarilganida olingan natija esa:

📊 qayta yuborilgan so'rovni natijasi:

"Limit (cost=0.00..33.76 rows=1000 width=239) (actual time=0.031..0.482 rows=1000 loops=1)"
" Buffers: shared hit=16"
" -> Seq Scan on employees (cost=0.00..13504.05 rows=400005 width=239) (actual time=0.028..0.262 rows=1000 loops=1)"
" Buffers: shared hit=16"
"Planning Time: 0.205 ms"
"Execution Time: 0.640 ms"

ushbu qismda " Buffers: shared hit=16" - ketyabdi. Bu shared_buffersda saqlanib qolgan natijani qaytaryabdi. Execution Time ham farq qilyabdi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: CSV import va ID sequence muammosi

Assalomu alaykum, hurmatli dasturchilar!
Bugun real holatdagi muammoni ko‘rib chiqamiz:
CSV fayllarni PhpStorm orqali import qilganda id_sequence yangilanmasligi.

📌 Muammo:

PhpStorm orqali .csv faylni databasega import qilsangiz, id maydonidagi SEQUENCE yangilanmasligi mumkin.

Masalan:

CSV faylda id qiymatlari bor (masalan, 1 dan 97100 gacha).
Ammo table_name_id_seq (ya’ni SERIAL yoki BIGSERIAL orqali avtomatik id beruvchi obyekt) yangilanmaydi. Natijada yangi ma’lumotlarni oddiy sql INSERT bilan qilmoqchi bo‘lsangiz, PostgreSQL duplicate key value violates unique constraint xatosini beradi.

🔍 Buni qanday aniqlaysiz?

SELECT * FROM table_name_id_seq;
last_value = 1 bo‘lsa, ammo jadvaldagi eng katta id = 97100 bo‘lsa — demak, SEQUENCE ortda qolgan!

🛠️ Yechimi: SEQUENCE’ni to‘g‘rilash:

Quyidagi SQL query orqali SEQUENCE’ni joriy maksimal idga moslab yangilaymiz:

SELECT setval(
pg_get_serial_sequence('table_name', 'id'),
COALESCE(max(id) + 1, 1)
)
FROM table_name;✅ Bu query table_name jadvalidagi eng katta idni topadi va table_name_id_seq ga moslab setval() orqali yangilaydi. Har doim iddan sequence last_value=id + 1 bo’ladi yani 1 katta bo’lishi kerak.


📌 Izoh:

pg_get_serial_sequence() — table_name jadvalidagi id ustuniga tegishli SEQUENCE nomini avtomatik oladi.

COALESCE(max(id) + 1, 1) — agar jadval bo‘sh bo‘lsa, 1 ni qaytaradi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Autovacuum haqida gaplashamiz (1-qism)

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan PostgreSQL Autovacuum mavzusini ko‘rib chiqamiz.
Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔸 Autovacuum — bu nima?
Autovacuum — VACUUM va ANALYZE buyruqlarini avtomatik ravishda orqa fonda bajarish. AUTOVACUUM yoqilsa, yangilangan yoki o‘chirilgan yozuvlarga ega bo‘lgan katta miqdordagi jadvallarni tekshirib boradi ularni statistikalarini yangilab boradi hajmi oshdi, indexlar qo'shildi va hokazo kabi statistikalarini.

✅ Bu tekshiruvlar ANALYZE deb ataladi, ya'ni statistik ma’lumotlarni to‘plash uchun kerak — bu esa query planner uchun muhim.
✅ Statistikalarni to‘plash uchun track_counts yoqilgan bo‘lishi kerak (default: yoqilgan). Shundagina AUTOVACUUMni ANALYZE qismi ishlaydi.

📌 Demak, Autovacuum maqsadlaridan biri statistikalarni yangilab borish ekan (ANALYZE).

🔸 Yana bir muhim vazifasi AUTOVACUUMNI:
UPDATE yoki DELETE amallari real ma’noda satrni o‘chirib yubormaydi, balki o‘chirilgan ma’lumotga delete flag qo‘yiladi. Yangi ma’lumot yangi versiya sifatida yoziladi. Shunday qilib barcha eski versiyalar dead tuple deb nomlanadi. Qisqasi delete yoki update natijasida yangilangan versiya saqlanadi ushbu versiyadan oldingi versiya esa dead-tuple qilib belgilanadi.

🧨 Dead tuple’lar diskda ortiqcha joy egallaydi va so‘rov samaradorligini pasaytiradi.
🔧 Autovacuum esa bu dead tuple’larni fonda tozalab boradi.

🔹 Autovacuum qanday ishlaydi?
Autovacuum daemon quyidagi ishlarni bajaradi:
VACUUM — dead tuple’larni o‘chiradi va joyni bo‘shatadi
ANALYZE — jadvallar uchun statistik ma’lumotlarni yangilaydi (query planner uchun)
🕒 U har bir jadvalni kuzatadi va belgilangan meyordan dead tuple (o'zgarishlar update va delete natijasida) ko‘payib ketsa, avtomatik ishga tushadi.

📁 postgresql.conf faylida AUTOVACUUMni yoqish:
autovacuum = on # default: on
autovacuum_naptime = 1min # Har 1 daqiqada jadvalni tekshiradi autovacuum jarayoni uchun (VACUUM va ANALYZE uchun)
📘 Biror real misol bilan tekshirib ko‘ramiz AUTOVACUUM jarayonini:

🔷 1. customer table qo‘shamiz:

CREATE TABLE customers (
id serial PRIMARY KEY,
name text,
email text
);
🔷 2. 10,000 ta yozuv kiritamiz:
INSERT INTO customers (name, email)
SELECT 'Customer ' i, 'customer' i || '@example.com'
FROM generate_series(1, 10000) AS s(i);
🔷 3. Endi barcha ma’lumotlarni UPDATE qilamiz:
UPDATE customers
SET name = name || ' Updated';
🔷 4. Dead tuple sonini ko‘ramiz:
SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 'customers';📌 n_dead_tup — dead tuple soni
📌 last_autovacuum — oxirgi autovacuum ishlagan vaqt

🔷 5. Autovacuum jarayonini logga tushishini faollashtiramiz: (postgresql.conf)
log_autovacuum_min_duration = 0
🔍 Logni kuzatish:
tail -f /var/log/postgresql/postgresql-XX-main.log
📄 Natija:
2025-05-04 16:27:27.766 +05 [96309] LOG: automatic vacuum of table "dev_test.public.customers": index scans: 1...

ushbu natija autovacuum ishlaganini ifodalaydi. Checkpoint ishlashini ham shu logdan ko'rib aniqlab olsak bo'ladi.

✅ Xulosa:
PostgreSQL’da Autovacuum — dead tuple ma’lumotlarni avtomatik tozalab boruvchi mexanizm hisoblanadi.
🧩 Dead tuple — bu UPDATE yoki DELETE natijasida o‘zgargan yoki o‘chirilgan, ammo fizik tarzda hali o‘chirilmagan eski yozuvlar hisoblanadi.

🧹 Autovacuum ushbu eski yozuvlarni tozalab:
- Diskda joyni bo‘shatadi
- So‘rovlar tezligini saqlab qoladi
- Statistik ma’lumotlarni ham yangilaydi (ANALYZE)

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Autovacuum haqida gaplashamiz (2-qism)

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan PostgreSQL Autovacuum mavzusini ko‘rib chiqamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️


📘 Amaliy misolda AUTOVACUUMni ko'rishda davom etamiz:

🧾 Logdan kuzatish: (1-shu sozlamani qilib postgres serverga restart bering)

VACUUM’ning logda chiqishi uchun:
log_autovacuum_min_duration = 0
postgresql.conf faylida autovacuumni sozlab ishlatib ko'ramiz.

🛠️ Birinchi qilinadigan ish — autovacuum yoqilganligini tekshirish:

autovacuum = on # Default ON
autovacuum_naptime = 1min # Har 1 daqiqada tekshiradi
autovacuum_vacuum_threshold = 50 #50 ta dead-tuple uchun ishlaydi
🚨 Lekin!
VACUUM hozirgi sozlamada 50da dead-tuple uchun ishlamaydi, chunki quyidagi sozlama mavjud:
autovacuum_vacuum_scale_factor = 0.2Bu degani:
Masalan jadvalda 10,000 ta satr bo‘lsa:
50 + 0.2 * 10000 = 2050 ta o‘zgarishdan keyin VACUUM ishlaydi. Yani man 2050ta dead-tuple hosil qilsam keyin ishga tushiriladi VACUUM.

✅ Ishlatib ko'rish uchun autovacuum_vacuum_scale_factor=0 qilib sozlaymiz (postgersql.conf).

🧪 UPDATE qilish 49 ta qatorni:

UPDATE customers
SET name = name || ' Updated'
WHERE id < 49;
Bu so'rov natijasida 49 ta dead tuple hosil bo'ladi.

Keyin quyidagini tekshiramiz:
SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 'customers';
📌 Hali VACUUM ishlamaydi, chunki 50 tadan kam.
UPDATE’ni yana bir marta ishlatamiz — 98 ta dead tuple bo‘ladi.
1 daqiqadan so‘ng VACUUM avtomatik ishlaydi.

tail -f /var/log/postgresql/postgresql-XX-main.log

🔄 VACUUM ishlaganidan so‘ng:

SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 'customers';
✅ n_dead_tup = 0 bo‘ladi — ortiqcha ma’lumotlar tozalandi.

📊 ANALYZE uchun sozlamalar:

autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.1
Jadvalda 10,000 ta satr bo‘lsa:
50 + 0.1 * 10000 = 1050 ta o‘zgarishdan keyin ANALYZE ishlaydi.

ANALYZE jadval statistik ma’lumotlarini yangilaydi — query planner uchun juda muhim!

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Normalization

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Normalization mavzusini ko‘rib chiqamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔎 Normalization — bu ma’lumotlar bazasida ortiqcha va takroriy ma’lumotlarni yo‘qotish, ularni tartibli va alohida jadvallarga ajratish usulidir.

4 ta asosiy shakli (forma) mavjud bo‘lib, biz bugun 1NF (First Normal Form) haqida gaplashamiz.

❌ Denormal shakl (1NF ga mos emas):

customers

id
name
adress
orders

+----+------+-----------+-------------------+
| id. | name | address | orders |
+----+------+-----------+-------------------+
| 1 | A | Toshkent | iPhone 13 Pro |
| 2 | B | Farg'ona | Redmi |
+----+------+-----------+-------------------+

📌 orders ustuni ko‘p qiymatli bo‘lishi yoki takrorlanish ehtimoli yuqori. Bu 1NF ga zid.

✅ 1NF ga mos tuzilma:
customers

id
name
address

+----+------+-----------+
| id | name | address |
+----+------+-----------+
| 1 | A | Toshkent |
| 2 | B | Farg'ona |
+----+------+-----------+

orders

id
customer_id
product

+----+--------------+-------------------+
| id | customer_id | product |
+----+--------------+-------------------+
| 1 | 1 | iPhone 13 Pro |
| 2 | 2 | Redmi |
+----+--------------+-------------------+

📌 Endi har bir ustun bitta qiymat saqlaydi, takrorlanishlar oldi olingan — bu 1NF normal formaga mos.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Normalization

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Normalization mavzusida davom etamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔎 Normalization — bu ma’lumotlar bazasida ortiqcha va takroriy ma’lumotlarni yo‘qotish, ularni tartibli va alohida jadvallarga ajratish usulidir.

PostgreSQLda 4 ta asosiy normal shakl mavjud. Bugun biz 2NF (Second Normal Form) haqida gaplashamiz.

⚠️ 2NF qanday ishlaydi?
✅ 1NF bajarilgan bo'lishi majburiy
🚫 Jadvalda composite primary key bo‘lsa-yu, qolgan ustunlar to‘liq bog‘liq bo‘lmasa, 2NF buziladi. Composite Primary key - yani bitta jadvalda birdan ortiq primary key joylashgan bo'lsayu lekin boshqa ustunlarni qiymati faqatgina 2 primary key ustundan bittasiga bog'liq bo'lsa ushbu xolatda 2NF shakl buzilgan xisoblanadi.

❌ 2NF ga mos emas jadval:
student_courses

student_id
course_id
student_name
course_name
mark

+------------+-----------+--------------+--------------+------+
| student_id | course_id | student_name | course_name | mark |
+------------+-----------+--------------+--------------+------+
| 1 | 2 | ALI | C++ | 9.0 |
| 2 | 1 | VALI | Postgres | 9.5 |
+------------+-----------+--------------+--------------+------+



📌 Bu yerda student_name — faqat student_idga,
course_name — faqat course_idga bog‘liq.
Ammo bu ustunlar student_id + course_id kompozit kalitiga to‘liq bog‘liq emas. mark esa student_id va course_id ustunlariga bog'liq. Shuning uchun bu 2NF emas.

✅ 2NF ga mos tuzilgan jadvallar:
students

+------------+--------------+
| student_id | student_name |
+------------+--------------+
| 1 | ALI |
| 2 | VALI |
+------------+--------------+

courses

+-----------+--------------+
| course_id | course_name |
+-----------+--------------+
| 1 | Postgres. |
| 2 | C++ |
+-----------+--------------+

link_student_courses

+------------+-----------+------+
| student_id | course_id | mark |
+------------+-----------+------+
| 1 | 2 | 9.0 |
| 2 | 1 | 9.5 |
+------------+-----------+------+

📌 Endi barcha ustunlar o‘z joyida va faqat kerakli kalitga bog‘langan — bu 2NF ga to‘liq mos.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Normalization & Denormalization

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Normalization & Denormalization mavzusida davom etamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔹 Normalization
3NF shakli mavjud. Bu forma bajarilishi uchun 1NF va 2NF yondashuvlari to‘liq bajarilishi kerak bo‘ladi.

🎯 Normalization Maqsadi:
🔸 Ma’lumotlarni qayta-qayta takrorlanishini oldini olish
🔸 Toza database arxitektura qurish
🔸 Ma’lumotlar bazasi hajmini kamaytirish
🔸 Ortiqcha yuklamalardan saqlash

🔹 Denormalization
Normalizationga qarama-qarshi yondashuv.

🎯 Maqsadi:
🔸 Struktura soddalashtirish
🔸 So‘rovlar tezligini oshirish
🔸 JOINlardan ko‘p foydalanmaslik
🔸 Ustunlar sonini oshirish, jadvallar sonini kamaytirish

🔹 Umumiy xulosa

Normalization - asosiy maqsad ma'lumotlarni qayta qayta takrorlanishini oldini olish va toza database arxitektura qurish qismlari uchun foydali. Ma'lumotlar bazasi hajmiga ham ta'sir qiladi Normalization qo'llanilsa. Ortiqcha ma'lumotlarni yuklashdan saqlaydi. Denormalization - ma'lumotlarni qayta qayta takrorlanishi haqida o'ylab o'tirmasdan struktura qurishga chaqiradi. Bu usul asosan SQL query ishlashini oshirish (tezlikni), jadvallar sonini kamro qilib jadvallardagi ustunlar sonini oshirishga qaratilgan. Natijada kattaroq sql querylarda JOINlar kam foydalaniladi. Umumiy xulosa tizim xolatiga qarab Normalization yoki Denormalizationdan foydalansak bo'ladi.

❓ Qachon qaysi biridan foydalanish tavsiya qilinadi?

✅ Normalization:
📈 Katta hajmli bazalar uchun shu strukturadan foydalanish
📝 Tez-tez insert qilinadigan tizimlar uchun
⚡️ Bajarilish vaqti kam bo'lgan sql querylar uchun

✅ Denormalization:
📊 Katta sql so'rovlar mavjud bo'lsa
📅 Hisobotlar uchun

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Monitoring query execute

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Monitoring query execute (pg_stat_activity) mavzusida davom etamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔹 pg_stat_activity

Postgresqlda bajariladigan sql querylarni holati haqida to'liq ma'lumot olish uchun ishlatiladi. Asosan ushbu usul bilan querylarni optimizatsiya qilishda ham foydalansak bo'ladi. Agar biz tomonimizdan yozilgan sql query execution time ortib ketsa yoki idle in transaction xolatiga tushib qolsa queryni qaytadan ko'rib chiqishimiz kerak bo'ladi. Katta tizimlarda asosiy rol ma'lumotlar bazasiga qaratilgan bo'lsa ushbu xolatda tizim sekinlasha boshlasa dastlabki qilinish kerak bo'lgan ishlardan biri bu ma'lumotlar bazasida bajarilyotgan sql querylar xolatini tekshirish bo'ladi. Oddiy SELECT sql query bilan ishlaydi:

SELECT
*
FROM pg_stat_activity;
🔄 Yuqoridag query natijasida ma'lumotlar bazasida bajarilyotgan barcha sql querylarni ko'rishimiz mumkin.

🔷 pid - process id. Har bir client uchun alohida unique id beriladi shu id process id deb nomlanadi.
🔷 state - sql query xolati haqida ma'lumot beradi. active, idle, idle in transaction, disabled
🔷 backend_start - client bilan postgresql o'rtasida connection ochilgan vaqt
🔷 query_start - sql query bajarilish boshlangan vaqt

📌 Biz asosan quydagi state natijasiga qaraymiz. Agar tizim ishlashi sekinlashgan bo'lsa va yuqoridagi query natijasida state=idle in transaction bo'lgan natija bo'lsa tezda uni aniqlab aynan ushbu client bilan connection uzish kerak va sql query qaytadan ko'rib chiqish kerak bo'ladi. idle in transaction - backend tomonidan tranzaksiya ochilgan lekin xali hech qanday ish bajarilmagan yoki tranzaksiyani commit, rollback qismlari qolib ketgan bo'lish mumkin. Bu jarayon davomida table qulflanadi va natijada aynan ushbu querydan keyingi sql querylar kutish rejimiga tushadi shu sababli tizim qotib qoladi.

✅ Yechim:

state=idle in transaction - bo'lgan clientni pid (process id) olib uni yopib yuborishimiz kerak. Quydagi query orqali bu ish amalga oshiriladi.

SELECT pg_terminate_backend(pid)
pid - process id yoziladi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

Assalomu alaykum. Hayrli va barakali kun barchaga 🖐

Ma’lumotlar bazasiga foydalanuvchiga faqatgina o’qish uchun (read-only) ruxsatini berish ketma ketligi.

1 - create role readonly;

readonly role hosil qilish. Nomlash ixtiyoriy
————————

2 - GRANT CONNECT ON DATABASE dbName
TO readonly;

ushbu role qaysi ma’lumotlar bazasi bilan ishlay olish qismini belgilash. dbName o’rnida ma’lumotlar bazasi nomi.
————————

3 - GRANT USAGE ON SCHEMA public TO readonly;

Ma’lumotlar bazasidagi qaysi schema bilan ishlay olish. Default public bo’lgani uchun shu qo’yilgan
————————


4 - GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

public schemadagi barcha jadvallarga ruxsat faqatgina SELECT sql querylarga.
————————

5 - CREATE USER read_user WITH
PASSWORD password;

Yangi foydalanuvchi qo’shish postgresql tizimga
————————

6 - GRANT readonly TO read_user;

Ushbu hosil qilingan foydalanuvchiga yuqorida hosil qilingan readonly roleni biriktirish qismi. Ma’lumotlar bazasiga dasturlash tili yoki freamvorklardan ulanishda shu hosil qilingan yangi foydalanuvchi bilan ulanilsa tizimda faqatgina select ruxsati beriladi. CREATE, UPDARE, DELETE ishlamaydi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Transaction Management (1- qism)

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Transaction Management mavzusida davom etamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

Relational databazalarda tranzaksiyani ko`rib chiqamiz.

🔹 Tranzaksiya nima?

Tranzaksiya — bu bir nechta SQL buyruqlari to‘plami bo‘lib, ular atomik tarzda bajariladi. Ya’ni bir nechta sql querylarda barchasi bajarilib bittasi xatolik bilan tugasa avvalgi barcha o'zgarishlarni bekor qiladi.

Hammasi muvaffaqiyatli bajarilishi kerak → COMMIT
Birorta xatolik bo‘lsa, hammasi bekor qilinadi → ROLLBACK

🔹 2. Asosiy buyruqlar

BEGIN - Tranzaksiyani boshlaydi
COMMIT - Tranzaksiyani yakunlab, o‘zgarishlarni saqlaydi
ROLLBACK - Tranzaksiyani bekor qiladi, eski holatga qaytaradi

🔹 3. Oddiy Tranzaksiya Misoli

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;
Ushbu sql queryda ikki query ham to'g'ri bajarilsa COMMIT qilinadi. Agar ikki sql querydan ikkinchisi xato qaytarsa ROLLBACK qo'lda yoziladi COMMIT o'rniga. Bunda UPDATE accounts SET balance = balance - 100 WHERE id = 1; so'rov natijasi ham orqaga qaytariladi. Transaction bilan ishlashda ROLLBACK yoki COMMITlarni qo'yib ketish shart. Aks xolda tableni bloklab qo'yadi va transactionni o'zi idle in transaction statusiga o'tib qoladi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

🧠 PostgreSQL: Transaction Management (2 - qism)

Assalomu alaykum, hurmatli dasturchilar!
Bugun sizlar bilan Transaction Management mavzusida davom etamiz.

📌 Diqqat bilan kuzatib boring — foydali ma’lumotlar kutmoqda! ⚡️

🔹 Tranzaksiya 4ta turi mavjud?

1 - Read Uncommited
2 - Read Commited
3 - Repeatable Read
4 - Serializable

📌 Read Uncommited - eng quyi qatlami Tranzaksiyani. Ushbu qatlamda Dirty Read muommosi yuzaga keladi. Ushbu qatlam Postgresqlda standart xolatda qo'llab quvvatlanmaydi. Dirty Read - deylik bizda 2 ta Tranzaksiya paralell ishlayabdi. Birinchi tranzaksiya A, ikkinchi tranzaksiya B. B tranzaksiya tomonidan bitta qator update qilindi lekin ushbu B tranzaksiya commit qilinmadi. Ushbu xolatda A tranzaksiya B tranzaksiya qilgan o'zgarishlarni ko'radi. Agar B tranzaksiya ROLLBACK bo'lib ketsa ushbu xolatda A tranzaksiya o'qigan ma'lumotlar xato (yolg'on) bo'lib qoladi. Aynan ushbu jarayon Dirty Read deb nomlanadi.

✅ Hayotiy misol:

- Bankda bir mijoz pul yechmoqchi (Tranzaksiya B). Aynan ushbu vaziyatda bank call center operatori balansni tekshirmoqchi (Tranzaksiya A)

1 - Tranzaksiya B pul yechyabdi deylik 1.000.000 so'm. Ushbu amaliyotni bajarishdan avval hisobida 2.000.000 so'm mablag'i bor edi. Shunda hisobida 1.000.000 so'm qoldi. Lekin Tranzaksiya B commit qilinmadi.

2 - Tranzaksiya A ushbu mijozni hisobini o'qiydi. U mijozni 1.000.000 so'm puli qolganini ko'radi.

3 - Tranzaksiya B biror sabab bilan rollback bo'lib ketdi.

4 - Shundan mijozni hisobi o'zgarishsiz qoladi yani 2.000.000 so'm. Tranzaksiya A esa xato ma'lumotga ega bo'lib qoladi.

Ushbu Dirty Read eng past darajadagi daraja hisoblanadi.

📢 Dasturlash bo‘yicha yana ko‘p bilimlar olishni xohlaysizmi?
Telegram kanalimizga a’zo bo‘ling:
👉 https://t.me/+b77O2cu55kg4ZThi

Assalomu alaykum. Hurmatli guruh a’zolari. RabbitMq bo’yicha video darslik.

rabbitmq