Refresh — cache, materialized view, replica metadata yoki boshqa hosila holatni authoritative manbadagi yangi ma’lumot bilan yangilash jarayonidir. Database kontekstida atama ko‘pincha materialized view natijasini qayta hisoblashni bildiradi. Refresh to‘liq yoki faqat o‘zgargan qismlarga incremental bajarilishi mumkin.
Full refresh
Full refresh source queryni boshidan bajarib, barcha natijani qayta yaratadi. Mantiqi sodda va oldingi driftdan tozalanadi, lekin katta table, join va aggregation uchun qimmat. Temporary storage yangi nusxani qurish uchun kerak bo‘lishi mumkin.
Atomic swap usulida readerlar refresh davomida eski valid natijani ko‘radi, so‘ng bir transactionda yangi nusxaga o‘tadi. In-place refresh resultni bo‘shatib to‘ldirsa vaqtincha unavailable yoki partial ko‘rinish paydo bo‘lishi mumkin.
Incremental refresh
Incremental refresh source’dagi o‘zgarishlarni change log, timestamp, partition yoki transaction offset orqali topadi. Faqat ta’sirlangan row va aggregate yangilanadi. Bu tezroq, ammo delete, late update va join dependencylarini to‘g‘ri ushlashi kerak.
Timestamp watermark bilan updated_at > last_refresh querysi bir xil timestamp, clock drift va transaction commit tartibida eventni tashlab ketishi mumkin. (timestamp, primary_key) cursor yoki log sequence number barqarorroq. Overlap oynasi bilan qayta o‘qish idempotent upsertni talab qiladi.
Trigger usuli
On-commit refresh base transaction bilan birga derived state’ni yangilaydi. Freshness yuqori, ammo write latency va lock oshadi. Og‘ir hisobni har transactionga qo‘shish throughputni kamaytiradi.
Asynchronous trigger change’ni queuega yozadi, worker keyin refresh qiladi. Source commitdan derived state yangilanguncha lag mavjud. Queue yo‘qotilmasligi va duplicate change idempotent qayta ishlanishi kerak.
Schedule
Refresh cron yoki orchestrator orqali har daqiqa, soat yoki kun bajarilishi mumkin. Interval biznes freshness talabi va hisoblash narxiga mos tanlanadi. Oldingi job tugamasdan yangisi boshlansa ikki refresh poyga qilishi mumkin; distributed lock yoki job concurrency policy ishlatiladi.
Jadval timezone va daylight saving o‘zgarishini hisobga oladi. “Har kuni 00:00” ikki marta yoki umuman ishlamasligi mumkin. UTC schedule va business cutoff alohida saqlanadi.
Freshness metadata
last_attempt va last_success bir xil emas. Source watermark, result row count, duration va refresh version monitoringga chiqariladi. Dashboard foydalanuvchiga “ma’lumot 10:30 gacha” degan cutoffni ko‘rsatishi mumkin.
Job muvaffaqiyatli tugab, ammo source partitionlardan biri o‘qilmagan bo‘lishi mumkin. Reconciliation expected partition, aggregate total va max event time’ni tekshiradi.
Cache refresh
Time-to-live tugaganda cache miss source’dan yangi qiymat oladi. Ko‘p request bir vaqtda expiry ko‘rsa cache stampede paydo bo‘ladi. Single-flight, jittered TTL yoki stale-while-revalidate yukni boshqaradi.
Push invalidation source o‘zgarishi bilan keyni o‘chiradi. Event yo‘qolsa stale cache qoladi, shu sabab maksimal TTL xavfsizlik tarmog‘i bo‘ladi. Authorizationga bog‘liq cache key identity contextini saqlaydi.
Failure va qayta urinish
Refresh yarim yo‘lda xato bersa eski valid natija saqlanishi ma’qul. Retry exponential backoff bilan bajariladi. Nondeterministic query yoki external API har retryda boshqa natija berishi mumkin; source snapshot yoki cutoff marker ishlatiladi.
Refresh schema migration bilan muvofiqlashtiriladi. Worker eski schema, source esa yangi schema bo‘lsa data drift yuz beradi. Versioned job va backward-compatible rollout bu oraliqni boshqaradi.
Bog‘liq tushunchalar
Materialized view, Cache invalidation, Incremental processing, Watermark, Change data capture, Data freshness, Scheduler