Performanse baze podataka rijetko uništi jedna dramatična pogreška. Češće se tiho narušavaju: praktičan upit postane kritičan put, nedostajući indeks postane vidljiv pod opterećenjem, a pozadinski posao počne se natjecati sa zahtjevima korisnika. Kada grafikoni latencije počnu izgledati alarmantno, temeljni je problem obično arhitektonski, a ne jedna spora naredba.

Predvidljivo skaliranje znači projektirati sustav čije ponašanje ostaje razumljivo kako rastu promet, količina podataka i veličina tima. Cilj nije učiniti svaki upit što bržim. Cilj je važan posao učiniti pouzdano brzim, skupi posao namjerno kontroliranim, a operativna iznenađenja lakšima za dijagnosticiranje.

Započnite s radnim opterećenjem, a ne s markom baze podataka

Baza podataka nije apstraktno „spora”. Spora je u odnosu na radno opterećenje: stope zahtjeva, omjere čitanja i pisanja, veličine zapisa, istodobnost, trajanje transakcija i prihvatljiva vremena odgovora. Sustav koji učinkovito obrađuje pretraživanje malog kataloga može se ponašati vrlo drukčije pri obradi izvješća ograničenih na klijenta kroz milijune redaka.

Prije uvođenja predmemorija, replika ili particija, utvrdite zahtjeve koji definiraju iskustvo proizvoda i poslovni rizik. Za PHP aplikaciju to često znači krajnje točke pozvane tijekom prijave, naplate, ažuriranja računa, nadzornih ploča i pozadinske obrade.

• Koji se upiti izvršavaju pri svakom zahtjevu?
• Koje tablice neprestano rastu?
• Koje operacije moraju biti strogo konzistentne?
• Koji zasloni mogu tolerirati neznatno odgođene podatke?
• Koji se poslovi mogu izvršavati asinkrono ili u skupinama?

Ova pitanja pretvaraju rad na performansama iz reaktivnog podešavanja u eksplicitnu vježbu dizajna. Također sprječavaju čest način neuspjeha: optimiziranje rijetkog administrativnog izvješća dok primarni tok za korisnike ostaje bez odgovarajućih indeksa.

Namjerno oblikujte putove pristupa

Indeksi su među najučinkovitijim alatima za performanse baze podataka, ali nisu besplatni. Troše prostor za pohranu, dodaju posao pri umetanjima i ažuriranjima te se mogu zanemariti ako oblik upita ne odgovara njima. Indeks bi trebao postojati zato što podržava poznati obrazac pristupa.

Razmotrite tablicu narudžbi s više klijenata, u kojoj krajnja točka okrenuta korisnicima prikazuje nedavne narudžbe za jedan račun:

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

Indeks usklađen sa stupcima za filtriranje i sortiranje može pomoći bazi podataka da suzi redove kandidate i izbjegne nepotrebno sortiranje:

CREATE INDEX orders_account_status_created_at_idx
ON orders (account_id, status, created_at DESC);

Točan najbolji indeks ovisi o pogonu baze podataka, distribuciji podataka i drugim upitima nad tablicom. Trajna je pouka šira: pregledajte plan izvršavanja za stvarni upit, s reprezentativnim parametrima i realističnim podacima. Ne pretpostavljajte da se indeks koristi samo zato što postoji.

Također izbjegavajte odabir podataka koji aplikaciji nisu potrebni. Dohvaćanje velikog tekstualnog stupca ili serijaliziranog sadržaja za svaki red u krajnjoj točki popisa povećava I/O, potrošnju memorije, mrežni trošak i PHP opterećenje pri hidrataciji. Uski upit često je bolja optimizacija od složenije predmemorije.

Paginacija zaslužuje arhitektonsku odluku

Offset paginaciju lako je implementirati, ali duboki offseti postaju sve rasipniji jer baza podataka možda i dalje mora proći kroz ranije retke. Također može dati zbunjujuće rezultate kada se podaci mijenjaju između zahtjeva.

Za sažetke aktivnosti, zapisnike aktivnosti i vremenski poredane resurse, paginacija temeljena na pokazivaču obično je stabilnija. Upotrijebite determinističko sortiranje, obično vremensku oznaku uz jedinstveni razrješivač neriješenih slučajeva:

SELECT id, created_at, event_type
FROM audit_events
WHERE account_id = ?
  AND (created_at, id) < (?, ?)
ORDER BY created_at DESC, id DESC
LIMIT 100;

Ovaj obrazac treba indeks koji podržava filtar klijenta i sortiranje. Također pojašnjava ugovor API-ja: klijenti nastavljaju s određene pozicije umjesto da traže proizvoljan broj stranice.

Držite transakcije kratkima i svrsishodnima

Transakcija štiti jedinicu ispravnosti; ne bi trebala postati spremnik za nepovezani rad aplikacije. Držanje transakcije otvorenom dok PHP poziva vanjski API, generira dokument, čeka odgovor reda čekanja ili obavlja opsežan izračun povećava vrijeme zaključavanja i zauzetost veza.

Provjerite ulaze i pripremite potrebne podatke prije ulaska u transakciju. Unutar nje obavite potrebna čitanja i pisanja, provedite invarijante, a zatim se odmah potvrđuje. Ako vanjski rad mora slijediti uspješno pisanje, modelirajte ga kao zaseban korak s pouzdanim mehanizmom predaje umjesto da pretpostavite kako oba sustava mogu sudjelovati u jednoj transakciji.

Neuspjesi pri istodobnosti normalni su u sustavima s konkurentskim zapisivačima. Kod bi trebao razlikovati prolazne neuspjehe, poput zastoja ili konflikata serijalizacije, od trajnih neuspjeha provjere valjanosti. Ograničeni ponovni pokušaj može biti primjeren kada je operaciju sigurno ponoviti. To zahtijeva idempotentnost: ponovni pokušaji ne smiju stvoriti duplicirana plaćanja, e-poruke ili zapise.

Koristite predmemoriranje za smanjenje rada, a ne za prikrivanje neizvjesnosti

Predmemoriranje je vrijedno kada su temeljni podaci skupi za izračun ili se često čitaju, ali uvodi drugo stanje o kojem treba razmišljati. Predmemorija bez jasne strategije vlasništva i poništavanja može sustav učiniti brzim i netočnim.

Dobri kandidati za predmemoriju uključuju stabilne referentne podatke, generirane fragmente i skupe zbirne rezultate s prihvatljivim vremenskim okvirom svježine. Loši kandidati uključuju vrijednosti koje moraju odmah odražavati svako pisanje, osim ako je put poništavanja doista pouzdan.

Praktičan pristup jest definirati ponašanje predmemorije kao dio značajke:

• Koji ključ identificira vrijednost, uključujući opseg klijenta i autorizacije?
• Koliko dugo vrijednost smije ostati zastarjela?
• Koji je događaj poništava ili osvježava?
• Što se događa kada predmemorija nije dostupna?
• Može li promašaj predmemorije uzrokovati da mnogi istodobni zahtjevi ponovno izgrade istu vrijednost?

Za mnoge krajnje točke ispravan je rezervni postupak primarna baza podataka uz razumnu zaštitu od opterećenja. Predmemorija bi trebala elegantno pogoršati performanse, a ne učiniti aplikaciju nedostupnom ili tiho vratiti podatke iz pogrešnog konteksta korisnika.

Odvojite mrežni rad od skupnog rada

Interaktivni zahtjevi i skupna obrada imaju različite potrebe za performansama. Zahtjev koji služi korisniku trebao bi učiniti najmanje potrebno za vraćanje ispravnog odgovora. Uvoz datoteka, ponovna izgradnja indeksa pretraživanja, generiranje izvješća i slanje obavijesti pripadaju asinkronim radnicima, gdje se propusnost može kontrolirati.

Ovo je razdvajanje važno na razini baze podataka. Veliki upit za ažuriranje ili izvješće može se natjecati s prometom zahtjeva za CPU, zaključavanja, međuspremničku memoriju i veze. Skupni poslovi trebali bi obrađivati ograničene dijelove, redovito potvrđivati promjene i biti dovoljno nadzirani da se mogu sigurno pauzirati ili nastaviti.

Na primjer, radnik može dohvatiti ograničen skup neobrađenih zapisa, atomski označiti napredak i nastaviti u kasnijim iteracijama. Izbjegavajte učitavanje cijele tablice u PHP memoriju ili obuhvaćanje dugotrajnog skupnog posla jednom transakcijom. I baza podataka i okruženje za implementaciju lakše se oporavljaju od malih, ponovljivih jedinica rada.

Zaštitite skup veza

Svaki proces aplikacije koji može otvoriti veze s bazom podataka pridonosi istodobnosti. U kontejneriziranim PHP implementacijama, skaliranje web radnika bez razmatranja ograničenja veza s bazom podataka može iscrpiti bazu podataka prije nego što upotreba CPU-a izgleda visoko.

Postavite eksplicitna ograničenja za radnike aplikacije i veze s bazom podataka. Ponovno koristite veze ondje gdje to model izvođenja podržava, ali uzmite u obzir zastarjele veze i ponovna pokretanja implementacije. Zajedno pratite aktivne veze, sesije na čekanju, spore upite, čekanja na zaključavanje, stope pogrešaka i latenciju zahtjeva. Promatranje samo jedne metrike potiče zavaravajuće zaključke.

Replike za čitanje mogu pomoći radnim opterećenjima s mnogo čitanja, ali također uvode zaostatak replikacije i složenost usmjeravanja. Nemojte slati čitanje koje mora odmah vidjeti prethodno pisanje replici, osim ako model konzistentnosti izričito podržava takvo ponašanje. Arhitektura je djelomično disciplina u kojoj se takvi kompromisi čine vidljivima u kodu i očekivanjima API-ja.

Kontinuirano mjerite, pažljivo mijenjajte

Promjene performansi trebale bi početi dokazima: zapisnikom sporih upita, podacima praćenja, planom izvršavanja ili ponovljivim profilom opterećenja. Zatim promijenite jednu značajnu varijablu, provjerite rezultat i pratite regresije u trošku pisanja, ponašanju zaključavanja ili potrošnji memorije.

Promjene sheme zaslužuju istu pažnju kao i izdanja aplikacije. Dodavanje indeksa ili izmjena velike tablice može utjecati na produkcijski promet, ovisno o pogonu i operaciji. Testirajte migracije na reprezentativnim podacima, razumijte ponašanje zaključavanja i imajte plan implementacije koji čuva dostupnost.

Predvidljivo skaliranje nije ciljna crta do koje se dolazi herojskim prepisivanjem. To je skup navika: modelirati obrasce pristupa, održavati kritične putove uskim, ograničavati skupi rad i promatrati sustav prije nagađanja. Kada se te navike rano izgrade u aplikaciju, rast postaje inženjerski problem s poznatim polugama umjesto hitnog slučaja koji čeka iza sljedećeg uspješnog lansiranja.