Postoji trenutak u životu svake rastuće stranice kad CDN caching prestane pomagati. Statične stranice lete, ali svaka stranica koja stvarno nešto radi — pretraga, dashboard, korisnički profil, filtriranje proizvoda — mora u nekom trenutku razgovarati s bazom podataka uživo. I tu, na potpuno drugoj razini stoga od one o kojoj se obično piše, čeka postavka koja često donosi veći skok brzine od bilo koje frontend optimizacije: pravilno postavljen indeks.
Zašto se ovaj sloj rijetko spominje
Optimizacija slika, JavaScripta i edge cachinga popularne su teme jer su vidljive u browseru — otvorite DevTools i vidite točno što je sporo. Sporost baze podataka je nevidljiva na isti način: korisnik vidi samo da se stranica sporo učitava, ne vidi da server u tom trenutku čeka upit koji prolazi kroz milijun redaka bez ijednog indeksa koji bi mu skratio put.
Slučaj koji pokazuje razmjere problema
Fintech startup koji je narastao s nekoliko stotina na nekoliko tisuća dnevnih korisnika počeo je bilježiti spore upite točno u vršnim satima — trenutak kad bi caching trebao najviše pomoći, a nije, jer je problem bio u samim upitima, ne u ponavljanju istog sadržaja. Analiza planova izvršavanja upita otkrila je nedostajuće indekse na upitima s najvećom frekvencijom pozivanja. Nakon što su indeksi dodani, performanse su porasle 400 posto, a troškovi servera pali su dramatično — jer baza više nije morala pretraživati cijele tablice za svaki pojedinačni zahtjev.
Zašto "dodajte još indeksa" nije univerzalno rješenje
Ovdje priča postaje suptilnija, i baš zato je vrijedi ispričati do kraja. Svaki indeks ubrzava čitanje, ali usporava pisanje — svaki INSERT ili UPDATE mora ažurirati ne samo tablicu, nego i svaki indeks koji na njoj postoji. Aplikacija koja piše milijune redaka dnevno može doslovno usporiti ako netko doda previše indeksa "za svaki slučaj". Ravnoteža je stvar analize stvarnih upita, ne pravila poput "indeksiraj sve stupce po kojima filtriraš".
Problem koji je češći od nedostatka indeksa
Podatak koji iznenađuje većinu developera: 61 posto produkcijskih baza podataka ima suvišne ili nekorištene indekse koji aktivno usporavaju operacije pisanja. To znači da mnoge stranice ne pate od premalo indeksa, nego od pogrešnih — starih indeksa ostavljenih od funkcionalnosti koja više ne postoji, ili dupliciranih indeksa koje je netko dodao ne provjerivši je li sličan već postojao. Timovi koji provode namjernu, mjerenu indeksnu strategiju bilježe u prosjeku tri puta brže upite uz upola manje indeksa nego oni koji indeksiraju nasumično.
Kako prepoznati je li ovo vaš problem
Prije nego što dodate ijedan indeks, pogledajte plan izvršavanja sporih upita (u PostgreSQL-u EXPLAIN ANALYZE, u MongoDB-u .explain()). Ako plan pokazuje puno pretraživanje tablice (Seq Scan ili COLLSCAN) na upitu koji se poziva stotinama puta na sat, to je gotovo uvijek signal da nedostaje indeks na stupcu po kojem se filtrira ili sortira. Ako, s druge strane, aplikacija ima problema s brzinom pisanja, a ne čitanja, smjer provjere je suprotan — pitanje postaje koje od postojećih indeksa možete sigurno ukloniti.
Zašto ovo vrijedi provjeriti prije sljedeće investicije u infrastrukturu
Prije kupnje jačeg servera ili skupljeg CDN plana, vrijedi potrošiti sat vremena na analizu stvarnih upita koji dominiraju prometom u vršnim satima. Razlika između "kupimo veći server" i "dodajmo jedan indeks" često je razlika između mjesečnog računa koji raste i problema riješenog jednom naredbom koja traje nekoliko minuta na tablici srednje veličine.
