Particionisanje Flashcards
Sta je particionisanje
Kako je replikacija jedan od osnovnih alata za postizanje performansi pitanje je sta se desava kod velikih baza.Ona nije dovoljna zato se uvodi particionisanje.Particije se prave tako da jedan podatak odgovara tacno jednoj particiji (svaka particija se smatra kao minijaturna baza)
- Particionisanje ima posebno dobre performanse na SHARED NOTHING arhitekturama:
– particije mozemo distribuirati na vise diskova,i sav query load na vise procesora
– Kada querijemo podatke na jednoj particiji,svaki moze nezavisno izvrsavati query-je za svoje podatke (read operacije se izuzetno lako skaliraju,sve dok su queriji lokalizovani)
Particionisanje Key/Value podataka
Cilj kod particionisanja je da sto ravnomernije rasporedimo load po nodovima
- da bi smo postigli linearnost performansi
- ukoliko raspodela particija nije fer,onda ce neki nodovi biti optereceniji od drugih (ova pojava je partition skew)
sta to tacno znaci jeste da ako se popularni kljucevi nadju na jednoj particiji moze doci do blokiranja
- Najlakse resenje za eliminaciju skew-a je da kljuceve rasporedjujemo po random funkciji
–nemamo lak nacin da znamo na kojoj je particiji,moramo sve particije da pitamo da li imaju odredjeni kljuc
Particionisanje po key range-u
-Efikasan nacin za rasporedu kljuceva po particijama je pravljenje ranga (lowerbound i upperbound)
– mozemo unapred znati na kom nodu se nalazi neki key range
-Treba uvek drzati na umu da podaci ne moraju biti jednako rasporedjeni po kljucevima
–Particije moramo prilagoditi tako da budu jednake po kolicini podataka
Prilikom particionisanja po kljucevima pozeljno je da kljucevi budu sortirani (znaci koristiti SSTable, ako zelimo vise pogodnosti mozemo konkatenirati vise polja u jedno)
Glavni nedostatak particionisanja po key-rangu je da odredjeni slucajevi rezultuju hot-spotovima
(primer: ako nam je timestamp jedan dan onda svi danasnji write-ovi ce ici na samo jednu particiju,dakle apsolutni hotspot za write operacije)
Particionisanje po Hash-u kljuca
Kao jedno od resenja za hot-spotove jaljva se koriscenje hash funkcija za raspodelu.
Umesto raspon ljuceva,rasporedjujemo raspon hash vrednosti
-Glavna prednost je da skew-ovane podatke uniformno rasporedjuje, medjutim gbimo sortiranost podataka,i svaki query koji zahteva “vise” redova mora biti slan na vise replika
Ekstremni skew i hotspot
Koriscenje navedenih strategija mozemo ukloniti vecinu skew-a tradicionalnog load-a.
Medjutim postoje slucajevi gde je sav load na nekolicini izuzetno aktivnih kljuceva.
Prvi korak je prirodno da odredimo ovakve ekstremne kljuceve,nakon toga mozemo pri svakom write zahtevu kljucu dodati random dvocifreni broj ,sto ce rezultovati ravnomernom raspodelom na 100 particija
Sekundarni indeksi i participnisanje
Do sada smo samo obradjivali key-value skladista,gde svaki read ili write radi iskljucivo po nekom kljucu, medjutim vecina workload-ova zahteva query i po necemu sto nije primarni kljuc. Sekundarni indeksi su standardna praksa u noSQL bazama.
Glavni problem sa sekundarnim indeksima je to sto se ne mapiraju lako na particije, moramo koristiti specificne strategije indeksiranja kao sto su document-based indeksiranje i Term-based indeksiranje
Document-Based indeksiranje
Kon indeksiranja baziranog na dokumentu ,mozemo koristiti sekundarni indeks na nivou jedne particije, takodje se ponekad zove i lokalni indeks.
Svaka particija vodi racuna o sopstvenom sekundarnom indeksu i nije svesan drugih particija
Ukoliko je particionisanje samo po kljucu imamo problem zato sto podaci sa datim indeksom biti razbacani na sve particije pa moramo query-ovati sve particije ukoliko zelimo neki podatak , ovakav nacin pretrage se naziva SCATTER/GATHER veoma je podlezezan latency amplifikaciji,uprkos tome puno se koristi.
Da bi izbegli scatter/gather pozeljno je da ipak svi querriji koji gadjaju sekundarni ineks budu opsluzeni od strane jedne particije, sto je skoro pa nemoguce ukoliko imamo kompleksan query koji koristi vise sekundarnih indeksa
Term-based indeksiranje
Za razliku od document-based indeksiranja,term based koristi globalni indeks.
Posto ne mozemo da cuvamo na jednoj particiji(bottleneck) i sam indeks cemo particionisati.
Glavna prednost term based indeksiranje je sto ima bolje preformanse u odnosu na scatter-gather, medjutim write operatije su spore ,zbog odrzavanja particionisanog indeksa.Promena jednog dokumenta moze menjati indesk na vise particije.
Imamo takodje i problem oko toga koliko je sam indeks “up-to-date”.Ubacivanje u particionisan indeks bi trebalo biti sinhrona radnja.
Rebalansiranje particija
Tokom vremena nas sistem bi trebalo da iskusi, query throughput se povecava pa moramo dodati jos CPU-a za ovaj load, dataset se povecava,treba veci broj hard diskova,masine padaju,pa moraju da se menjaju.
Svaka od ovih stvari zahtevaju pomeranje sa jednog node-a na drugi.
-Proces pomeranja loead-a sa jednog noda na drugi se zove rebalansiranje.
Rebalansiranje je svesno particija,i mora ispuniti odredjene uslove:
1. nakon rebalansiranja,opterecenje bi trebalo da bude ravnomerno rasporedjenjo izmedju node-ova.
2.Dok se sistem rebalansira,node-ovi moraju nastaviti sa svojim regularnim radnjama
3.Samo minimalna potrebna kolicina podataka treba biti premestena izmedju node-ova kako bi rebalansiranje bilo brzo.
Rebalansiranje hashiranjem
Svakome bi palo na pamet da radimo hasiranje sa modN ali to je losa ideja zato sto se onda promenom broja nodova svaka particija mora menjati sa mod(N+1) pa menja node…
Laksa varijanta je da jednostavno particijama dodeljujemo neki range(lowerbound i upperbound)
Rebalansiranje sa finksim brojem particija
Pravimo veci broj particija nego sto imamo nodova i dodeljujemo vise particija jednom nodu
Dodavanjem novog noda,jednostavno moze da “ukrade” par particija sa ostalih nodova kako bi se napunio ,Ukooliko uklonimo dode ,isto se desava samo u obrnutom redosledu.Samo CELE particije mozemo prebacivati izmedju nodo-va.Broj particija je uvek FIKSAN.Jedino sto se menja je broj node-ova i dodela particija
Dinamicko particionisanje
Ukoliko koristimo key-range particionisanje,fiksan broj particija nam ne odgovara previse,ukoliko lose definisemo key range,svi podaci ce nam zavrsiti u samo par node-ova
Umesto da fiksiramo broj particija, dozvolicemo sistemu da sam kreira particije, kada particija poraste dovoljno biva podeljena nu 2 particije gde svaka dobija pola podataka,svaka particija se dodenjuje jednom node-u.medjutim node moze primati vise particija.
Glavna prednost dinamickog particionisanja je da se broj particija skalira sa velicinom dataset-a, generalno dobre performanse sa niskim overhead-om
Losa strana je da kada kreiramo bazu,imamo samo jednu particiju koju obradjuje samo jedan node,dosta baza dozvoljava pre-splitting koji sluzi da unapred uapravi odredjeni broj particija
Dinamicko particionisanje se moze raditi i nad hash range-ovima kao i nad key-range-ovima
Particionisanje proporcionalno node-ovima
Dinamicko particionisanje i fiksan broj particija su uzimali u obzir samo broj particija, dok nas broj nodova sistema nije zanimao
Automatsko ili Manualno particionisanje
-Iako je potpupuno automatsko particionisanje pogodno i zahteva malo “truda” u praksi i nije tako
–Automatsko rebalansiranje ima obicaj da bude poprilicno nepredvidljivo,sto je veoma nepogodno zbog skupoce same operacije particionisanja
-Posebna problematika se moze javiti kod labavog failure detection-a
-Generalno je dobra praksa da uvek postoji covek koji nadgleda sistem i odobrava skupe operacije.Nije tolko brzo,ali generalno moze izbegnuti itekako gadne posledice.
Rutiranje
Do sada smo pričali o particijama bez pomisli o tome kako korisnik treba da zna, koji node tačno treba da gađa.
Kako se particije rebalnsiraju, tako se i pomeraju po node-ovima.
Potreban je mehanizam praćenja lokacija svih particija
Postoji par rešenja:
Dozvolimo klijentu da kontaktira bilo koji node (po round robin balanseru). Ukoliko ima tu particiju, odgovara, ukoliko nema, prosleđuje node-u koji ima.
Imamo routing tier u našoj bazi, koji tačno utvrđuje kojem nodu korisnik treba pristupiti. Routing tier nema nikakvu drugu svrhu, osim čistog rutiranja (Partition aware load balanser)
Klijenti mogu biti svesni particija i dodele particija node-ovima. U ovom slučaju klijent se može direktno povezati sa node-om koji mu treba. (Sračuna hash vrednost ključa, i prosledi lokalnoj biblioteci)
Problematika rutiranja sa particijama leži u tome što svi moraju da se slože o tome gde se nalazi koja particija.
U suprotnom requestovi će biti slani pogrešnom node-u. (Što će izbacivati errore ili uvesti dodatni lag)
Većina sistema se oslanja na eksterne alate za praćenje particija i koordinaciju njima
