Fișa esențială de ghidare inginerească AWS: Serverele EC2 → Lambda → servere false Hard disk-uri EBS → S3 → hard disk-uri lente VPC → cosplay LAN AM → permisiunea refuzată CloudWatch → "avem Datadog acasă"

Nu rula niciodată interogări fără timeout. O singură interogare neglijentă sau un pic de încărcare poate duce la blocaje sau întreruperi ale aplicației fără ele. Să ne gândim de ce. Luați în considerare cazul în care o interogare de lungă durată este introdusă accidental în aplicația noastră. Baza de date procesează de obicei doar interogări de scurtă durată (10ms sau mai puțin) și, brusc, avem o interogare nouă care durează 1000ms pe execuție. Nu doar că va consuma resurse, dar va crește și numărul de tranzacții simultane. Fie atingem limitele de conexiune, fie limitele de transmisie, fie folosim 100% din CPU/IOPS-urile bazei de date. Acum considerăm același scenariu, dar noi plasăm un timeout de 250ms pentru fiecare tranzacție (partea bazei de date), cu logică de reîncercare exponențială + jitter (partea aplicației). Acum am limitat raza exploziei oricărei interogări. Interogările de lungă durată vor fi eliminate, iar logica de retragere minimizează riscul de a provoca turme puternice. Prin monitorizarea acestor timeout-uri, putem identifica rapid interogarea problematică și anula schimbarea.

Jurnalul write-ahead (WAL) este atât modul în care bazele de date se angajează rapid, cât și modul în care se recuperează în siguranță după blocaje. În afară de B-tree, probabil este cea mai importantă structură în Postgres și MySQL. (se numește "redo log" în domeniul MySQL)