Performanse baze podataka rijetko zakažu odjednom. Češće se postupno narušavaju: nadzorna ploča učitava se malo dulje, pozadinski zadatak preklapa se s vršnim prometom, naizgled bezopasan API filtar uzrokuje spor upit, a skupovi veza počinju čekati. Kad korisnici to primijete, problem više nije jedan upit. To je interakcija između oblika podataka, obrazaca pristupa, konkurentnosti i operativnih ograničenja.

Cilj nije učiniti svaki upit što bržim zasebno. Cilj je da se sustav ponaša predvidljivo pri očekivanom opterećenju i promišljeno degradira kada potražnja premaši njegove mogućnosti.

Započnite s opterećenjem, a ne s dijagramom sheme

Dobro normalizirana shema i dalje može imati loše performanse ako joj aplikacija postavlja pogrešna pitanja. Prije dodavanja indeksa ili podešavanja konfiguracije, utvrdite opterećenje: koji su zahtjevi česti, koji su osjetljivi na latenciju, koji se putovi pisanja međusobno natječu i koja se izvješća mogu pokretati asinkrono.

API krajnja točka koja učitava jednog kupca razlikuje se od administrativnog pretraživanja kroz milijune zapisa. Tijek plaćanja može zahtijevati trenutačnu dosljednost, dok analitički zaslon može sasvim prihvatljivo kasniti nekoliko minuta. Tretiranje svih čitanja i pisanja kao jednako važnih način je na koji sustavi troše skupe resurse na pogrešan posao.

Korisna pitanja uključuju:

• Koji upiti imaju najveći volumen?
• Koje se operacije izvode tijekom vrhunaca prometa?
• Koliko redaka svaki upit pregledava u odnosu na broj vraćenih redaka?
• Koje krajnje točke pokreću ponovljene upite po zahtjevu?
• Koja se opterećenja mogu premjestiti u red čekanja, predmemoriju, repliku ili unaprijed izračunatu tablicu?

Ovaj okvir mijenja rad na performansama iz nagađanja u određivanje prioriteta.

Učinite oblik upita vidljivim

Većinu incidenata s bazom podataka lakše je dijagnosticirati kada aplikacija može povezati spor zahtjev s obrascem upita. Bilježite spore upite s trajanjem, brojem pregledanih redaka gdje je dostupan, kontekstom zahtjeva i sigurnim otiskom upita. Izbjegavajte bilježenje tajni ili osjetljivih podataka kupaca, ali zadržite dovoljno strukture za prepoznavanje ponavljanja.

Zatim pregledajte planove izvršavanja. Indeks nije automatski koristan samo zato što postoji; optimizator ga mora moći upotrijebiti za stvarni obrazac predikata, spajanja, sortiranja i grupiranja. Upit koji filtrira prema account_id, sortira prema created_at i ograničava rezultate često ima koristi od indeksa koji odražava taj obrazac pristupa.

SELECT id, status, created_at
FROM orders
WHERE account_id = ?
  AND status = ?
ORDER BY created_at DESC
LIMIT 50;

Za ovaj upit indeks koji počinje s account_id i status, nakon kojih slijedi created_at, može podržati i filtriranje i dohvat sortiranih rezultata. Ispravan izbor i dalje ovisi o distribuciji podataka i pogonu baze podataka, stoga ga potvrdite planom i realističnim podacima.

Indeksi imaju cijenu. Svaki dodatni indeks troši prostor za pohranu i čini umetanja, ažuriranja i brisanja skupljima. Indeksi su dio puta pisanja, a ne besplatni prekidači za performanse.

Spriječite slučajni rad u aplikacijskom sloju

Pozadinski kôd često neizravno stvara opterećenje baze podataka. Klasičan je primjer problem upita N+1: učitajte popis zapisa, a zatim izdajte još jedan upit za povezane podatke svakog zapisa. Može izgledati bezopasno u razvoju s deset redaka, a postati katastrofalno kada stvarni račun ima tisuće.

Upotrijebite nestrpljivo učitavanje, spajanje ili namjerni skupni upit kada su povezani podaci potrebni. Istodobno, nemojte prema zadanim postavkama dohvaćati cijeli graf objekata. Bolja je navika oblikovati podatke za slučaj upotrebe: odaberite samo potrebne stupce, podijelite velike kolekcije na stranice i izbjegavajte pretvaranje baze podataka u stroj za hidraciju objekata.

Paginacija zaslužuje posebnu pažnju. Paginacija s pomakom praktična je, ali veliki pomaci mogu zahtijevati da baza podataka skenira i odbaci rastuću količinu podataka. Za velike, sortirane skupove podataka, paginacija pomoću skupa ključeva često je stabilnija.

SELECT id, created_at, title
FROM articles
WHERE created_at < ?
ORDER BY created_at DESC
LIMIT 25;

Kursor bi se trebao temeljiti na stabilnom redoslijedu, često s jedinstvenim razrješivačem izjednačenja kao što je id. Time se izbjegavaju duplikati ili nedostajući redci kada više zapisa dijeli istu vremensku oznaku.

Kontrolirajte konkurentnost prije nego što ona kontrolira vas

Baza podataka može biti zdrava dok je aplikacija preopterećuje s previše istodobnih zahtjeva. Otvaranje nove veze za svaki PHP radnik, potrošač reda čekanja, zakazani zadatak i ad hoc naredbu može iscrpiti dostupne veze mnogo prije nego što CPU ili disk postanu vidljivo usko grlo.

Namjerno postavite ograničenja veza kroz cijeli stog. Uzmite u obzir web radnike, obrađivače poslova, preklapanje pri implementaciji, zdravstvene provjere i administrativne alate. Skup veza trebao bi osiguravati povratni pritisak umjesto da postane mehanizam za skrivanje neograničene konkurentnosti.

Transakcije također trebaju biti kratke i svrhovite. Držanje transakcije otvorenom tijekom pozivanja vanjskog API-ja, slanja e-pošte ili obavljanja sporog aplikacijskog rada povećava trajanje zaključavanja i natjecanje. Spremite stanje koje mora biti atomsko, potvrdite transakciju, a zatim ne-transakcijski rad predajte redu čekanja ili procesu vođenom izlaznim spremnikom.

Kada ažurirate zapise oko kojih postoji nadmetanje, namjerno odaberite model konkurentnosti. Optimistično zaključavanje može dobro funkcionirati kada su sukobi rijetki; zaključavanje redaka može biti prikladno kada ispravnost zahtijeva serijalizirana ažuriranja. Važno je neuspjeh tretirati kao uobičajen ishod. Zastoji i sukobi serijalizacije mogu se pojaviti čak i u ispravno dizajniranim sustavima, zato ponavljajte samo operacije koje je sigurno ponoviti i upotrijebite ograničen broj pokušaja s odgodom.

Predmemorirajte pažljivo, a ne refleksno

Predmemoriranje je vrijedno kada uklanja ponavljajući, skupi rad, ali stvara drugi sustav istine s vlastitim načinima poništavanja i otkazivanja. Predmemorirajte stabilne referentne podatke, prikazane agregate i skupa čitanja s jasnim dogovorom o svježini. Nemojte koristiti predmemoriju za prikrivanje neograničenog upita ili nedostajuće strategije paginacije.

Jasno odredite što se događa pri promašaju predmemorije, prekidu rada predmemorije ili stampedu. Ako stotine zahtjeva istodobno ponovno izgrađuju istu skupu vrijednost, predmemorija može pojačati problem baze podataka koji je trebala riješiti. Tehnike poput objedinjavanja zahtjeva, kratkotrajnih zaključavanja, ponašanja zastarjelo-dok-se-ponovno-provjerava i ograničenja brzine mogu oporavak učiniti predvidljivim.

Dizajnirajte za operativnu rezervu kapaciteta

Podešavanje performansi koje uspijeva samo u tihom okruženju nije podešavanje. Testirajte realističnu konkurentnost, veličine podataka slične produkcijskima i miješana opterećenja. U model uključite implementacije, ponovne pokušaje, neuspjele pozive prema nizvodnim sustavima, spore potrošače i dugotrajna izvješća. To su uobičajeni radni uvjeti, a ne rubni slučajevi.

Mjerite mali skup značajnih signala: latenciju zahtjeva, latenciju baze podataka, korištenje veza, čekanja zaključavanja, stope pogrešaka, dubinu reda čekanja i pokazatelje zasićenja. Upozoravajte na trajno pogoršanje, a ne na jedan bučan skok, i održavajte nadzorne ploče vezanima uz ponašanje vidljivo korisnicima.

Predvidljivo opterećenje nije odsutnost pritiska. To je sposobnost razumijevanja kamo pritisak ide, što ga ograničava i kako sustav reagira kada se ta ograničenja dosegnu.

Najtrajniji rad na performansama baze podataka obično nije glamurozan: precizan indeks, manji skup rezultata, ograničeni skup, kraća transakcija, izvješće prebačeno u pozadinu i iskreno ograničenje kapaciteta. Zajedno, ti izbori pretvaraju performanse iz kasnog napora spašavanja u arhitektonsko svojstvo sustava.