Vacuum

Vacuum — ma’lumotlar bazasida update va delete natijasida eskirgan row versiyalarini tozalash, bo‘sh joyni qayta ishlatishga tayyorlash va ayrim metadata’larni yangilash jarayoni. Bu tushuncha ayniqsa MVCC ishlatadigan relational database’larda muhim.

MVCC readerlarga eski row versiyalarini vaqtincha saqlash orqali concurrency beradi. Eski versiyalar transactionlar uchun kerak bo‘lmay qolgach vacuum ularni tozalaydi.

Dead tuple

Row update qilinganda ayrim database’lar eski rowni joyida almashtirmaydi.

Yangi versiya yoziladi, eski versiya esa dead tuple holatiga o‘tadi.

Delete ham rowni darhol fizik olib tashlamasdan transaction visibility metadata’sini o‘zgartirishi mumkin.

Vacuum dead tuple egallagan joyni kelajakdagi yozuvlar uchun qayta foydalanishga tayyorlaydi.

Oddiy vacuum

Oddiy vacuum table’ni odatda mavjud fayl hajmini keskin kichraytirmasdan ichki bo‘sh joyni belgilaydi.

Afzalligi:

• concurrent querylar davom etadi;
• bo‘sh page’lar qayta ishlatiladi;
• dead rowlar indexdan tozalanadi;
• transaction visibility metadata yangilanadi.

Disk fayli operatsion tizimga darhol qaytarilmasligi mumkin.

Full vacuum

To‘liq qayta yozishga o‘xshash vacuum table’ni ixcham yangi fizik ko‘rinishga keltirishi mumkin.

Bu disk joyini operatsion tizimga qaytaradi.

Kamchiligi:

• kuchli lock;
• katta qo‘shimcha disk;
• uzoq execution;
• ko‘p I/O;
• katta WAL.

Production’da maintenance oynasi talab qilishi mumkin.

Autovacuum

Database background worker orqali tablelarni avtomatik vacuum qiladi.

Triggerlar:

• insert soni;
• update soni;
• delete soni;
• table hajmi;
• threshold;
• scale factor.

Katta va tez o‘zgaradigan table uchun default parametrlar yetarli bo‘lmasligi mumkin.

Analyze

Vacuum bilan birga yoki alohida ANALYZE optimizer statistics’ini yangilaydi.

Statistics:

• row count;
• distinct qiymat;
• null ulushi;
• data distribution;
• common values

haqida ma’lumot beradi.

Statistics eskirsa query optimizer noto‘g‘ri plan tanlashi mumkin.

Bloat

Dead tuple va page ichidagi bo‘sh joy table hamda index hajmini oshiradi.

Bu bloat.

Bloat oqibatlari:

• ko‘proq disk;
• ko‘proq cache;
• sekin scan;
• katta backup;
• ko‘p I/O.

Oddiy vacuum joyni qayta ishlatadi, ammo faylning fizik hajmini har doim kamaytirmaydi.

Long-running transaction

Uzoq transaction eski snapshotni ushlab turadi.

Vacuum shu transaction ko‘rishi mumkin bo‘lgan eski row versiyalarini olib tashlay olmaydi.

Natijada dead tuple yig‘iladi.

Idle transaction va uzoq report querylar vacuum progress’iga ta’sir qilishi mumkin.

Transaction ID wraparound

Ayrim MVCC tizimlar transaction ID’ni cheklangan integer sifatida ishlatadi.

Eski rowlarning visibility metadata’si vaqtida “muzlatilmasa”, ID aylanishi ma’lumot visibility’siga xavf tug‘dirishi mumkin.

Vacuum eski transaction metadata’sini xavfsiz holatga keltiradi.

Bu oddiy performance emas, database xavfsiz ishlashi uchun kritik maintenance bo‘lishi mumkin.

Freeze

Juda eski row versiyasi kelajak transactionlar uchun doim visible deb belgilanishi mumkin.

Bu freeze jarayoni transaction ID yoshini kamaytiradi.

Database table va database bo‘yicha eng eski unfrozen IDni kuzatadi.

Vacuum progress

Katta table vacuum jarayoni kuzatiladi.

Ko‘rsatkichlar:

• qaysi table;
• qaysi phase;
• scanned page;
• cleaned tuple;
• index cleanup;
• elapsed time.

Vacuumni ko‘r-ko‘rona to‘xtatish keyingi ish hajmini yana oshirishi mumkin.

Cost limit

Autovacuum foreground querylarga ortiqcha I/O bosimi bermaslik uchun cost-based throttling ishlatishi mumkin.

Juda kuchli throttling vacuumni backlogdan chiqara olmaydi.

Juda agressiv sozlama production latency’ni oshiradi.

Table workloadiga mos balans tanlanadi.

Index cleanup

Dead rowga tegishli index entrylar ham tozalanadi.

Ko‘p index vacuum vaqtini uzaytiradi.

Ayrim optimization table’da dead tuple kam bo‘lsa index cleanupni cheklashi mumkin.

Index bloat alohida rebuild yoki reindex talab qilishi ehtimoli bor.

HOT update

Indexed columnlar o‘zgarmasa yangi row versiyasi barcha indexlarga yangi entry qo‘shmasdan page ichida bog‘lanishi mumkin.

Bu Heap-Only Tuplega o‘xshash optimization.

U:

• index bloat;
• WAL;
• write I/O

ni kamaytiradi.

Page’da bo‘sh joy bo‘lishi zarur.

Fill factor

Table page’larini to‘liq to‘ldirmasdan ayrim bo‘sh joy qoldirish update’larning shu page ichida qolishiga yordam beradi.

Kam fill factor ko‘proq disk sarflaydi, ammo update-heavy table’da bloatni kamaytirishi mumkin.

Read-only table uchun yuqoriroq zichlik qulay.

Manual vacuum

Katta delete, bulk update yoki autovacuum ortda qolganda manual vacuum ishga tushiriladi.

Bu holatda:

• disk capacity;
• lock;
• replica lag;
• I/O;
• transaction yoshi

kuzatiladi.

Manual vacuum autovacuum tizimini doim o‘chirib qo‘yish o‘rnini bosmaydi.

Partitioned table

Partitionlar alohida fizik table bo‘lgani sabab vacuum har partitionda bajariladi.

Eski vaqt partitionini row-by-row delete qilishdan ko‘ra drop qilish tezroq va kamroq bloat yaratadi.

Active partitionlar esa muntazam vacuum talab qiladi.

Monitoring

Muhim ko‘rsatkichlar:

• live va dead tuple;
• autovacuum oxirgi vaqti;
• transaction ID yoshi;
• bloat taxmini;
• table va index hajmi;
• blocked vacuum;
• worker soni.

Faqat disk to‘lgandan keyin vacuum muammosini aniqlash kech bo‘ladi.

Vacuum va replica

Primary’dagi vacuum WAL yaratishi va replica replay yukini oshirishi mumkin.

Katta cleanup replica lagga sabab bo‘lsa maintenance tezligi va checkpoint sozlamalari muvofiqlashtiriladi.

Replica’dagi uzoq read ham ayrim replication modelida eski versiyalar retentioniga ta’sir qilishi mumkin.

Table-specific sozlama

Update-heavy kichik table va ulkan append-only table bir xil autovacuum threshold bilan samarali ishlamasligi mumkin.

Har table uchun scale factor, threshold va analyze chastotasi alohida sozlanishi mumkin.

Bog‘liq tushunchalar

MVCC, Dead tuple, Autovacuum, Analyze, Bloat, Transaction ID, Freeze, HOT update, Reindex, Database maintenance