Deljenje baze podataka je tehnika koja se koristi za postizanje horizontalne skalabilnosti u velikim sistemima.
Gotovo svi sistemi u realnom svetu se oslanjaju na servere baza podataka koji primaju ogroman broj zahteva za čitanje, kao i značajan broj zahteva za pisanje. To može dovesti do preopterećenja servera i negativno uticati na performanse sistema.
Da bi se ublažili ovi problemi i poboljšale performanse sistema, koriste se različiti pristupi, kao što su replikacija baze podataka i deljenje baze podataka. U ovom vodiču ćemo najpre istražiti tehnike za poboljšanje performansi sistema, uključujući:
- Povećanje kapaciteta servera baze podataka
- Replikaciju baze podataka
- Horizontalno particionisanje
Nakon diskusije o ovim tehnikama, nastavićemo da istražujemo kako funkcioniše deljenje baze podataka i razmotrićemo prednosti i ograničenja ovog pristupa.
Započnimo!
Tehnike za poboljšanje performansi sistema
Počećemo sa pregledom tehnika za poboljšanje performansi sistema kada server baze podataka postane usko grlo:
#1. Povećanje kapaciteta servera baze podataka
Nadogradnja servera baze podataka, odnosno povećanje njegove procesorske snage, dodavanje više RAM-a i slično, može se činiti kao jednostavan pristup za poboljšanje performansi sistema.
Međutim, ova tehnika ima svoja ograničenja. Ne možemo imati server sa beskonačnim kapacitetom za skladištenje i obradu podataka. Takođe, nakon određene granice, povećanje kapaciteta donosi sve manje poboljšanja.
#2. Replikacija baze podataka
Kada server baze podataka postane preopterećen zbog velikog broja zahteva, možemo razmotriti replikaciju baze podataka.
U okviru replikacije baze podataka, postoji jedan glavni čvor koji obično prihvata zahteve za pisanje, kao i više replika za čitanje.
Ovo poboljšava dostupnost i ublažava preopterećenje sistema. Sada možemo paralelno obraditi više upita, jer se zahtevi za čitanje mogu usmeriti na jednu od replika za čitanje.
Ali to uvodi novi problem. Zahtevi za pisanje na glavnom čvoru mogu promeniti podatke, a ova ažuriranja se periodično propagiraju na replike za čitanje.
Pretpostavimo da postoji zahtev za čitanje na jednoj od replika za čitanje u isto vreme kada je operacija pisanja u toku na glavnom čvoru.
Promene na glavnom čvoru još uvek nisu propagirane na replike za čitanje. U ovom slučaju, možemo čitati zastarele podatke, što nije poželjno.
#3. Horizontalno particionisanje
Horizontalno particionisanje je još jedna tehnika za optimizaciju performansi sistema. Možemo imati jednu veliku tabelu sa milijardama redova (na primer, tabela kupaca i podataka o transakcijama).
Operacije čitanja iz takve tabele baze podataka su spore. Međutim, korišćenjem horizontalnog particionisanja, jedna velika tabela je podeljena na više particija (ili manjih tabela) iz kojih možemo da čitamo. Relacione baze podataka, kao što je PostgreSQL, imaju nativnu podršku za particionisanje.
Ipak, sve particije su i dalje unutar jedne instance servera baze podataka. Jedina razlika je u tome što sada možemo da čitamo iz particija umesto iz jedne velike tabele.
Stoga, kada se poveća broj dolaznih zahteva, server možda neće moći da podrži povećanu potražnju.
Kako funkcioniše deljenje baze podataka?
Sada kada smo razmotrili pristupe za poboljšanje performansi sistema i njihova ograničenja, hajde da razumemo kako funkcioniše deljenje baze podataka.
Kod deljenja, jednu veliku bazu podataka delimo na više manjih baza podataka, od kojih svaka radi na instanci servera baze podataka. Svaka takva manja baza podataka se naziva šard. I svaki šard sadrži jedinstveni podskup podataka.
Ali kako podelimo bazu podataka na šardove? I kako odlučujemo koji red ide u koji šard?
🔑 Tu na scenu stupa ključ za deljenje.
Razumevanje ključa za deljenje
Razjasnimo ulogu ključa za deljenje.
Ključ za deljenje, koji je obično kolona (ili kombinacija kolona) u tabeli baze podataka, treba izabrati tako da distribucija podataka bude ravnomerna u više šardova. Ne želimo da neki šard bude mnogo veći od ostalih.
U bazi podataka koja čuva podatke o klijentima i transakcijama, customer_ID je dobar kandidat za ključ za deljenje.
Kada se odlučimo za ključ za deljenje, možemo kreirati funkciju heširanja koja određuje koji od redova ide u koji od šardova.
U ovom primeru, pretpostavimo da treba da podelimo bazu podataka na pet šardova (šard od 0 do šard 4) koristeći customer_ID kao ključ za deljenje. U tom slučaju, jednostavna funkcija heširanja je customer_ID % 5.
Sve vrednosti customer_ID koje daju ostatak nula pri deljenju sa 5 će biti mapirane na šard broj 0. A vrednosti customer_ID koje daju ostatke od 1 do 4 će biti mapirane na šard od 1 do šard 4, respektivno.
Nakon što je deljenje baze podataka implementirano na ovaj način, važno je imati sloj za rutiranje koji usmerava dolazne zahteve na ispravan šard baze podataka.
Prednosti deljenja baze podataka
Evo nekih od prednosti deljenja baze podataka:
#1. Visoka skalabilnost
Uvek je moguće podeliti veću bazu podataka na više manjih šardova. Dakle, deljenje baze podataka nam omogućava horizontalno skaliranje.
#2. Visoka dostupnost
Kada postoji jedna instanca servera baze podataka koja obrađuje sve dolazne zahteve, imamo jednu tačku greške. Ako server baze podataka prestane da radi, cela aplikacija prestaje da radi.
Sa deljenjem baze podataka, verovatnoća da će svi šardovi baze podataka prestati da rade u datom trenutku je relativno mala. Zbog toga, ako je određeni šard neispravan, nećemo moći da obradimo zahteve za čitanje tog šarda. Ali drugi šardovi i dalje mogu da obrađuju dolazne zahteve. Ovo rezultira visokom dostupnošću i povećanom otpornošću na greške.
Ograničenja deljenja baze podataka
Pređimo sada na neka od ograničenja deljenja baze podataka:
#1. Složenost
Iako deljenje ima prednosti u smislu skalabilnosti i tolerancije na greške, ono uvodi složenost u sistem.
Od mapiranja zapisa na particije, preko implementacije sloja za rutiranje za usmeravanje upita do odgovarajućih šardova, postoji značajna složenost koja je povezana sa deljenjem baze podataka.
#2. Ponovno deljenje
Još jedno ograničenje deljenja je potreba za ponovnim deljenjem.
Iako koristimo funkciju heširanja da bismo dobili ravnomernu distribuciju zapisa podataka, moguće je da je jedan od šardova mnogo veći od drugih i da se može brže iscrpeti. U tom slučaju, moramo da razmotrimo ponovno deljenje (ili preuređivanje), a to ima značajne troškove.
#3. Pokretanje složenih upita
Kada treba da pokrenete upite za analizu koji uključuju spajanja, morate da koristite zapise iz više šardova umesto iz jedne baze podataka. Dakle, to može biti izazov kada treba da pokrenete previše analitičkih upita. To možete zaobići denormalizacijom baza podataka, ali to i dalje zahteva određeni napor!
Zaključak
Završimo diskusiju rezimiranjem onoga što smo naučili.
Povećanje hardvera nije uvek optimalno. Stoga se ne preporučuje nadogradnja instance servera. Takođe smo razmotrili tehnike kao što su replikacija baze podataka i horizontalno particionisanje i njihova ograničenja.
Zatim smo naučili kako funkcioniše deljenje baze podataka tako što smo veliku bazu podataka podelili na manje šardove kojima je lakše upravljati. Razgovarali smo o tome kako ključ za deljenje treba pažljivo izabrati kako bi se dobile ravnomerno raspoređene particije, i o potrebi za slojem za rutiranje koji bi usmeravao dolazne zahteve na ispravan šard baze podataka.
Deljenje baze podataka ima prednosti kao što su visoka dostupnost i skalabilnost. Neki od nedostataka uključuju složenost podešavanja deljenja i ponovnog deljenja kada se jedan ili više šardova iscrpe.
Dakle, možete razmotriti deljenje kada mislite da prednosti nadmašuju složenost koju ono uvodi. Zatim pogledajte poređenje različitih AWS relacionih baza podataka.