Razvoj

Arhitektura baze podataka koje žalimo što nismo odabrali ranije

autor

Liu C.

10 min citanja · 30. maj 2025.

Baza podataka

Pre tri godine napravili smo arhitekturnu odluku koja nam se cinila logicnom u tom trenutku. Sad, posle dva skupocena migriranja i bezbroj nocnih budenja zbog pada upita, konacno razumemo šta smo trebali da odaberemo od pocetka.

Problem: jedna SQL baza za sve

Poceli smo sa PostgreSQL bazom za sve — korisnicke podatke, analitiku, logove, transakcije. Godinu i po dana nije bilo problema. Onda smo prešli 100.000 korisnika i analiticki upiti poceli su da usporavaju transakcijsku bazu. Pocetna strana aplikacije je ucitavala za 8 sekundi.

Šta smo pokušali

Dodali smo indekse svuda. Pomoglo je kratko. Skalirali smo vertikalno — skupo i privremeno rešenje. Pokušali smo sa read replikama — kompleksnost se povecala, latencija se smanjila, ali root cause nije rešen.

"Svaki arhitekturni problem koji ignorišete danas, sutra ste poput kredita sa kamatom od 30% — raste brže nego što možete da ga pratite."

Rešenje: hibridni pristup

Transakcioni podaci ostali su u PostgreSQL. Analitika je prešla u ClickHouse — kolumnarna baza specificno dizajnirana za analitiku. Logovi su otišli u Elasticsearch. Rezultat: transakciona baza se vratila na sub-50ms, analitika je brža za 100x, a infrastruktura košta manje jer svaki alat radi ono za šta je napravljen.

Lekcija

"Jedna baza za sve" radi odlicno do odredene tacke — negde oko 10.000 aktivnih korisnika ili kad analitika pocne da pati. Plan za razdvajanje odmah na pocetku, cak i ako ga ne implementirate — jer cena reaktivne migracije je 5x veca od proaktivne arhitekture.

Svidja vam se ovaj tekst?

Pretplatite se na nedeljni newsletter.

Procitajte i ovo