„Un log este poate cea mai simplă abstracție de stocare posibilă. Este o secvență de înregistrări doar-cu-adăugare, total ordonată, ordonată în timp.”Jay Kreps · The Log: What every software engineer should know about real-time data's unifying abstraction · 2013 · The Log: What every software engineer should know about real-time data's unifying abstraction, LinkedIn Engineering (2013) — Part One: What Is a Log?
Un SELECT periodic nu vede ștergerile; jurnalul de tranzacții le vede pe toate.
Un log e o listă la care doar adaugi, în ordine. Pare banal, dar e abstracția care leagă replicarea, streaming-ul și depozitul de date. Orice bază relațională are unul înăuntru — jurnalul de tranzacții — și fiecare insert, update sau delete trece pe acolo înainte să ajungă în tabele. Change data capture (CDC) citește exact acel jurnal și emite fiecare schimbare ca eveniment: fără interogări periodice care încarcă sursa, fără fereastra pierdută dintre două rulări și, mai ales, cu ștergerile incluse — un SELECT de noapte nu vede niciodată rândul care a dispărut la prânz. Evenimentele ajung într-un log distribuit; consumatorii le citesc cu un offset, deci pot reporni de unde au rămas sau, dacă e nevoie, de la zero. În depozit, bronze primește evenimentele brute, iar silver aplică „ultima valoare per cheie” (merge) sau păstrează tot istoricul. Semantica realistă e cel-puțin-o-dată plus idempotență: fiecare eveniment poartă cheie și versiune, iar aplicarea lui de două ori dă același rezultat. Ordinea contează per cheie, nu între chei.
De ce contează Extragerea periodică cu SELECT ratează ștergerile și încarcă sursa; un depozit alimentat așa își pierde încet acuratețea fără să dea nicio eroare.