Većina incidenata s bazama podataka ne započinje kao problem s bazom podataka. Počinju kao razuman aplikacijski kôd koji susretne malo više prometa, malo veću tablicu ili jednu novu značajku koja mijenja obrazac pristupa. Tada raste latencija, veze se stavljaju u red čekanja, nadzorna ploča pocrveni, a tim počinje tražiti indeks koji nedostaje.

Dodavanje tog indeksa može biti ispravan neposredan odgovor. No samo reaktivni popravci stvaraju krhak sustav: svako novo opterećenje postaje hitan slučaj koji čeka sljedeći prag. Proaktivno inženjerstvo baza podataka tretira performanse kao svojstvo dizajna, koje se mjeri i štiti tijekom cijelog životnog vijeka aplikacije.

Započnite sa zahtjevom, a ne upitom

Spor SQL izraz važan je zbog učinka koji ima na tijek rada usmjeren prema korisniku ili operativni tijek rada. Prije optimizacije definirajte put zahtjeva: koja je krajnja točka, pozadinski zadatak ili zaslon spor; koje je vrijeme odgovora prihvatljivo; koliko se često izvršava; i koliko podataka mora vratiti.

Time se sprječava česta pogreška: poboljšavanje izoliranog upita koji nije stvarno usko grlo. API krajnja točka može izvršiti nekoliko brzih upita, serijalizirati golem graf objekata, pozvati drugu uslugu i tek tada prekoračiti vremensko ograničenje. Obrnuto, jedan upit može biti prihvatljiv za administrativni izvoz, ali katastrofalan na često pozivanoj krajnjoj točki.

Instrumentirajte granicu između aplikacije i baze podataka. Bilježite trajanje, ishod pogreške, broj redaka kada je korisno te dovoljno konteksta zahtjeva za grupiranje sličnog rada. Izbjegavajte bilježenje osjetljivih vrijednosti samo radi praktičnosti. Cilj je prepoznati obrasce, a ne stvoriti drugu kopiju produkcijskih podataka u zapisnicima.

Učinite oblik upita vidljivim

Rad na performansama postaje mnogo lakši kada je SQL vidljiv kao SQL. ORM može poboljšati produktivnost, ali ne uklanja ponašanje baze podataka. Pregledajte generirane izraze za važne putanje, osobito nakon promjene odnosa, filtara, paginacije ili serijalizacije.

Klasičan je primjer obrazac upita N+1: učitajte popis, a zatim dohvatite povezane podatke jednom za svaki redak. U lokalnom razvoju često djeluje bezopasno jer je popis malen. Pri stvarnoj upotrebi jedan zahtjev pretvara u desetke ili stotine povratnih putovanja.

$orders = $repository->findRecentOrders();

foreach ($orders as $order) {
    $customerName = $order->getCustomer()->getName();
}

Hoće li ovo izdati dodatne upite ovisi o konfiguraciji ORM-a, upravo zato taj kôd zaslužuje pomno ispitivanje. Za krajnju točku popisa namjerno dohvatite odnos potreban za odgovor ili upotrijebite namjenski upit za čitanje koji odabire samo potrebna polja. Nemojte svaki problem N+1 rješavati željnim učitavanjem cijelog grafa objekata; to može zamijeniti mnogo malih upita jednim velikim, skupim rezultatom.

Čitajte planove izvršavanja kao povratnu informaciju o dizajnu

Kada je upit značajno spor, pregledajte njegov plan izvršavanja prije nagađanja. Plan može otkriti potpuna skeniranja, skupa sortiranja, spajanja izvršena neočekivanim redoslijedom ili procjene koje se znatno razlikuju od stvarnosti. Točne naredbe i format plana razlikuju se među bazama podataka, stoga upotrijebite dokumentiranu funkcionalnost baze podataka za objašnjenje te je tumačite uz stvarne parametre i veličine tablica.

Indeks nije ukrasna optimizacija. On podržava određeni obrazac pristupa. Složeni indeks trebao bi odražavati način na koji upit filtrira, spaja i sortira podatke. Na primjer, krajnja točka koja dosljedno odabire nedavne događaje jednog klijenta ima drukčije potrebe od pretraživanja svih klijenata prema vrsti događaja. Dodavanje pojedinačnih indeksa na svaki navedeni stupac može povećati trošak pisanja, a ipak ne pomoći kombiniranom upitu.

Dizajnirajte API-je koji ne prisiljavaju na skupa čitanja

O performansama baze podataka često se odlučuje na razini API ugovora. Krajnja točka koja obećava „sve zapise” s vremenom postaje produkcijska opasnost. Paginacija, ograničene veličine rezultata, izričito sortiranje i pažljivo odabrani filtri nisu samo pojedinosti sučelja; oni su mehanizmi za rasterećenje opterećenja.

Paginacija s pomakom jednostavna je i može biti sasvim primjerena za umjerene, stabilne skupove rezultata. Za velike zbirke ili zbirke koje se često mijenjaju, paginacija temeljena na pokazivaču može izbjeći postupno skeniranje i odbacivanje ranijih redaka. Također zahtijeva stabilno sortiranje i pokazivač koji ispravno predstavlja to sortiranje. Pokazivač temeljen samo na vremenskoj oznaci koja nije jedinstvena, primjerice, riskira duplikate ili izostavljanja kada nekoliko redaka dijeli istu vrijednost.

Budite jednako oprezni s fleksibilnim filtriranjem. Široko sučelje za pretraživanje može proizvesti kombinacije kojima nijedan indeks ne služi dobro. Definirajte podržane filtre, provjerite njihove raspone i odlučite koja su sortiranja doista potrebna. Ako korisnici trebaju analitičko istraživanje, transakcijski API možda nije prava apstrakcija za svako pitanje.

Zaštitite skup veza i put pisanja

Iscrpljivanje veza može učiniti da zdrava baza podataka izgleda neispravno. Svaka veza troši resurse, a velik skup na strani aplikacije ne stvara veći kapacitet baze podataka. Postavite konzervativna ograničenja, primjereno ponovno upotrebljavajte veze i osigurajte da radnici ne drže transakcije otvorenima dok izvršavaju udaljene pozive, rad s datotekama ili sporu obradu u aplikaciji.

Transakcije trebaju biti male koliko to ispravnost dopušta. Pokrenite ih blizu pisanja, izvedite potrebna čitanja i pisanja te ih odmah potvrdite ili poništite. Duge transakcije mogu zadržavati zaključavanja ili odgađati rad čišćenja, ovisno o pogonu baze podataka i razini izolacije.

Za PHP aplikacije to često znači pažljivo upravljanje životnim ciklusom zahtjeva. Zahtjev koji otvori transakciju, pošalje HTTP zahtjev drugoj usluzi i čeka odgovor povezuje sukobljavanje u bazi podataka s promjenjivošću mreže. Spremite lokalnu promjenu, potvrdite je i upotrijebite izričit asinkroni tijek rada kada poslovni proces to dopušta.

Namjerno upotrebljavajte predmemoriranje i asinkroni rad

Predmemoriranje je vrijedno kada podaci mogu biti malo zastarjeli, kada su pravila invalidacije razumljiva i kada predmemorija zaista uklanja značajan rad baze podataka. Manje je korisno kao refleksivni sloj postavljen ispred neučinkovitog upita. Najprije utvrdite što je skupo i zašto; zatim odaberite ključ predmemorije, pravilo isteka i strategiju invalidacije koji odgovaraju vlasništvu nad podacima i potrebama svježine.

Slično tome, kada je moguće, premjestite neinteraktivan rad iz puta zahtjeva: slanje obavijesti, generiranje izvještaja, ponovni izračun agregata i obrada uvoza česti su kandidati. Red čekanja ne čini rad besplatnim. Mijenja kada i kako se on izvršava, stoga radnici i dalje trebaju idempotentnost, ograničenja ponovnih pokušaja, vidljivost neuspjeha i obrazac pristupa bazi podataka koji ostaje siguran pri istodobnom izvršavanju.

Ugradite performanse u isporuku

Proaktivno inženjerstvo je rutina, a ne jednokratna sesija podešavanja. Dodajte pregled upita u zahtjeve za spajanje koji mijenjaju putanje s velikim prometom. Testirajte migracije u odnosu na realistične karakteristike tablica. Uvodite promjene sheme uz pozornost na ponašanje zaključavanja i kompatibilnost implementacije. Implementacija aplikacije trebala bi podnijeti razdoblje u kojem stari i novi kôd koegzistiraju sa shemom koja se razvija.

Vodite kratak proračun performansi za ključne operacije: očekivani broj upita, veličinu odgovora, prihvatljivu latenciju i svaku poznatu granicu skaliranja. Proračun ne treba lažnu preciznost. Njegova je svrha učiniti regresije predmetom rasprave prije nego što postanu incidenti.

• Mjerite: identificirajte spore putanje zahtjeva i skupe obrasce upita.
• Objasnite: pregledajte planove prije odabira indeksa ili prepisivanja.
• Ograničite: ograničite skupove rezultata, transakcije, ponovne pokušaje i pozadinski rad.
• Provjerite: promatrajte ponašanje u produkciji nakon svake značajne promjene.

Najbolja optimizacija baze podataka često nije lukav SQL trik. To je jasna granica proizvoda, manji odgovor, bolji obrazac pristupa ili tijek rada premješten iz kritične putanje. Kada timovi donose te odluke rano i neprekidno ih provjeravaju, performanse baze podataka prestaju biti ponavljajuća misija spašavanja i postaju dio pouzdanog dizajna pozadinskog sustava.