Carte
Designing Data-Intensive Applications
de Martin Kleppmann · 2017 · 1 fișă de lectură
1 fișă
Designing Data-Intensive Applications · 2017
Adaugă, umple, comută, abia apoi șterge — niciodată nu schimba pe loc.
O aplicație se înlocuiește în cinci minute; datele ei stau cinci ani. De aici două compatibilități: înapoi (codul nou citește datele vechi) și înainte (codul vechi citește datele noi — fiindcă niciodată nu se actualizează totul deodată). Regulile care le păstrează pe amândouă sunt puține și stricte: adaugi coloane opționale, nu refolosești niciodată un nume cu alt sens, nu schimbi tipul pe loc. O schimbare de tip se face în patru pași: adaugi coloana nouă, o umpli (backfill), muți cititorii, abia apoi ștergi vechea. Formatele cu schemă (Avro, Protobuf, Parquet) fac regulile verificabile; JSON-ul liber le lasă pe seama norocului. Contractul de date e aceeași idee, ridicată la nivel de echipă: producătorul și depozitul cad de acord pe schemă, semantică, SLA, proprietar și politica de schimbare, iar acordul e verificat automat la fiecare publicare. O schimbare care rupe contractul se publică ca versiune nouă, alături de cea veche. Motivul e că cele mai grave defecte sunt tăcute: o coloană redenumită la sursă sosește ca NULL, raportul scade cu 30% și nimeni nu primește nicio eroare. Contractul o prinde la graniță, unde e ieftin.
“Astfel, datele vechi de cinci ani vor fi tot acolo, în codificarea originală, dacă nu le-ai rescris explicit între timp. Observația aceasta e rezumată uneori prin: datele supraviețuiesc codului.”