Usluge baza podataka: PostgreSQL, MySQL i MongoDB

Usluge baza podataka obuhvataju sve što se dešava između vaše aplikacije i podataka od kojih ona zavisi: izbor pravog sistema, dizajn šeme, upite koji ostaju brzi i kada tabele narastu, te redovan backup, replikaciju i sigurnost. Kada je baza dobro postavljena, niko je ne primjećuje. Kada nije, vidi se na svakom koraku – spore stranice, timeouti tokom akcija i rasprodaja, izvještaji koji se generišu minutama i programeri koji se boje promijeniti jednu kolonu.

Sadržaj

U CodeWizu dizajniramo, gradimo, optimizujemo i spašavamo baze podataka za web aplikacije, online prodavnice, SaaS proizvode, API-je i interne alate sa mnogo podataka. Svakodnevno radimo sa PostgreSQL-om i MySQL-om/MariaDB-om kao glavnim izvorom podataka, MongoDB-om za podatke u obliku dokumenata, Typesenseom za brzu pretragu i Redisom za keširanje, redove poruka i podatke u realnom vremenu – i znamo gdje svaki od njih pripada, a gdje ne.

Usluga je namijenjena timovima koji pokreću novi proizvod i žele model podataka koji za godinu dana neće tražiti bolno prepisivanje, kao i kompanijama kojima je postojeća baza postala usko grlo. Ako se aplikacija usporava kako podaci rastu, procesor servera u špicama radi na 100% ili niko nije siguran da bi se backup zaista mogao vratiti, analiza baze je obično najisplativiji korak koji možete napraviti.

Baze: Otvoren hard disk na kojem se vide ploča i glava za čitanje i pisanje

Razvoj i optimizacija PostgreSQL i MySQL baza

Relacione baze su i dalje pravi temelj za većinu poslovnih aplikacija: narudžbe, fakture, korisnike, dozvole i sve ostalo gdje je konzistentnost podataka ključna. PostgreSQL i MySQL (uključujući MariaDB) su zreli, open-source i brzi sistemi. Razlike se uglavnom vide na rubnim slučajevima, pa biramo prema vašem opterećenju, frameworku i timu, a ne iz navike.

PostgreSQL ili MySQL u praksi

PostgreSQL se ističe kod složenih upita, strogog integriteta podataka, JSONB kolona, full-text pretrage, window funkcija, parcijalnih indeksa i indeksa nad izrazima, te ekstenzija poput PostGIS-a za geopodatke ili pgvectora za AI embeddinge.
MySQL/MariaDB je prirodan izbor za WordPress, WooCommerce, Magento i PrestaShop, ima vrlo predvidive performanse kod jednostavnih opterećenja sa mnogo čitanja i podržava ga praktično svaki hosting.
Oba sistema odlično rade sa Laravelom, Node.js-om (Prisma, Knex, TypeORM, Drizzle) i svim većim programskim jezicima, pa izbor rijetko ograničava kod aplikacije.

Optimizacija upita i indeksiranje

Većina problema tipa „baza je spora” svodi se na nekoliko upita bez odgovarajućeg indeksa, N+1 upite u ORM-u ili konfiguraciju koja je ostala na podrazumijevanim vrijednostima iz instalacije. Krećemo od podataka, ne od pretpostavki: pg_stat_statements ili MySQL slow query log pokazuju koji upiti ukupno troše najviše vremena, a EXPLAIN ANALYZE otkriva zašto.

-- Find the cause: a sequential scan over millions of orders
EXPLAIN ANALYZE
SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

-- Fix: one composite index that matches filter and sort order
CREATE INDEX CONCURRENTLY idx_orders_customer_status_created
  ON orders (customer_id, status, created_at DESC);

Osim indeksa, podešavamo memorijske parametre (shared_buffers, work_mem, innodb_buffer_pool_size), uvodimo connection pooling preko PgBouncera ili ProxySQL-a, ispravljamo ORM upite koji učitavaju cijele tabele i uklanjamo indekse koje niko ne koristi – jer svaki suvišan indeks usporava svako pisanje. Zvanični PostgreSQL vodič za EXPLAIN je odlična referenca ako želite ući dublje u temu.

Typesense i MongoDB: pretraga i dokumenti na pravi način

Nije svaki problem relacioni. Dva alata koja često dodajemo uz glavnu SQL bazu su Typesense za pretragu i MongoDB za fleksibilne podatke u obliku dokumenata.

Typesense za trenutnu pretragu otpornu na greške u kucanju

Upit LIKE '%term%' ne može koristiti običan indeks, ne prepoznaje greške u kucanju i loše rangira rezultate. Typesense je open-source pretraživač koji vraća rezultate za nekoliko milisekundi, razumije greške u kucanju, sinonime i filtere po kategorijama (facete), a mnogo je lakši za održavanje od Elasticsearcha. SQL baza ostaje glavni izvor istine, a izmjene u Typesense šaljemo preko događaja u modelima, reda poruka ili change data capture pristupa – tako je pretraga brza i nikada ne postaje druga kopija podataka koja se razilazi sa originalom. Detaljno smo pisali o tome kako gradimo brze pretraživače uz Typesense.

MongoDB tamo gdje dokumenti imaju smisla

MongoDB je dobar izbor za kataloge proizvoda sa vrlo različitim atributima po kategorijama, podatke o događajima i logove, sadržaj sa duboko ugniježđenom strukturom i prototipove čija se šema još mijenja. Kolekcije dizajniramo prema načinu na koji se podaci čitaju, koristimo validaciju šeme kako „bez šeme” ne bi postalo „bilo šta”, pravimo složene indekse po ESR pravilu (equality, sort, range) i koristimo aggregation pipeline umjesto prebacivanja dokumenata u kod aplikacije.

Otvoreno govorimo i o ograničenjima: ako su vaši podaci puni veza i transakcija između entiteta, PostgreSQL sa nekoliko JSONB kolona često je jednostavniji od MongoDB-a uz spajanje podataka u aplikaciji.

Koja baza za koji posao

Većina aplikacija koje gradimo koristi dva ili tri sistema za podatke, pri čemu svaki radi ono u čemu je najbolji. Ovo je poređenje kroz koje prolazimo sa klijentima prilikom planiranja arhitekture:

Sistem	Model podataka	Prednosti	Tipična upotreba	Nije idealan za
PostgreSQL	Relacioni + JSONB	Integritet, složeni upiti, ekstenzije	SaaS, ERP aplikacije, API-ji, analitika, AI embeddinzi	Timove vezane za hosting koji nudi samo MySQL
MySQL / MariaDB	Relacioni	Jednostavnost, brza čitanja, podrška na svakom hostingu	WordPress, WooCommerce, Magento, Laravel aplikacije	Vrlo složene analitičke upite
MongoDB	Dokumenti (BSON)	Fleksibilna šema, ugniježđeni podaci, horizontalno skaliranje	Katalozi, događaji, sadržaj, IoT podaci	Izrazito relacione i transakcione podatke
Typesense	Indeks za pretragu	Pretraga u milisekundama, otporna na greške, sa facetama	Pretraga proizvoda i sajta, autocomplete	Ulogu glavnog izvora podataka
Redis	Key-value u memoriji	Čitanje ispod milisekunde, bogate strukture podataka	Cache, sesije, redovi poruka, rate limiting, rang liste	Velike skupove podataka koji moraju opstati bez RAM-a

Redis keširanje u arhitekturi baze podataka

Najbrži upit je onaj koji nikada ne stigne do baze. Redis stoji pored glavne baze i preuzima ponovljena čitanja: stranice proizvoda, konfiguraciju, provjere dozvola, skupe agregacije i odgovore API-ja. Kada je dobro postavljen, drastično smanjuje opterećenje baze i čini vrijeme odziva predvidivim i tokom naglih skokova saobraćaja.

Iz ugla baze podataka, fokusiramo se na to da Redis i baza ostanu usklađeni:

Cache-aside čitanje sa razumnim TTL vrijednostima i eksplicitnom invalidacijom kada se izmijene redovi u bazi.
Zaštita od cache stampede efekta pomoću lockova ili ranijeg preračunavanja, kako jedan istekli ključ ne bi poslao stotine istih upita na bazu u istom trenutku.
Odvojene Redis baze ili instance za cache (koji se smije brisati) i za sesije i redove poruka (koji se ne smiju brisati), sa odgovarajućim maxmemory-policy podešavanjem za svaku.
Redis i za više od keširanja: Laravel i BullMQ redovi poruka, rate limiting, distribuirani lockovi i brojači u realnom vremenu.

Keširanje kroz sve slojeve – Memcached, keš u aplikaciji, HTTP i CDN – zasebna je tema koju pokrivamo kroz posebnu uslugu keširanja.

Šarene linije koda aplikacije na tamnom ekranu editora

Sharding baze podataka i skaliranje izvan jednog servera

Sharding baze podataka dijeli podatke na više servera, obično prema shard ključu kao što je ID klijenta ili korisnika, tako da nijedna mašina ne mora čuvati i posluživati sve. To je moćan pristup, ali i najsloženiji način skaliranja, pa treba doći na kraju, a ne na početku.

Prije shardinga iskoristimo jeftinije korake, otprilike ovim redom:

Ispravljamo spore upite i dodajemo indekse koji nedostaju, uz connection pooling.
Vertikalno skaliramo server – moderan hardver sa NVMe diskovima može izdržati mnogo.
Dodajemo read replike i na njih preusmjeravamo izvještaje i saobraćaj sa mnogo čitanja.
Često korištene podatke keširamo u Redisu, a pretragu prebacujemo u Typesense.
Vrlo velike tabele particionišemo (na primjer po mjesecima) unutar jedne baze.
Tek tada uvodimo sharding – uz Citus za PostgreSQL, Vitess za MySQL ili ugrađeni sharding u MongoDB-u.

Kada je sharding zaista potreban, dizajniramo shard ključ, sloj za usmjeravanje upita i plan prelaska tako da sve prođe bez prekida rada. U članku o shardingu i particioniranju baze podataka detaljnije objašnjavamo prednosti i kompromise.

Dizajn baze i modelovanje podataka

Dobra šema je jeftinija od bilo koje kasnije optimizacije. Kod novih projekata prvo modelujemo domen – entitete, veze, način na koji će se podaci pretraživati i kako će rasti – a tek onda pišemo migracije.

Normalizovane osnovne tabele sa ispravnim primarnim i stranim ključevima i ograničenjima, tako da se neispravni podaci uopšte ne mogu upisati.
Svjesna denormalizacija samo tamo gdje to traže performanse čitanja, dokumentovana i usklađena sa izvorom.
Ispravni tipovi podataka: numeric za novac umjesto float vrijednosti, timestamptz za vrijeme, UUIDv7 ili bigint ključevi zavisno od namjene.
Soft delete, audit kolone i multi-tenancy definisani na početku, a ne naknadno dodani.
ER dijagram i rječnik podataka koje vaš tim može koristiti pri uvođenju novih ljudi.

Backup, replikacija i visoka dostupnost

Backup koji nikada niste vratili je nada, a ne backup. Svaka baza o kojoj brinemo dobija automatizovanu strategiju backupa sa redovnim, provjerenim vraćanjem podataka.

Point-in-time recovery za PostgreSQL uz pgBackRest ili WAL-G, te oporavak preko binarnih logova za MySQL, tako da bazu možete vratiti na minut prije greške.
Šifrovane kopije van servera u object storageu, odvojene od produkcijskog servera i njegovih pristupnih podataka.
Streaming replikacija sa hot standby serverom i automatski failover uz Patroni ili managed baze kada to opravdavaju zahtjevi za dostupnošću.
Nadzor kašnjenja replikacije, rasta diska, dugih upita i lockova, uz upozorenja prije nego što korisnici bilo šta primijete.

Kod online prodavnica ovo je dio šireg pristupa koji opisujemo u članku o e-commerceu bez gubitka podataka i narudžbi, gdje svaka narudžba i svaka akcija kupca mora biti povratljiva.

Sigurnost baze i kontrola pristupa

Baze nikada ne slušaju na javnom interfejsu; pristup ide preko privatnih mreža, VPN-a ili SSH tunela.
Odvojeni korisnici po aplikaciji i ulozi, sa minimalnim potrebnim pravima – web aplikacija ne može obrisati tabele.
TLS za konekcije, šifrovanje podataka na disku gdje je potrebno i tajne koje se čuvaju van koda.
Parametrizovani upiti svuda kako bi se eliminisao SQL injection, uz row-level security u PostgreSQL-u za sisteme sa više klijenata.
Audit logovi i rukovanje ličnim podacima u skladu sa GDPR-om, uključujući anonimizovane kopije za razvoj i staging.

Najčešće greške u radu sa bazama koje ispravljamo

Nema indeksa na stranim ključevima i kolonama za filtriranje, ili desetine indeksa koji se preklapaju i usporavaju svako pisanje.
ORM N+1 upiti koji jedan prikaz stranice pretvaraju u stotine odlazaka do baze.
Novac sačuvan kao float, datumi kao tekst ili ID-jevi razdvojeni zarezom u jednoj koloni.
Izvještaji i veliki izvozi koji se pokreću na istoj glavnoj bazi koja opslužuje checkout.
Podrazumijevana konfiguracija na serveru sa mnogo RAM-a koji baza nikada ne iskoristi.
Backupi koji se čuvaju na istom serveru kao i baza i nikada nisu testirani.

Programer kuca na laptopu sa kodom otvorenim u editoru

Kako radimo

Analiza: pregledamo šemu, logove sporih upita, konfiguraciju, metrike servera, backupe i način na koji aplikacija koristi bazu.
Plan: nalaze rangiramo prema uticaju na poslovanje i dogovaramo plan – prvo brzi rezultati, zatim strukturne izmjene.
Izrada: dizajniramo šeme, pišemo migracije, dodajemo indekse, podešavamo konfiguraciju i postavljamo replikaciju, keširanje ili pretragu.
Testiranje: mjerimo performanse na realnoj količini podataka, poredimo planove izvršavanja prije i poslije te uvježbavamo vraćanje backupa i failover.
Puštanje u rad: izmjene uvodimo kontrolisano, korak po korak, uz online izgradnju indeksa i nadzor tokom i nakon svake promjene.
Podrška: po želji dugoročno nadziremo, ažuriramo i optimizujemo bazu te pomažemo vašem timu kako rastu podaci i saobraćaj.

Zašto CodeWiz

Full-stack pogled: sami razvijamo Laravel, Node.js i WordPress aplikacije koje rade nad bazama, pa probleme rješavamo u upitima i kodu, a ne samo na serveru.
Pravi alat za svaki posao: PostgreSQL, MySQL, MongoDB, Typesense i Redis su dio našeg svakodnevnog rada, pa preporučujemo ono što odgovara, a ne ono što slučajno poznajemo.
Open-source na prvom mjestu: bez troškova licenci i bez zaključavanja kod jednog dobavljača – podaci ostaju u standardnim, prenosivim formatima.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, uz rad na daljinu sa klijentima iz regiona i svijeta.
Performanse na jednom mjestu: optimizacija baza, keširanje, Varnish i Cloudflare su dio onoga što radimo – saznajte više o CodeWizu.

Često postavljana pitanja

Da li za novi projekat izabrati PostgreSQL ili MySQL?

Za aplikaciju po mjeri bez ograničenja platforme obično preporučujemo PostgreSQL zbog snažnih mehanizama integriteta, JSONB podrške i ekstenzija. Ako gradite na WordPressu, WooCommerceu, Magentu ili PrestaShopu, MySQL ili MariaDB je prirodan izbor. Oba sistema su odlična kada su dobro dizajnirana i podešena.

Koliko koštaju usluge optimizacije baze podataka?

Zavisi od veličine baze, broja aplikacija koje je koriste i dubine problema. Ciljana analiza sa brzim poboljšanjima je manji projekat, dok su redizajn šeme sa migracijom podataka ili prelazak na replikaciju i sharding veći posao. Jasnu procjenu dobijate nakon početnog pregleda.

Možete li ubrzati bazu bez izmjena u aplikaciji?

Često možemo. Indekse, podešavanje konfiguracije, connection pooling i read replike moguće je uvesti bez diranja koda aplikacije. Ipak, najveći dobici obično dolaze od ispravke nekoliko neefikasnih upita u kodu, što također radimo.

Da li je optimizacija produkcijske baze rizična?

Jeste ako se radi nepažljivo. Izmjene testiramo na kopiji sa realnim podacima, indekse gradimo online (CREATE INDEX CONCURRENTLY ili online DDL u MySQL-u), zahtjevne operacije zakazujemo u periodima slabog saobraćaja i prije svake strukturne izmjene imamo provjeren backup.

Kada mi uz SQL bazu treba MongoDB ili Typesense?

Typesense uvedite kada korisnicima treba brza pretraga otporna na greške u kucanju ili filtriranje kroz velike kataloge. MongoDB razmotrite kada su vaši podaci prirodno u obliku dokumenata i mnogo se razlikuju od zapisa do zapisa. Ako ništa od toga nije slučaj, dobro dizajnirana PostgreSQL ili MySQL baza je obično sasvim dovoljna.

Učinimo vašu bazu brzom i pouzdanom

Opišite nam svoju aplikaciju, podatke i gdje vas danas najviše muči, a mi ćemo predložiti jasan plan rješenja. Kontaktirajte nas da razgovaramo o projektu ili pogledajte kompletnu ponudu naših usluga baza podataka.

Usluge baza podataka: PostgreSQL, MySQL i MongoDB