Ledia Hajdëri – Teknologjite e Cloud Computing
“Sharding”: copëtimi horizontal i të dhënave
“Sharding” është një model kërkese për përmirësimin e shkallëzimit dhe xhiros së aplikimeve të
të dhënave në shkallë të gjerë. Termi “sharding", ka të bëjë me procesin e copëzimit të një baze
të dhënash logjike në copëza më të vogla të të dhënave, dhe shpërndarjen e copezave të të
dhënave në shumë databaza fizike për të arritur shkallëzim maksimal të aplikimit. Çdo databaze
fizike në këtë arkitekturë i referohemi me termin “shard”.
Në një aplikim të copëzuar siç është përshkruar më lartë, rreshtat e një baze të dhënash logjike
shpërndahen nëpër baza të dhënash të ndara fizike. Kjo ndryshon nga rasti kur ndarja bëhet
vertikalisht duke vënë një grup të tërë të entiteteve të të dhënave në një bazë të dhënash të ndarë
fizike, psh. porositë dhe konsumatorët vendosen në baza të ndryshme të dhënash. Ndarja e të
dhënave sipas vlerës (çelësit të ndarjes) siguron për nga potenciali shkallëzim më të madh se një
dizajn i ndarë vertikalisht duke qenë në gjendje për të ndarë të dhënat në mënyrë të vazhdueshme
në më shumë copa që përhapen në një numër në rritje të pjesëve në varësi të rritjes së kërkesës.
Implementimi i propozuar do të lidhë të dhënat me pjesë specifike duke aplikuar një ose më
shumë strategji mbi një "çelës ndarës", i cili është çelësi kryesor në një nga entitetet e të dhënave.
Entitetet e referuara të të dhënave janë të grumbulluara në një grup bazuar në çelësin ndarës
dhe kësaj njësie i referohemi si njësi atomike. Të gjitha të dhënat në një njësi atomike ruhen
gjithmonë në të njëjtën ndarje (shard).
Njësia atomike formon një koncept bazë arkitekturor që përdoret nga infrastruktura ndarëse si një
bazë për qasje të qëndrueshme të të dhënave ndërsa ndarjet (shards) shtohen dhe hiqen
dinamikisht nga aplikimi. Infrastruktura e ndarjes duhet të sigurojë që të gjitha entitetet në një
njësi atomike janë gjithmonë në të njëjtën ndarje. Kjo lehtëson lidhjet dhe grupimet, dhe është
një nga përfitimet kryesore të Federatës së SQL Azure që përfundimisht do të implementohet në
infrastrukturën sharding, duke bërë të mundur shkallëzim elastik të qëndrueshem.
Duke u fokusuar në njësinë atomike si një pjesë e qëndrueshme të dhënash, infrastruktura
“sharding” do të jetë në gjendje të ndërmarrë veprime automatike sipas rregullave për të shtuar
ose hequr copëza në varësi të kërkesave në rritje apo në rënie. Pas shtimit apo heqjes së
“copëzave”, njësitë atomike duhet të lëvizin përgjatë copëzave për të optimizuar komunikimin me
të dhënat. Gjatë procesit të lëvizjes së të dhënave infrastruktura “sharding” duhet të sigurojë që
1
Ledia Hajdëri – Teknologjite e Cloud Computing
çdo njësi e veçantë atomike e të dhënave do të jenë gjithmonë në dispozicion në vendndodhjen
aktuale ose në një pozicion të ri, por gjithmonë në një vend transparent për aplikimin.
1 Përfitimet e “sharding” me SQL Azure
Sharding si koncept ka qenë i mundshëm në forma të ndryshme për vite me rradhë dhe është
fokusuar kryesisht në implementime bazuar në infrastruktura vetë-hostuese që adresojnë nevojat
e mëposhtme:

Shkallëzim duke përdorur dhjetëra, qindra apo mijëra nyje bazës së të dhënave duke
përdorur pajisje fizike të lira në vend të sistemeve të shtrenjta,

Performancë të shkallëzuar me rritjen e numrit të nyjeve, dhe

Dhënja e një zgjidhjeje me një raport të shkëlqyer çmim-performancë që rrjedhin nga
përdorimi i pajisjeve të lira (për përdorim desktopi) në vend të serverave të shtrenjtë të
aplikimit.
Është e mundshme për të ndërtuar një projekt “sharding” të vetë-hostuar, (në të vërtetë deri
më sot shumica është ndërtuar në këtë mënyrë), por projektet “sharding” të vetë-hostuara ka
disa çështje të rëndësishme:

Shkallëzimi është bërë në nivelin e aplikimit, dhe aplikimi duhet të menaxhojë të gjitha
detajet e ndarjes së të dhënave,

Në nivel aplikimi është zbatuar kontrolli i tepricës dhe disponueshmëri mjaft e lartë në
vend të pajisjeve fizike të brendshme ose fabrikës së të dhënave të “Cloud”,

Ribalancimi i copëzave është i vështirë dhe shpesh realizohet si një proces “offline”,

Administrimi fizik i pajisjeve fizike dhe sistemit në nivel programi bëhet gjithnjë e më i
vështirë me rritjen e numrit të bazave të të dhënave, dhe

Shpenzimet kapitale në servera janë të ndaluara.
SQL Azure ofron një aftësi të veçantë (unike) për zgjidhjen e çështjeve të ndërtimit të një aplikimi
“sharded” vetë-hostues përmes aftësive elastike ofruar nga platforma Azure si një shërbim.
Përfitimet kryesore janë:
 E gjithë infrastruktura është e menaxhuar
2
Ledia Hajdëri – Teknologjite e Cloud Computing
SQL Azure përmbledh pjesën logjike nga administrimi fizik. SQL Azure trajton të gjitha detyrat
në nivel fizik të tilla si përditësimi i serverave, pajisjeve për depozitimin e të dhënave etj.,
ndërsa klientët duhet të merren vetëm me administrimin e bazave të të dhënave logjike.
 Sigurimi elastik i nyjave
Krijimi i një copëze të re dhe shtimi i saj në një aplikim “sharded” mund të kryhet duke përdorur
Menaxhim Portal te Windows Azure ose nëpërmjet DDL. SQL Azure eleminon nevojën për të
marrë muaj për të blerë, konfigurim dhe për të vendosur hardware të ri dhe të sistemeve të
bazës së të dhënave. Përveç kësaj, kërkesat që kanë nevojë për dhjetëra, qindra apo edhe
mijëra baza të të dhënave për një periudhë të shkurtër kohe mund ta bëjnë këtë dhe pastaj te
ridepozitojne bazat e të dhënave kur bie kërkesa.
 Pagesa sipas kërkesës
SQL Azure ka një model linear çmimi që është shumë tërheqës për zgjidhjet sharding si psh.
shuma në muaj për hapësirën në Gigabyte është lineare me rritjen e madhësisë së bazës së
të dhënave. Kjo i lejon konsumatorët që të ketë mundësinë për të parashikuar saktësisht
shpenzimet që do të kenë, në varësi të rritjes apo zvogëlimit të sistemit. Gjithashtu, për shkak
se bazat e të dhënave janë në versione të ndryshme (Web dhe Biznes) me kufinj të ndryshëm
në varësi të madhësisë, përdorues të ndryshëm mund të kenë kontroll mbi copëtimin e
kostove në rritje ndërkohë që një zgjidhje “sharding” zgjerohet vazhdimisht me të dhëna.
 Disponueshmëri e lartë
SQL Azure ofron një SLA me disponueshmëri të lartë 99,9% për të gjitha bazat e të dhënave,
nuk ka nevojë për të implementuar RAID dhe teknika të tjera. Infrastruktura “Cloud” ka
kompleksitetin e vet, dhe ndërtimi i një projekti të copëzuar në SQL Azure të sotëm kërkon
projektim të kujdesshëm duke patur parasysh kompleksitetin e tij unik:
 Kufizim maksimal i burimeve në bazat e të dhënave individuale SQL Azure
Ka kufizime praktike dhe teknike të vendosura në SQL Azure mbi madhësinë maksimale të
të dhënave të vendosura në një bazë të dhënash të vetme. Ndërsa këto madhësi vazhdojnë
të rriten me kalimin e kohës, ata do të vazhdojnë të mbeten relativisht të vogla në krahasim
me madhësinë e përgjithshme te kërkuara nga disa projekte sharded.
 Ulja e performances nga shumë drejtime dhe menaxhimi i lidhjes
3
Ledia Hajdëri – Teknologjite e Cloud Computing
Bazat e të dhënave në SQL Azure mund të ulin performancën në përpjekje për të siguruar një
cilësi minimale të nivelit të shërbimit. Kërkesat e lëshuara nga një aplikim që konsumojnë më
shumë se pjesa e caktuar për to do të përfundohen nga SQL Azure, dhe meqë SQL Azure ofron
shërbime të shumta me qera edhe kërkesat e lëshuara nga një aplikim tjetër gjithashtu mund të
ndikojnë performancën aplikimit. SQL Azure mund të përfundojë sesione boshe në intervale të
rregullta për të ruajtur burimet e sistemit, duke kërkuar që aplikimi të jetë në gjendje për të
realizuar rigjenerim të sesioneve automatikisht. Me shtimin dhe heqjen e copëzave dinamikisht,
menaxhimi i lidhjeve kthehet në sfidë, ndërkohë që aplikimi duhet të jetë në gjendje të rikrijojë
lidhjet me ndryshimin e copëzave.
 Copëzimi me SQL Azure aktualisht bëhet në nivel aplikimi
Versioni aktual i SQL Azure nuk ka ndonjë mbështetje të veçantë për copëzimin, dhe për këtë
arsye aplikimi është përgjegjës për të gjitha aspektet e copëzimit derisa janë mundesitë në
Federatën e SQL Azure.
 Ribalancimi i copëzave është një proces i shkëputur
Shtimi ose heqja e copëzave nga një aplikim “sharded” mund të jetë një proces i komplikuar, pasi
rregullat për gjetjen e të dhënave duhet të ndryshohen kur modifikohet infrastruktura fizike. Përveç
çështjeve të përmendura më pare, në lidhje ndikojnë edhe çështje në nivel të dhënash si
menaxhimi i çelësave që mund të kërkojë rishkrimin e çelësave ndërkohë që të dhënat lëvizin
ndërmjet copëzave. Kjo shpesh çon në faktin se zgjidhjet sharding, madje edhe me SQL Azure
janë në gjendje për të krijuar bazat e të dhënave pothuajse menjëherë, por ende mund të kenë
nevojë për të kaluar në shkëputje për një kohë të pacaktuar ndërkohë që të dhënat përshtaten
me strukturën e re të federatës.
Figura 1: Federatat e SQL Azure
4
Ledia Hajdëri – Teknologjite e Cloud Computing
Krijimi i një librarie sharding në ADO.NET me porosi e kombinuar me funksionalitete të versioneve
të mëvonshme të Azure, duke përfshirë dhe Federatat SQL Azure, jep një infrastrukturë të
përparuar, fleksibël, të shkallëzuar dhe ekonomike për aplikimet sharding.
2 Një përmbledhje e “Sharding”
Sharding është një model aplikimi ku aplikimi particionon të dhënat e tij horizontalisht ndërmjet
shumë bazave të të dhënave me qëllim drejtimin e udhëzimin e bazave të të dhënave të shumta
SQL Azure.
Ky seksion paraqet një prototip arkitekturor sharding përmendur shpesh si një model sharding
multi-master.
3 Modeli arkitekturor sharding multi-master
Figura 2: Modeli Multi-Master
Në këtë prototip sharding të gjitha copëzat e bazës së të dhënave janë konsideruar të lexueshme
dhe të shkrueshme, nuk ka replikime të pandara të të dhënave në mes të copëzave, dhe modeli
është referuar si "asgjë e përbashkët" duke qënë se nuk ka të dhëna të ndara ose të përsëritura
mes copëzave. Një aplikim duhet të përdorë një prototip multi-master nëse:
•
Klientët dhe sistemi kanë nevojë për akses për të lexuar / shkruar të dhëna
•
Aplikimi ka aftësinë për të rritur vazhdimisht të dhënat
•
Shkallëzimi linear i aksesimit të të dhënave është i nevojshëm me rritjen e madhësisë
së të dhënave
•
Të dhënat e shkruara në një copë duhet të jenë menjëherë të aksesueshme për çdo
klient
Në një prototip multi-master, për shkak se të dhënat janë të ndara ose të replikuara ndërmjet
copëzave, aplikimi është plotësisht përgjegjës për mënyrën se si shpërndahen të gjitha
operacionet e bazës së të dhënave në copëzat e përshtatshme, dhe në mënyrën se si
5
Ledia Hajdëri – Teknologjite e Cloud Computing
menaxhohet qasja seriale ose paralele me të gjitha copëzat. Kjo detyrë mund të bëhet e vështirë
për t’u menaxhuar me rritjen e madhësisë së bazës së të dhënave dhe numrit të copëzave.
4 Sfidat e Sharding
Sharding mund të sigurojë shkallezim të madh për një aplikim, por edhe komplikon aplikimin për
shumë arsye. Aplikimi duhet të shpërndajë të dhënat e tij ndërmjet shumë serverave të bazës së
të dhënave dhe koordinimi i aksesit në servera kërkon nga aplikimi të marrë përsipër përgjegjësi
të rëndësishme për ndarjen e aksesit të të dhënave në të gjithë copëzat.
Një kërkesë që merr përsipër të ndajë të dhënat e saj bëhet një shërbim i orkestruar me të dhëna
nga copëzat, e cila për fat të keq largon fokusin e aplikimit nga fusha e problemit ku është
menduar të adresojë në detaje të implementimi për çdo copëz.
Në vijim janë çështjet që ngrihen zakonisht gjatë ndërtimit të një aplikimi sharded të çdo shkallë:
4.1 Aksesi i shpërndarë i të dhënave
Shqetësimi kryesor i një zgjidhje sharding është shpërndarja e shkallëzuar dhe tërheqja e të
dhënave ndërmjet shumë instancave të bazës së të dhënave. Kjo natyrë e shpërndarë e
arkitekturës ndikon në të gjitha metodat e qasjes së të dhënave (krijimi, leximi, modifikimi dhe
fshirja) dhe sistemi sharding duhet të ketë aftësinë për të ditur se si të menaxhojë manipulimin e
të dhënave ndërmjet shumë databazave.
Këto qendra të aplikimit janë në gjendje të:

Përcaktojnë se në cilën copë duhet të ruhet një subjekt i ri, dhe

Se si e ruan aplikimi se në cilën copë është ruajtur subjekti në mënyrë të mund të merret,
përditësohet, fshihet në mënyrë efikase në një kohë më të vonë.
4.2 Përcaktimi i njësisë që do të përdoret për të ruajtur një pjesë të re të të dhënave
Cilën njësi do të zgjedhë aplikimi, i ballafaquar me një numër njësish në të cilën mund të shkruajë
një pjesë të të dhënave? Ka shumë strategji për marrjen e këtij vendimi, duke përfshirë balancimin
e ngarkesës, algoritmi “round-robin”, kriptim bazuar në një çelës dhe thjesht shkrimi i të dhënave
për të gjithë njësitë. Secila nga këto teknika ka dizajn, performancë dhe çështje operative të
ndryshme të cilat duhet të trajtohen nga një aplikim.
6
Ledia Hajdëri – Teknologjite e Cloud Computing
4.3 Si mund të tërhiqen në mënyrë efikase të dhënat e ruajtura
Rikthimi i të dhënave është i komplikuar pasi ka nevojë për të përcaktuar njësinë që mban
elementin dhe varet nga lloji i rregullave që përdor aplikimi për të përcaktuar vendin në të cilin do
të ruhen të dhënat. Aplikimi duhet të përcaktojë në një farë mënyre çelësin e të dhënave dhe
pastaj të nxjerrë një përfundim me anë të një algoritmi nga shumë të tillë apo të përdorë pyetje
paralele për të gjitha njësitë (e cila nuk është shumë e efektshme).
4.4 Gjenerimi i ID
Gjenerimi i ID mund të përdoret në mënyrë efikase për të ruajtur dhe rifituar të dhënat. Magazinimi
dhe marrja e artikujve në një aplikim sharded realizon në vija të përgjithshme marrjen e një pjese
të të dhënave dhe gjeneron një ID të cilën sistemi mund ta përdorë në mënyrë efikase per te
depozituar dhe tërhequr artikullin nga njësia. Mundësitë e zgjedhjes për këtë përdorim përfshijnë
kriptime të ndryshme dhe funksione lidhëse, algoritme specifike për gjenerimin e ID, apo me një
aplikim sharding të bazuar në gjenerim ID që mund të trajtojë procesin në emër të aplikimit.
4.5 Ekzekutim paralel ose sekuencial i kërkesave në njësi
Kur kemi nevojë për të kërkuar në njësi të shumta për një artikull ose një sërë artikujsh, lind pyetja
nëse aplikimi do të kërkojë njësitë në mënyrë sekuenciale apo paralele? Secili ka implikime të
performancës për aplikimin, dhe modeli paralel paraqet nevojën për të trajtuar njëkohshmërinë e
veprimeve (kërkesat me shumë procese për të dhënat). Megjithëse qasja në paralel në pamje të
parë duket si një mënyrë e natyrshme për të marrë të dhënat nga të gjitha njësitë, nëse të dhënat
janë të gjitha vetëm në një njësi atëherë të gjitha njësitë e tjera shfrytëzojnë burime të
panevojshme për trajtimin e kërkesave që ata nuk kanë nevojë t’i përgjigjen.
4.6 Marrja e të dhënave mbrapsht nga njësia e saj burim
Nëse aplikimi dëshiron të modifikojë ose të fshijë të dhënat që janë marrë nga njësia, ai duhet të
përcaktojë nga të dhënat e marra se nga cila njësi kanë ardhur fillimisht në mënyrë që të trajtojë
me efikasitet ndryshimin. Shpesh është e mundur që thjesht t’i dërgohet çdo njësie një
komandë, ku njësia që nuk është përgjegjëse vetëm filtëron (me çelës) dhe injorojn kërkesën,
por kjo mund të jetë shumë e paefektshme, veçanërisht në qoftë se objektivi është në një njësi
të vetme. Një strukturë sharding për këtë arsye duhet të ofrojë një mjet që është në gjendje për
të ndjekur çdo pjesë të të dhënave mbrapsh në origjinën e saj njësi.
7
Ledia Hajdëri – Teknologjite e Cloud Computing
4.7 Lidhjet ndërmjet njësive
Në një aplikim “sharded”, kërkesat që përdorin lidhje për të përfshirë gjithë njësitë janë komplekse
dhe sfiduese për t’u kryer me efikasitet. Disa teknika kanë mundësi për të kryer lidhje të
shumfishta ndër-njësish, por me rritjen e numrit dhe elasticitetit të njësive, shpesh bëhet e vështirë
për aplikimin të ketë informacion se cilat njësi të përdorë ose ku ekzistojnë ato në çdo kohë të
dhënë për t'u përfshirë në një lidhje.
Shumë aplikacione që menaxhojnë vetë njësitë e tyre e adresojnë këtë duke shmangur lidhjet e
shumëfishta ndër-njësi dhe duke përshtatur disa teknika të tjera dizenjimi që në thelb menaxhojnë
hapësirë dhe kohë, pasi në një projekt elastik sharded hapërsira është burim i lirë dhe koha është
shumë e vlefshme. Tre teknikat më të zakonshme janë:
o
Denormalizimi
Denormalizimi ndihmon duke siguruar një mënyrë për të përcaktuar se cilat të dhëna nga
subjekte të ndryshme të lidhura shkrihen në një strukturë entitet të përbashkët ku të dhënat e
lidhura ruhen në të njëjtin rekord dhe kështu të njëjtën njësi.
o
Tabelat Referencë
Një shembull i përdorimit të tabelave referencë është rasti i tabelave ndihmëse (lookup)
relativisht statike që janë përdorur zakonisht kur t'u bashkuar me tabelat më të mëdha primare.
Tabelat që përmbajnë vlera të tilla si kodet e statusit, vendet, llojet, dhe produktet i përkasin
kësaj kategorie. Aplikimi për këtë arsye shkruan të dhënat referencë në të gjitha njësitë e
përshtatshme ose përdor një teknologji sinkronizimi për të replikuar këto tabela në të gjitha
njësitë.
o
Njësitë e grupuara që përdorin një çelës njësi dhe të dhëna të njësive atomike
Një aplikim që përdor këtë teknikë depoziton subjekte të lidhura në të njëjtën njësi. Kjo realizohet
nga projekti duke ditur marrëdhëniet e subjektit dhe duke përdorur një çelës të përbashkët njësi
në subjektet e lidhura për të siguruar që ato shkruhen për të njëjtën njësi. Kjo mundëson
përdorimin e lidhjeve ndërmjet këtyre subjekteve specifike duke qënë se ata janë në të njëjtën
njësi.
7 Dizenjimi i aplikimeve për Sharding me SQL Azure dhe ADO.NET
Le të paraqesim një nivel të lartë të projektimit për një librari sharding ADO.NET bazuar në
konceptet e përshkruara më sipër. Objektivat specifike të projektimit janë:
8
Ledia Hajdëri – Teknologjite e Cloud Computing

Librari bazuar në ADO.NET sharding që merret me shumë nga detajet e sharding

Sigurimi i përkrahjes për shumë lloje të ndryshme të strategjive për gjenerimin e njësive
dhe çelësave për njësi atomike dhe përcaktimin e cila njësi do të përdoret për të ruajtur
dhe për të tërhequr të dhënat

Trajtimi automatik i paralelizimit

Të veprojë mbi një model njësie/ atomik për të siguruar që të dhënat janë ruajtur në të
njëjtën njësi (shard)

Të sigurojë një bazë të shëndoshë për mbështetjen e karakteristikave sharding që do të
paraqiten në SQL Azure të cilat do të mundësojnë aplikime sharding të lehta për tu
migruar.
Projektimi i një Aplikimi të Madh në CC
Aplikimet e Mëdha në CC kanë objektiva të veçanta që favorizojnë shkallëzimin duke i mbajtur
punën dhe disponueshmërinë si parametra të rëndësishëm.
7.1 Arkitektura e Aplikimit
Le të shqyrtojmë një model tipik i cili ka tendencë të bëhet i vështirë me rritjen e bazës së
konsumatorëve. Ai është e bazuar në parimin se të gjitha të dhënat e konsumatorëve duhet të
ruhen në të njëjtën bazë të dhënash, të ndara logjikisht nga një kolonë çelës, të tilla si ID e
konsumatorëve. Ndarja logjike është quajtur domain i të dhënave, ose të dhënat e federatës.
Figura 4 tregon një bazë të dhënash të centralizuar për ruajtjen e të gjitha të dhënave te
konsumatorëve. Ndërsa ky model punon mirë, ai bëhet gjithnjë e më i vështirë për tabelat që kanë
një tendencë për të ruajtur shumë shënime. Performanca ulet me kalimin e kohës dhe pengesat
në transaksione bëhen më të shpeshta për shkak të njëkohëshmërisë së rritur.
Figura 4 - Ark itek turë me shk allëzim tradicional
9
Ledia Hajdëri – Teknologjite e Cloud Computing
Një model projektimi me shkallëzim te thjeshtë përfshin përdorimin e shumë bazave të të
dhënave, një për konsumator. Ky model është quajtur Arkitekturë Lineare njësish pasi çdo bazë
të dhënash është e pavarur nga të tjerët dhe çdo konsumator ka bazën e vet të të dhënave.
Avantazhi kryesor i këtij zbatimi qëndron në implementimin jo të përbashkët të arkitekturës duke
i lejuar çdo baze të dhënash për të marrë përparësinë e plotë të pajisjeve që i duhen, së bashku
me izolimin e plotë të sigurisë. Përveç kësaj, ky implementim nuk mbështetet në skema, që
thjeshtësojnë detyra të caktuara menaxheriale. Figura 5 tregon një shembull të një arkitekture
lineare.
Figura 5 - Ark itek turë njësish lineare
Një arkitekturë baze të dhënash me zgjerim të njësive është një tjetër dizajn i mundshëm. Në këtë
mënyrë, N konsumatorë janë ruajtur në një numër të bazave të të dhënave, në të cilën të dhënat
janë të shpërndara pothuajse në mënyrë të barabartë. Arkitektura me njësi të zgjeruara është një
modeli i shkallëzuar në të cilën databazat që përbëjnë një njësi nuk i caktohen një klienti të
veçantë (ose domaini). Aftësia për të gjetur të dhënat në këtë model varet nga filtrat e duhur në
dhënien e komandave drejt bazës së të dhënave.
Të dhënat janë shtuar në njësi duke përdorur një mekanizëm round-robin duke siguruar edhe
shpërndarjen e të dhënave në njësi. Gjithashtu, bërja e një kërkese ndaj njësisë kërkon qasjen e
një apo më shumë baza të dhënash në paralel dhe agregimin te rezultatit në shtresën e shërbimit
të internetit. Figura 6 tregon një shembull të këtij zbatimi.
10
Ledia Hajdëri – Teknologjite e Cloud Computing
Figura 6 - Një ark itek turë baza të dhënash me zgjerim të njësive
Është gjithashtu e mundur për të ndërtuar një dizajn që mikson arkitekturën lineare dhe atë të
zgjeruar, i referuar si një model shkallëzimi Hibrid i përshkruar në figurën 7. Grumbullimet e
njësive mund të përcaktohen për një grup klientësh.
Figura 7 – Modeli Hibrid
Së fundi, ka një rast të veçantë të quajtur Njësi (shard) të kompresuara, në të cilën numri i bazave
të të dhënave është më pak se numri i fushave të të dhënave, por më e madhe se një (përndryshe
kjo do të jetë një arkitekture e shkallëzuar si më lartë). Për të arritur këtë model, konsumatorë të
caktuar janë të grupuar në një bazë të dhënash të vetme, por të ndarë nga skema. Çdo skemë
paraqet një bazë të dhënash logjike në një bazë të dhënash të vetme dhe çdo skemë është
siguruar në një mënyrë që lejon klientët për të parë të dhënat e klientëve të tjerë.
11