Sharding i particioniranje baze podataka

Sharding baze podataka je način da aplikacija koja raste i dalje odgovara na zahtjeve kada jedan server baze više nije dovoljan. Narudžbe, događaji, poruke ili podaci po klijentu dijele se na više servera, svaki čuva samo svoj dio, pa skladište i saobraćaj pisanja rastu u širinu umjesto da svakog kvartala traže jaču mašinu.

Sadržaj

U CodeWizu dizajniramo i uvodimo sharding i particioniranje za PostgreSQL, MySQL i MongoDB. Pun shard klaster ostavljamo za kraj, a ne za početak: indeksi, keširanje, read replike i ugrađeno particioniranje tabela rješavaju mnoge zahtjeve tipa „moramo shardovati”. Kada je podjela zaista potrebna, biramo shard ključ, sloj za usmjeravanje i prelazak tako da aplikacija ostane online, a vaš tim zna koji upiti smiju preći granicu sharda.

Usluga je za multi-tenant SaaS proizvode, marketplace platforme, prodavnice sa velikim prometom i sisteme kojima je brzina pisanja ili obim podataka prerasla jedan primary server. Ako su podaci još skromni, reći ćemo to i prvo riješiti jeftinije probleme. Ako jedan klijent ili jedan noćni izvještaj već savija server, podjelu treba dizajnirati prije nego što je nametne prekid rada.

Particioniranje: Crveni dijelovi slagalice razbacani po drvenom stolu

Horizontalni sharding baze podataka na više servera

Horizontalni sharding stavlja različite redove iste logičke tabele na različite servere baze. Narudžbe se mogu dijeliti po tenant_id, poruke po korisniku, knjigovodstvo po računu. Svaki shard je obična baza koju možete backupovati i vratiti zasebno. Aplikacija, ili proxy ispred nje, odlučuje koji shard odgovara na upit.

Kapacitet pisanja i disk dobijate server po server. Jedan primary ima jedan plafon commitova i jedan volumen za skladište; shardovi taj plafon podižu, zato se pojavljuju u SaaS proizvodima koji svakog mjeseca dodaju klijente. Cijena je složenost: upit bez shard ključa može posjetiti svaki server, a transakcija koja je bila jedan SQL iskaz sada može ići preko mreže.

Usmjeravanje po opsegu, hashu i direktorijumu

Range sharding dodjeljuje pojaseve ključa (tenant 1–5.000, zatim 5.001–10.000). Arhiviranje je jednostavno, ali najnoviji opseg često postane i najopterećeniji.
Hash sharding razbacuje susjedne ključeve po serverima, pa je pisanje ravnomjernije. Opseg poput „tenanti otvoreni ove sedmice” više ne stoji na jednom shardu.
Directory sharding drži mapu ključa na shard. Premještanje tenanta je izmjena u mapi plus kopija podataka, što pomaže kada jedan klijent preraste čvor.

Kako to gradimo

Na PostgreSQL-u obično uzimamo Citus: tabele se dijele po koloni, referentne tabele kopiraju se na svaki čvor, a koordinator planira upite. Na MySQL-u koristimo Vitess, gdje VSchema usmjerava saobraćaj kroz VTGate, a svaki shard je običan MySQL primary sa replikama. Kada svaki zahtjev već nosi tenant_id, dovoljan je mali router u Laravelu ili Node.js-u. Ugrađeni MongoDB balancer ima smisla samo kada su podaci već u obliku dokumenata.

Zapisana mapa shardova i pravilo koje smješta novi ključ.
Usmjeravanje u aplikaciji, u Citusu ili u Vitessu, sa connection poolom po shardu.
Pravilo za posao preko shardova: koji izvještaji smiju ići na sve, a koje treba preprojektovati.
Uvježban način da se doda shard ili premjesti vrući tenant bez dugog locka.

Vertikalno particioniranje tabela i servisa

Vertikalno particioniranje dijeli po obliku, a ne po redovima. Široka tabela proizvoda postaje uzak red koji prodavnica čita na svakoj stranici, plus sporedna tabela za specifikacije i prijevode koje treba samo admin ekran. U većem obimu ista ideja jednu bazu dijeli na zasebne baze po oblasti poslovanja: katalog, narudžbe, naplata. Svaki servis piše u svoje skladište, a ostali za izmjene saznaju preko API-ja ili događaja.

To je često pravi korak prije bilo kakvog horizontalnog sharda. Checkout koji čita osamdeset kolona da prikaže pet plaća širinu reda i indekse na kolonama koje nikada ne filtrira. Šema za izvještaje u istoj bazi kao žive narudžbe takmiči se za disk i lockove. Premještanje hladnih kolona u stranu, ili analitike na repliku, uklanja taj sukob bez sloja za usmjeravanje.

Gdje vertikalna podjela prestaje biti dovoljna

Vertikalni rez ne dodaje kapacitet pisanja jednoj vrućoj tabeli. Ako svaki insert i dalje pada u jednu tabelu orders na jednom primaryju, cijepanje kolona neće podići broj commitova. Strani ključevi također prestaju na granici baze. Tu garanciju zamjenjujemo jasnim provjerama, idempotentnim upisima i poslom koji usklađuje podatke, i dokumentujemo koja su pravila prešla iz baze u aplikaciju.

Raspodjela opterećenja po shardovima i replikama

Shard klaster pomaže samo ako posao stigne tamo gdje ima slobodnog kapaciteta. Usmjeravanje pravimo tako da uobičajen zahtjev ostane na jednom shardu: shard ključ je u WHERE klauzuli, jedan pool opslužuje taj shard, a njegove replike preuzimaju izvještaje i liste. Upiti koji idu na sve shardove i spajaju rezultate ostaju na admin ekranima i zakazanim poslovima, uz timeout i limit redova.

PgBouncer ili ProxySQL ispred svakog sharda, da instance aplikacije ne otvaraju stotine konekcija po čvoru.
Read replike po shardu za izvještaje, izvoze i pretragu u back-officeu, uz vidljivo kašnjenje na dashboardu.
Timeout za upite i rate limiting po tenantu, da jedan bučan klijent ne zaustavi cijeli shard.
Odvojeni poolovi za migracije i batch poslove, da izmjena šeme ne ukrade konekcije checkoutu.

Niz poštanskih sandučića označenih brojevima od jedan do sedam

Vrući shardovi i premještanje tenanta

I dobar hash napravi vrući shard kada jedan tenant čini veliki dio saobraćaja. Mjerimo pisanje i skladište po ključu, ne samo po serveru. Rješenja su poseban shard za tog tenanta, finiji ključ (tenant plus bucket) ili unos u direktorijumu koji samo taj ključ šalje drugdje. Sam premještaj je kopija, kratko sustizanje, kratka pauza pisanja za taj ključ i prebacivanje rute, prvo uvježbano na staging kopiji.

Optimizacija performansi prije i poslije shardinga

Shardovanje spore šeme samo napravi nekoliko sporih šema. Optimizacija performansi ide prva, redom koji troši najmanje novca i pažnje u radu:

Ispravite upite koji dominiraju ukupnim vremenom: indeksi koji nedostaju, N+1 obrasci i izvještaji koji skeniraju žive tabele.
Primaryju dajte dovoljno RAM-a, brz disk i connection pooler prije kupovine drugog servera.
Dodajte read replike i izvještaje šaljite tamo.
Vruće redove keširajte u Redisu, a pretragu proizvoda ili sajta prebacite u search engine.
Najveće tabele particionišite unutar jedne baze, obično po mjesecu, da održavanje dira jedan komad odjednom.
Shardujte tek kada brzina pisanja ili disk jednog primaryja i dalje ne mogu dostići cilj.

Ugrađeno particioniranje je korak koji se miješa sa shardingom. Tabela ostaje na jednom serveru; engine je čuva kao više fizičkih dijelova i preskače one koje upit ne može dotaći. Često je to dovoljno za još godinu rasta. U vodiču o shardingu i particioniranju prolazimo kroz taj izbor. PostgreSQL dokumentacija za particioniranje pokriva sintaksu koju koristimo:

CREATE TABLE events (
  id bigint GENERATED ALWAYS AS IDENTITY,
  tenant_id bigint NOT NULL,
  created_at timestamptz NOT NULL,
  payload jsonb NOT NULL
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_10 PARTITION OF events
  FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');

CREATE INDEX ON events_2026_10 (tenant_id, created_at DESC);

SELECT id, payload FROM events
WHERE tenant_id = 4821
  AND created_at >= '2026-10-01'
  AND created_at <  '2026-11-01'
ORDER BY created_at DESC
LIMIT 50;

Nakon uvođenja shardova podešavanje se nastavlja po čvoru: lokalni indeksi, autovacuum koji stiže da prati pisanje i planovi provjereni na svakom shardu. Spajanje dvije velike distribuirane tabele po koloni koja nije shard ključ prvi je obrazac koji uklanjamo.

Izbor shard ključa s kojim možete živjeti

Shard ključ je odluka s kojom ćete najduže živjeti. Dobar ključ ima veliku kardinalnost, pojavljuje se u skoro svakom upitu osjetljivom na kašnjenje, ravnomjerno raspoređuje pisanje i gotovo se nikada ne mijenja. Kasnija izmjena znači premještanje redova između servera. Za većinu SaaS proizvoda prirodan ključ je id tenanta ili računa, jer su zahtjevi već ograničeni na jednog klijenta.

Loši ključevi: samo created_at (svaki insert pogađa najnoviji shard), status kolona sa nekoliko vrijednosti ili nasumični UUID koji nijedan upit ne filtrira.
Bolji ključevi: tenant_id, account_id ili složeni ključ, tenant plus bucket, kada je jedan tenant ogroman.
Jedinstvenost: jedinstven email ili broj narudžbe jedinstven je samo unutar sharda, osim ako to ne nametnete direktorijumom ili posebnim servisom. To kažemo prije puštanja u rad, a ne nakon drugog duplikata.
Sekvence: autoincrement id na nivou cijele baze će se sudariti ili povezati shardove. Koristimo sekvence po shardu sa pomakom, UUIDv7 ili id koji generiše aplikacija.

Poređenje alata za sharding i particioniranje

Alat biramo prema engineu koji već koristite i prema tome ko će klaster održavati nakon primopredaje.

Pristup	Engine	Težina	Najbolje odgovara	Na šta paziti
Ugrađeno particioniranje	PostgreSQL, MySQL	Niska	Vremenske serije i ogromne tabele na jednom serveru	Ne dodaje kapacitet pisanja dodatnih servera
Citus	PostgreSQL	Srednja	Multi-tenant SaaS kojem treba distribuirani SQL	Joinovi i transakcije preko shardova traže dizajn
Vitess	MySQL	Srednja do visoka	Velika MySQL okruženja koja moraju reshardovati online	VTGate, tableti i VSchema koje treba održavati
Usmjeravanje u aplikaciji	Bilo koja SQL baza	Niska do srednja	Stroga izolacija tenanta, ključ već na svakom zahtjevu	vi vodite routing, migracije i izvještaje preko tenanta
MongoDB sharding	MongoDB	Srednja	Dokumenti koji su već u MongoDB-u	Shard ključ se teško mijenja; pazite na jumbo chunkove

Referentni podaci koje svaki shard treba, poput planova i feature flagova, kopiraju se na svaki čvor ili ih daje mali zajednički lookup. To odlučujemo namjerno, da checkout nikada ne ide preko mreže zbog tabele od tri reda. Gdje koji shard radi prati istu disciplinu kao ostatak platforme; pisali smo o deploymentu na DigitalOceanu, AWS-u, Hetzneru i bare metalu.

Najčešće greške u shardingu baze podataka

Shardovanje baze čiji su spori upiti samo čekali indeks. Fan-out ih učini sporijim, a ne bržim.
Shard ključ koji nije u vrućim upitima, pa svaki prikaz stranice dira svaki server.
Joinovi i transakcije preko više shardova na putu checkouta ili prijave.
Nema plana za tenanta koji pravi 40% pisanja. Hash izgleda fer dok taj klijent ne stigne.
Pretpostavka da globalno unique ograničenje i dalje postoji. Ne postoji, osim ako ste ga sami napravili.
Resharding ostavljen kao slajd u dizajnu, nikada skriptovan i nikada izmjeren na stvarnoj količini podataka.
Backupi koji shardove uhvate u različitim trenucima, pa restore ne može složiti jednu usklađenu sliku. Usklađen oporavak je ovdje jednako važan kao u e-commerceu bez gubitka podataka.

Šta utiče na cijenu sharding projekta

Procjenu dajemo nakon kratkog pregleda šeme, opterećenja upitima i rasta. Faktori su predvidivi:

Hoće li particioniranje, replike ili keširanje odraditi posao umjesto shardinga. To je manji angažman i to ćemo preporučiti ako je dovoljan.
Broj tabela koje treba distribuirati i koliko upita nema shard ključ.
Alat: router u aplikaciji je manje posla od Citusa, a Citus manje od Vitessa kojim upravlja vaš tim.
Koliko postojećih podataka treba premjestiti i da li prelazak mora proći bez prekida rada.
Resharding, premještanje pojedinačnih tenanta i nadzor koji želite od prvog dana.
Jednokratni dizajn i migracija, ili da klaster i dalje vodimo mi.

Kako radimo

Analiza: mjerimo veličine tabela, oblike upita, brzinu pisanja, najtoplije ključeve i način na koji aplikacija otvara konekcije.
Plan: kažemo da li stati na indeksima, replikama ili particioniranju, ili ići na shard, pa se dogovorimo oko ključa, alata i uvođenja.
Izrada: postavljamo usmjeravanje ili ekstenziju, šemu na svakom shardu, pooling, replike i poslove koji prebacuju postojeće redove.
Testiranje: puštamo saobraćaj sličan produkciji, mjerimo premještaj tenanta i provjeravamo backup i restore koji pokriva svaki shard.
Puštanje u rad: prelazimo u fazama, često tenant po tenant ili tabela po tabela, i pratimo kašnjenje, greške i vrijeme odziva.
Podrška: ostavljamo runbook za dodavanje sharda i po želji dalje podešavamo planove i kapacitet kako podaci rastu.

Zašto CodeWiz

Aplikacija i baza zajedno: sami gradimo Laravel, Node.js i WordPress sisteme koji šalju upite, pa se routing i šema mijenjaju kao jedan dizajn.
Sharding na kraju, ne na početku: ako su veći disk, replika ili mjesečna particija dovoljni, to i predlažemo.
Open-source na prvom mjestu: PostgreSQL, Citus, Vitess i MongoDB drže podatke u engineima koje možete pokretati bez iznenađenja sa licencom.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, uz rad na daljinu sa klijentima iz regiona i svijeta.
Ostatak stacka na jednom mjestu: keširanje, hosting, Cloudflare i backupi stoje uz sloj podataka. Saznajte više o CodeWizu.

Često postavljana pitanja

Koliko košta sharding baze podataka?

Zavisi od toga koliko tabela se seli, koji alat koristimo i da li se postojeći podaci moraju prebaciti bez prekida. Podjela jedne tabele iza routera u aplikaciji je fokusiran projekat. Uvođenje Citusa ili Vitessa sa reshardingom i premještanjem tenanta veći je posao. Pisanu procjenu dobijate nakon analize, prije početka rada.

Treba li mi sharding ili jači server?

Većini aplikacija koje pregledamo prije shardova trebaju bolji indeksi, connection pooler, read replika ili particioniranje. Sharding se isplati kada brzina pisanja ili disk jednog primaryja i nakon tih koraka promašuju cilj, ili kada tenanti moraju sjediti na odvojenom hardveru. Reći ćemo vam u kom ste slučaju.

Koja je razlika između shardinga i particioniranja?

Particioniranje dijeli jednu tabelu na dijelove koji i dalje žive u jednoj bazi, pa planer može preskočiti mjesece koji nisu bitni. Sharding dijeli redove na servere, tako da pisanje i skladište rastu u širinu. Particioniranje je jednostavnije. Sharding dodajete kada je plafon pisanja jednog servera stvarna granica.

Možete li shardovati živu bazu bez prekida rada?

Možemo, kada je kopija isplanirana. Tokom prozora za sustizanje pisanje ide na obje lokacije, ili selimo jednog tenanta dok svi ostali ostaju na prvobitnom primaryju. Restore iz dumpa bez probe je način da se izgube narudžbe.

Hoće li ORM i postojeći upiti i dalje raditi?

Upitima koji već filtriraju po shard ključu obično treba samo promjena usmjeravanja. Joinovi preko tenanta, globalni autoincrement ili unique ograničenje preko svih redova traže novi dizajn. Te upite nabrajamo u analizi.

Citus, Vitess ili usmjeravanje u aplikaciji?

Ostanite na engineu koji imate. Citus ako ste na PostgreSQL-u i želite SQL koji može preći shardove. Vitess ako ste na MySQL-u i treba vam online resharding na velikom obimu. Usmjeravanje u aplikaciji ako je svaki zahtjev već vezan za jednog tenanta i želite najmanje nove infrastrukture.

Spremni da skalirate bazu bez prepisivanja?

Recite nam koliko su podaci veliki, koji upiti bole i koliko brzo očekujete rast. Predlažemo particioniranje, replike ili dizajn shardova koji odgovara proizvodu. Kontaktirajte nas da prođemo kroz to, ili pogledajte cijeli obim naših usluga shardinga i particioniranja baze.

Sharding i particioniranje baze podataka