„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.
Dacă log-ul e sursa adevărului, apare o consecință neobișnuită: tabelele nu mai sunt sacre. Ele devin o viziune materializată — un rezultat calculat din evenimente, care poate fi refăcut de la zero oricând. Asta schimbă felul în care gândești greșelile. O migrare ratată sau o logică greșită nu mai e o catastrofă, ci o repornire: arunci tabela, corectezi transformarea, rejucai log-ul. La fel cum poți rescrie o rețetă și găti din nou din aceleași ingrediente, fără să fi pierdut nimic. Baza de date nu mai e depozitul adevarului, ci un cache al ultimei valori, reconstruibila din jurnal. Dar dacă log-ul poate reface orice, apare întrebarea firească: cât timp trebuie păstrat acel log?
Pasajul anterior s-a încheiat cu o întrebare: cât trebuie păstrat log-ul? Răspunsul surprinde: nu pentru totdeauna. Pentru că tabela poate fi reconstruită din orice punct, e suficient un instantaneu plus evenimentele de după el. Multe sisteme merg mai departe și păstrează în log doar ultima valoare per cheie, printr-un proces numit compactare. E ca agenda din telefon: nu ții fiecare versiune veche a fiecărui număr, doar starea actuală, și totuși poți suna pe oricine. Istoricul complet devine o alegere, nu o obligație — îl păstrezi doar dacă vrei să răspunzi la întrebări despre trecut. Dar dacă log-ul e atât de central, apare o problemă practică: ce se întâmplă când mai multe servicii vor să scrie în el în același timp?
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.