Baza podataka rijetko postaje spora zbog jedne dramatične pogreške. Češće se performanse narušavaju nizom malih, razumnih odluka: praktičnim upitom u petlji, indeksom koji se odgodi za kasnije, fleksibilnim stupcem koji se koristi za podatke po kojima se često filtrira ili krajnjom točkom API-ja koja traži daleko više redaka nego što korisnik može vidjeti.

Arhitektura je mjesto na kojem se te odluke međusobno učvršćuju ili stvaraju sustav koji se bori sam protiv sebe. Projektiranje za vrhunske performanse ne znači optimizirati svaki upit prvoga dana. To znači učiniti podatkovni model, obrasce pristupa, granice i operativne prakse dovoljno predvidljivima da aplikacija može rasti bez iznenađenja.

Započnite pitanjima na koja vaš sustav mora odgovoriti

Dizajn sheme trebao bi slijediti obrasce pristupa, a ne samo apstraktni model poslovanja. Normalizirani model obično je dobra osnova, ali shema koja savršeno opisuje entitete, a uobičajene zahtjeve čini skupima, nije potpuna.

Prije dodavanja tablica zapišite važna čitanja i pisanja. Za sustav narudžbi to može uključivati pronalaženje nedavnih narudžbi kupca, učitavanje narudžbe i njezinih stavki, provjeru zaliha proizvoda te izradu popisa narudžbi sa stranicama za operativno osoblje.

Svako pitanje upućuje na korisne odnose i indekse. Ako krajnja točka redovito učitava narudžbe prema kupcu, počevši od najnovijih, temeljni upit trebao bi biti očit:

SELECT id, status, total_amount, created_at
FROM orders
WHERE customer_id = ?
ORDER BY created_at DESC
LIMIT 25;

Složeni indeks koji počinje s customer_id i nastavlja se s created_at prirodan je kandidat. Točna strategija indeksiranja i dalje ovisi o mehanizmu baze podataka i punom obliku upita, ali arhitektonska poanta ostaje: modelirajte rad koji sustav zapravo obavlja.

Jasno odredite vlasništvo nad podacima

Mnogi problemi s performansama zapravo su problemi vlasništva. Kada nekoliko usluga, modula ili timova može slobodno mijenjati iste tablice, postaje teško razumjeti koje su pretpostavke sigurne. Naizgled bezopasna promjena stupca, okidača ili zadatka čišćenja može utjecati na nepovezani API put.

Odredite jasnog vlasnika za svako logičko područje podataka. Vlasništvo ne zahtijeva zasebnu bazu podataka za svaku uslugu. Ono znači da jedan dio sustava utvrđuje pravila pisanja, migracije, ograničenja integriteta i javni ugovor pristupa za skup podataka.

Ostale komponente trebale bi koristiti promišljeno sučelje: aplikacijsku uslugu, interni API, objavljeni događaj ili pažljivo upravljani model za čitanje. Izravna spajanja među domenama mogu biti prikladna u modularnom monolitu, ali trebala bi biti namjerna, a ne zadani prečac.

Indeksi su značajke proizvoda

Indeks nije opći prekidač za performanse. Ima trošak: dodatnu pohranu, više rada tijekom umetanja i ažuriranja te veću složenost kada se obrasci upita promijene. Stvarajte indekse za poznate putanje, a zatim provjerite koriste li ih te putanje.

Za svaku krajnju točku s velikim prometom pregledajte generirani SQL i proučite njegov plan izvršavanja u realističnom okruženju. Tražite potpuna skeniranja velikih tablica, skupa sortiranja, spajanja koja neočekivano umnožavaju retke i filtre primijenjene prekasno.

U PHP aplikaciji koja koristi PDO, vezanje parametara drži vrijednosti odvojenima od SQL strukture i čini ponašanje upita predvidljivijim:

$statement = $pdo->prepare(
    'SELECT id, status, total_amount, created_at
     FROM orders
     WHERE customer_id = :customerId
       AND created_at < :cursor
     ORDER BY created_at DESC
     LIMIT 25'
);

$statement->execute([
    'customerId' => $customerId,
    'cursor' => $cursor,
]);

Odgovarajući indeks trebao bi podržavati filtriranje i sortiranje koji se ovdje koriste. Indeksi ne mogu spasiti krajnju točku koja dohvaća cjelokupnu povijest kupca i većinu toga odbacuje u PHP-u. Dohvaćajte samo stupce i retke potrebne za odgovor.

Koristite paginaciju koja odgovara opsegu

Paginacija s pomakom jednostavna je i često prihvatljiva za male administrativne popise. No veliki pomaci mogu prisiliti bazu podataka da prođe sve veći broj redaka prije nego što vrati sljedeću stranicu. Rezultati se također mogu promijeniti dok se korisnik kreće između stranica.

Za uređene podatke velikog opsega, paginacija temeljena na kursoru obično je stabilnija arhitektura. Upotrijebite vrijednost iz redoslijeda sortiranja, često uparenu s jedinstvenim identifikatorom za razrješavanje izjednačenja. Klijent šalje posljednji viđeni kursor, a sljedeći upit traži retke nakon njega.

• Odaberite deterministički redoslijed sortiranja.
• Uključite jedinstveni razrješivač izjednačenja kada se vremenske oznake ili rezultati mogu podudarati.
• Kodirajte kursore kao detalj API-ja umjesto da nepotrebno izlažete pretpostavke implementacije.
• Zadržite razumnu gornju granicu veličine stranice.

Ovaj pristup pretvara „stranicu 5000” u zahtjev za sljedeći dio uređenog toka, što je bolje usklađeno s načinom na koji se indeks prolazi.

Spriječite skupi rad prije nego što stigne do baze podataka

Baza podataka vrijedna je zajednička infrastruktura. Postupajte s njom u skladu s tim. Validacija, autorizacija, ograničenja zahtjeva i predmemoriranje trebali bi se odvijati na odgovarajućem sloju prije nego što svaki zahtjev postane skup upit.

Predmemoriranje je korisno kada uklanja ponavljani rad, a ne kada prikriva nejasno ponašanje. Predmemorirajte podatke s definiranim zahtjevom svježine, jasnom strategijom poništavanja i sigurnim rezervnim rješenjem kada predmemorija nije dostupna. Katalog proizvoda može tolerirati kratkotrajnu zastarjelost; stanje ili rezervacija zaliha često zahtijevaju strožu dosljednost.

Za rad koji ne mora biti dovršen tijekom HTTP zahtjeva, upotrijebite trajni red i radnički proces. Izrada izvješća, obrada slika, obavijesti i skupni uvozi tipični su primjeri. Zahtjev bilježi namjeru i vraća koristan status; radnik obavlja sporiju operaciju s ponašanjem ponovnog pokušaja osmišljenim za taj zadatak.

Ponovni pokušaji zahtijevaju oprez. Prolazni neuspjeh baze podataka može opravdati ponovni pokušaj, ali neidemponentna operacija može stvoriti dvostruke učinke. Upotrijebite granice transakcija, jedinstvena ograničenja, ključeve idempotentnosti i eksplicitne prijelaze stanja kako bi ponovno pokrenut zadatak ostao siguran.

Transakcije štite ispravnost, a ne samo podatke

Performanse i ispravnost nisu suprotstavljeni ciljevi. Nedosljedni podaci često kasnije stvaraju skupe zadatke popravka, obrambenu logiku aplikacije i složene upite. Ograničenja postavite u bazu podataka kada predstavljaju trajna poslovna pravila: primarne ključeve, strane ključeve gdje je prikladno, jedinstvena ograničenja i razborite zahtjeve za vrijednostima koje nisu null.

Neka transakcije budu kratke. Transakcija koja obavlja mrežne pozive, čeka korisnički unos ili obrađuje veliku grupu može držati zaključavanja dulje nego što je potrebno. Odvojite atomsku promjenu baze podataka od vanjskih nuspojava. Uobičajen je obrazac prvo potvrditi poslovno stanje, a zatim pouzdano predati naknadni rad putem mehanizma outboxa ili stavljanja u red.

Razina izolacije, ponašanje zaključavanja i rukovanje zastojima razlikuju se prema mehanizmu baze podataka i opterećenju. Praktična disciplina je univerzalna: očekujte konkurentnost, otkrivajte neuspjehe koji se mogu ponoviti i učinite put ponovnog pokušaja sigurnim.

Uvodite promjene baze podataka kao vježbu kompatibilnosti

Migracija nije dovršena kada se pokrene lokalno. Produkcijska uvođenja mogu privremeno istodobno pokretati stare i nove verzije aplikacije. Dizajnirajte promjene sheme tako da obje verzije mogu raditi tijekom tog razdoblja.

1. Najprije dodajte novi stupac koji dopušta null ili novu tablicu.
2. Uvedite kôd koji može čitati stari oblik i pisati novi oblik.
3. Po potrebi dopunite postojeće podatke u kontroliranim skupinama.
4. Prebacite čitanja nakon što novi podaci postanu pouzdani.
5. Uklonite zastarjele stupce ili ponašanje tek nakon što stare verzije aplikacije više ne postoje.

Ovaj pristup proširivanja i sažimanja manje je dramatičan od velikog prepisivanja sheme, ali smanjuje rizik uvođenja i čini vraćanje na prethodno stanje realističnim.

Mjerite cijeli put zahtjeva

Samo vrijeme rada baze podataka nije dovoljno. Pratite put od dolaznog zahtjeva do odgovora: vrijeme aplikacije, broj upita, spore upite, čekanja na zaključavanje, pritisak na skup veza, kašnjenje reda i stope pogrešaka. Zapisi bi trebali sadržavati identifikator zahtjeva ili zadatka kako bi se povezani događaji mogli spojiti bez nagađanja.

Najvažnije, optimizirajte na temelju dokaza. Upit koji izgleda sumnjivo može se izvršiti jednom dnevno; skromno pretraživanje izvedeno tisućama puta može biti stvarni trošak. Uspostavite proračun performansi za kritične krajnje točke, izmjerite početno stanje, napravite jednu usmjerenu promjenu i provjerite rezultat pri reprezentativnom opterećenju.

Gradite za sljedeće pitanje

Vrhunske performanse nisu rezultat jednog mjerila. One su sposobnost odgovaranja na sljedeće pitanje o proizvodu bez destabiliziranja sustava: Može li se ovaj popis filtrirati prema još jednom polju? Može li se uvoz sigurno nastaviti? Može li novi klijent koristiti ovaj API bez stvaranja obrasca upita N+1?

Dobro dizajnirana baza podataka čini uobičajeni put izravnim, put neuspjeha oporavljivim, a operativni put vidljivim. To je arhitektura kojoj vrijedi težiti: ne domišljatost skrivena u shemi, nego sustav čije ponašanje podataka ostaje razumljivo kako potražnja raste.