Log Compaction — append-only logda har key uchun eng so‘nggi qiymatni saqlab, eski superseded recordlarni fon jarayonida olib tashlash siyosati. U cache, distributed snapshot yoki stream-processing tizimlaridagi muayyan data va vaqt semantikasini ifodalaydi. Aniq kafolatlar platforma, protocol hamda konfiguratsiyaga bog‘liq; termin nomi barcha implementatsiyada bir xil xulqni anglatmaydi.
Tizimdagi vazifasi
Compactor segmentlarni ko‘rib, keyning keyingi recordi mavjud bo‘lsa avvalgisini o‘chiradi. Delete tombstone bilan ifodalanadi va ma’lum muddat saqlangach tozalanadi. Record offsetlari qayta raqamlanmaydi.
Log Compaction alohida feature emas, source, storage, tarmoq va consumer xulqi bilan birga ishlaydi. Request qabul qilinishi, state durable bo‘lishi va natijaning tashqi tizimda ko‘rinishi turli nuqtalar bo‘lishi mumkin. Shu chegaralar hujjatlashtirilsa retry va recoverydagi noaniqlik kamayadi.
Holat o‘zgarishi
Time-based retention vaqtga ko‘ra barcha eski recordni o‘chiradi; compaction esa key state’ini tiklash uchun eng yangi recordni saqlashga intiladi. Ikki siyosat birga ishlashi mumkin.
Log Compaction kafolati butun pipeline bo‘yicha baholanadi. Source timestamp to‘g‘ri bo‘lsa ham broker, operator, cache va sink boshqa ordering yoki durability semantikasini berishi mumkin. Har acknowledgement qaysi state durable va visible bo‘lganini ifodalaydi.
Ishonchlilik
Tombstone erta o‘chsa offline replica eski qiymatni qayta tiriltirishi mumkin. Key yo‘q recordlar, compaction lag va disk amplification nazorat qilinadi.
Log Compaction bilan ishlovchi client retry uchun umumiy deadline, exponential backoff va jitter qo‘llaydi. Cheksiz retry backendni himoya qilmaydi. Side effect bo‘lsa idempotency key yoki checkpoint bilan duplicate effect cheklanadi; timeout operatsiya bajarilmadi degani emas.
Log Compaction dizaynida correctness, freshness, latency va resource sarfi birga tanlanadi. Past latency uchun cache yoki early firing ishlatilsa stale yoki preliminary natija ehtimoli paydo bo‘ladi. Qat’iyroq ordering va completeness ko‘proq buffer, coordination yoki kutish vaqtini talab qiladi.
Kuzatuv
Log Compaction uchun monitoring semantic metrikalarni qamrab oladi: hit ratio, stale age, watermark lag, late count, compaction backlog yoki offset distance. Process up signali correctnessni ko‘rsatmaydi. Alert aniq key, partition va vaqt oralig‘ini tekshirish qadamiga bog‘lanadi.
Log Compaction optimallashtirilganda correctness testi qayta bajariladi. Batching, local cache, asynchronous flush yoki parallelism throughputni oshirishi mumkin, ammo ordering va freshnessni o‘zgartiradi. Feature flag bilan yoqilgan yo‘l ham shu semantic testdan o‘tadi.
Log Compaction ko‘p tenantli muhitda adolatli resource taqsimotini talab qiladi. Bitta tenantning hot keylari, katta oynasi yoki sekin consumeri umumiy memory va diskni egallamasligi uchun per-tenant limit hamda isolation ishlatiladi. Limitga yetish correctnessni buzadigan yashirin drop emas, o‘lchanadigan va tushunarli javob bilan namoyon bo‘ladi.
Log Compactionga bog‘liq default qiymatlar environmentlar orasida bir xil deb taxmin qilinmaydi. Developmentdagi kichik data va bitta node productiondagi parallelizm, retention hamda failure xulqini to‘liq takrorlamaydi.
Log Compaction uchun qabul mezoni misol bilan tasdiqlanadi: bir xil input va boshlang‘ich state berilganda kutilgan output, metadata hamda tashqi effect birgalikda tekshiriladi. Faqat yakuniy qiymatni solishtirish oraliq yo‘qotish yoki takroriy yozuvni yashirishi mumkin.
Log Compaction bo‘yicha o‘zgarishdan keyin faqat muvaffaqiyatli oqim emas, miss, timeout, duplicate, late data, restart va partial failure holati ham tekshiriladi. Qabul qilingan cheklovlar hujjatlashtiriladi va boshqa workloadga avtomatik ko‘chirilmaydi.
Bog‘liq tushunchalar
compacted log, tombstone, retention policy, key-value state, stream offset, changelog