Materialized view — query natijasini fizik saqlaydigan database obyektidir. Oddiy view har murojaatda base tablelardan natija hisoblaydi, materialized view esa oldindan hisoblangan satrlarni o‘qiydi. Bu murakkab join va aggregation querylarini tezlashtiradi, lekin natija refresh oralig‘ida eskirishi mumkin.
Yaratish
Materialized view query ta’rifi va uning saqlangan natijasidan iborat:
CREATE MATERIALIZED VIEW daily_sales AS
SELECT sale_date, region_id, SUM(amount) AS total
FROM sales
GROUP BY sale_date, region_id;
Yaratish paytida query bajariladi va natija storagega yoziladi. Ayrim tizim WITH NO DATA orqali strukturani bo‘sh yaratib, keyin refresh qilishga imkon beradi. Base table bilan dependency catalogda qayd etiladi.
Query tezligi
Dashboard endi millionlab sales satrini har safar guruhlamaydi, tayyor kunlik natijani o‘qiydi. Materialized view ustida alohida indeks yaratilishi mumkin. (region_id, sale_date) indeksi region va vaqt oralig‘i querylarini tezlashtiradi.
Optimizer ayrim platformalarda user base table querysini avtomatik materialized viewga rewrite qiladi. Buning uchun query equivalence, freshness va constraint metadata yetarli bo‘lishi kerak. Boshqa tizimda application view nomiga bevosita murojaat qiladi.
Full refresh
Full refresh eski natijani qayta hisoblaydi. Katta datasetda CPU, I/O va temporary disk sarfi katta bo‘ladi. Refresh transaction ichida atomik almashtirilsa reader eski yoki yangi to‘liq natijani ko‘radi; in-place rebuild vaqtincha lock yoki partial holat keltirishi mumkin.
Concurrent refresh readerlarni bloklamasdan yangi nusxa qurishi mumkin, lekin unique indeks yoki qo‘shimcha disk talab qiladi. Refresh paytida base table o‘zgaraversa database aniq snapshot nuqtasini tanlaydi.
Incremental refresh
Incremental model faqat o‘zgargan base rowlar ta’sirini hisoblaydi. Change log, materialized view log yoki partition marker qaysi qism yangilanishini ko‘rsatadi. SUM va COUNT kabi aggregation qo‘shish osonroq; DISTINCT, murakkab join va non-deterministic function qiyinroq.
Late update oldingi kun partitionini o‘zgartirsa faqat yangi kunni refresh qilish yetarli emas. Change tracking event date bilan zararlangan partitionni aniqlaydi. Periodik full reconciliation driftni topadi.
Freshness
Refresh har commitda, schedule bo‘yicha yoki talab qilinganda bajarilishi mumkin. On-commit yangi natija beradi, lekin write transactionni og‘irlashtiradi. Har soatlik schedule write’dan ajralgan, ammo bir soatgacha stale data ko‘rsatadi.
View metadata’da last successful refresh, source watermark va duration saqlanadi. “Job ishladi” statusi resultning to‘liq ekanini isbotlamaydi; row count va aggregate invariantlar tekshiriladi. Failed refresh eski valid natijani saqlashi ma’qul.
Consistency va transaction
Bir nechta materialized view turli vaqtda refresh qilinsa dashboard panellari turli source nuqtalarini ko‘rsatishi mumkin. Umumiy batch ID yoki source snapshot marker ularni bog‘laydi. Business report ma’lum cutoff vaqtini ko‘rsatadi.
Refresh query non-deterministic now() yoki volatile function ishlatsa aynan qayta ishlab chiqarish qiyin. Cutoff parametr sifatida saqlanib, barcha hisobda bir xil ishlatiladi.
Maintenance
Base schema o‘zgarsa view invalid bo‘lishi mumkin. Migration dependency tartibida viewni drop/recreate yoki yangilaydi. SELECT * o‘rniga explicit column list schema contractini aniq saqlaydi.
Materialized view storage, backup va replication hajmiga qo‘shiladi. U base data’dan to‘liq qayta qurilsa backupdan chiqarish mumkin, ammo disaster recovery va rebuild vaqti RTOga mos bo‘lishi kerak.
Bog‘liq tushunchalar
SQL view, Refresh, Incremental view maintenance, Base table, Query rewrite, Data freshness, Database index