MongoDB - Sharding (Komadanje)
Sharding je proces kojim se postiže čuvanje manjih kolicina informacija (data) na više mašina i na taj način MongoDB odgovara na potrebe koje se javljaju kada količina data-e mnogo raste. U modernim aplikacijama količina informacija može jako brzo da poraste, i često jedna mašina može biti nedovoljna kako za skladištenje tih podataka tako i za obradu "read" i "write" zahteva.
Postoje dve metode kojima se rešava problem prevelike količine podataka:
- Vertikalno skaliranje - podrazumeva povećanje kapaciteta jednog servera, i to tako što se koristi jači CPU, povećava količina RAM memorije ili povećava memorija za skladištenje podataka. Međutim, kako trenutna tehnologija predstavlja limit za vertikalno skaliranje često se dešava da je jedna mašina ipak nedovoljna
- Horizontalno skaliranje - podrazumeva deljenje sistemskog data set-a kroz više servera, dodavajući omoliko servera koliko je potrebno da bi se zadovoljili kapaciteti. Uglavnom brzina i kapacitet jedne mašine nije dovoljno veliki, pa zato svaka mašina obrađuje određeni deo posla što na kraju pruža bolju efikasnost nego jedan veoma jak server. Povećanje kapaciteta se omogućava jednostavnim dodavanjem servera, za razlitikalnog skaliranja kada je potrebno dodavanje jakog hardware-a na jednoj mašini. Što uglavnom bude i jeftinija varijanta. Mana ovom skaliranju jeste komplikovana arhitektura i održavanje sistema. Ovim načinom se obezbeđuje distribuiranost baze.
MongoDB podržava horizontalno skaliranje kroz Sharding.
Sharded Clusters (Iskomadani klasteri)
Implementacija Shard-ova se izvršava korišćenjem klastera koji ne predstavljaju ništa komplikovanije od MongoDB instanci.
Jedan MongoDB Sharded Cluster se sastoji od sledećih komponenti:
- Shard - je osnova i oni sadrže deo sačuvane date. Oni omogućavaju dostupnost i doslednost podataka. I svaki "shard" u produkcionom okruženju moraju biti delovi replika setova.
- Config server (konfiguracioni server) - Predstavlja mongodb intancu koja sadrži metadata-u o klasteru.
- Router (mongos) - mongos se ponaša kao ruter, koji obezbeđuje interface između aplikacije i sharded klastera.
Sledeća slika opisuje komunikaciju između komponenti unutar klastera
MongoDB deli informacije (data-u) na nivou kolekcija, distribuirajući datu kroz "shards"-ove unutar klastera.
Shard Key (ključ shard-a)
Da bi se podelili dokumenti unutar kolekcija, MongoDB pravi particije od kolekcije koristeći shard ključeve. Svaki kljuć sadrži nepromeljivo polje, ili polje koje postoji unutar svakog dokumenta koje se nalazi unutar određene kolekcije.
Taj ključ se bira kada se kolekcija deli, i odabrani ključ se kasnije ne može menjati, jer svaka podeljena kolekcija ima samo jedan ključ.
Odabir ključa je jako bitan, jer loše odabran ključ može uticati na performanse, efikasnost i skalabilnost Sharded klastera, ma koliko dobar hardware i infrastruktura servera bila.
Chunks
MongoDB pravi takozvane "chunks" (komade) prilikom deljenja date. Svaki chunk ima gornju i donju granicu baziranu na shard ključu. (Te granice mogu da budu na primer slova, pa da se u jednom od chunk-ova nalaze svi radnici čija se prezimena nalaze u rasponu od A do E.)
Prednosti korišćenja Sharding procesa
MongoDB distribuira "read" i "write" poslove shard-ovima unutar sharded klastera, i na taj način im omogućava svakom shard-u da radi na određenim operacijama klastera. I "read" i "write" poslovi se mogu skalirati horizontalno kroz klaster, jednostavnim dodavanjem shard-ova.
Za upite koji sadrže konkretne shard ključeve, mongos (ruter) može da targetira specifičan shard ili set shardova koji sadrže taj ključ, i na taj način poveća performanse.
Bitna je činjenica da briga zbog poveća date je minimalna jer se rešava jednostavnim povećanjem kapaciteta klastera.
Velika dostupnost sharded klastera je isto velika prednost, jer oni funkcionišu tako da se read/write operacije mogu izvršavati čak i ako su jedan ili više shard-ova nedostupni. Dok je taj deo date nedostupan, nad ostatkom klastera se operacije normalno izvršavaju.
Mane korišćenja Sharding procesa
Ono o čemu treba razmisliti pre korišćenja Sharding procesa jeste činjenica da kompleksnost i zahtevi ove arhitekture zahteva pažljivo planiranje i izvršavanje i na kraju dugoročno održavanje.
Primer
Koraci za ovaj postupak bi bili sledeći
Korak 1) Kreiranje posebne baze za potrebe config servera
mkdir /data/configdb
Korak 2) Pokretanje mongodb instance. Na primer ako nam se server koji će nam biti konfiguracioni server zove Server1, komanda bi bila sledeća
mongod -configdb Server1: 27019
Korak 3) Pokretanje mongos instance specifirajući konfiguracioni server
mongos -configdb Server1: 27019
Korak 4) Iz mongo shell-a konektujemo se na mongo instancu
mongo –host Server1 –port 27017
Korak 5) Na primer imamo Server2 i Server3 koje treba da dodamo u klaster, komande su sledeće
sh.addShard("Server2:27017")
sh.addShard("Server3:27017")
Korak 6) Omogućavanje sharding procesa unutar baze podataka (ako bi se baza zvala "Studentidb")
sh.enableSharding(Studentidb)
Korak 7) Omogućavanje sharding procesa za kolekcije. Ako imamo kolekcije "studenti" i "ispiti"
Sh.sharedCollection("db.Employee" , { "studenti" : 1 , "ispiti" : 1})