Ekipi i depozitës S3 shkroi një artikull mbi kriteret e rëndësishme për zgjedhjen e depozitës objektive. Më poshtë është teksti nga autori.
Kur bĂ«het fjalĂ« pĂ«r depozitĂ«n objektive, zakonisht, njerĂ«zit mendojnĂ« vetĂ«m pĂ«r njĂ« karakteristikĂ« â çmimin pĂ«r TB/GB. Sigurisht, ky metrik Ă«shtĂ« i rĂ«ndĂ«sishĂ«m, por ai e bĂ«n qasjen njĂ«anshĂ«m dhe e barazon depozitĂ«n objektive me njĂ« mjet pĂ«r ruajtjen e arkivave. PĂ«r mĂ« tepĂ«r, kĂ«to qasje zvogĂ«lojnĂ« rĂ«ndĂ«sinĂ« e depozitĂ«s objektive pĂ«r stakun teknologjik tĂ« ndĂ«rmarrjes.
Kur zgjidhni një depozitë objektive, vlen të kushtoni vëmendje ndaj pesë karakteristikave:
- performanca;
- shkallëzueshmëria;
- kompatibiliteti me S3;
- reaksioni ndaj defekteve;
- integriteti.
Këto pesë karakteristika janë metrika të reja për depozitën objektive, përveç kostos. Le ta shqyrtojmë të gjitha ato.
Performanca
Depozitat tradicionale objektive nuk dallohet për performancë. Ofruesit e shërbimeve vazhdimisht e sakrifikuan atë në ndjekjen e çmimeve të ulëta. Megjithatë, me depozitat moderne objektive, gjithçka është ndryshe.
ShpejtĂ«sitĂ« e depozitave tĂ« ndryshme po afrohen me Hadoop ose madje e tejkalojnĂ« atĂ«. KĂ«rkesat moderne pĂ«r shpejtĂ«sinĂ« e leximit dhe shkrimit janĂ« nga 10 GB/s pĂ«r disqet e forta, deri nĂ« 35 GB/s pĂ«r NVMe.Â
Kjo kapacitet është mjaftueshëm për Spark, Presto, Tensorflow, Teradata, Vertica, Splunk dhe frameworket moderne tël logjistikës në ekosistem. Fakti që bazat e të dhënave MPP janë duke u konfigurur për objekte depozitash tregon se ato po përdoren gjithnjë e më shumë si depoja kryesore.
Nëse sistemi juaj i ruajtjes nuk siguron shpejtësinë e nevojshme, nuk mund të përdorni të dhënat dhe të nxirrni vlere prej tyre. Edhe nëse nxirrni të dhënat nga depozita e objekteve në një strukturë përpunimi në memorie, ende do të nevojitet kapacitet për të transferuar të dhënat në memorie dhe jashtë saj. Depozitat e objekteve të vjetra nuk e sigurojnë këtë.
Kjo është çështja kryesore: treguesi i ri i performancës është kapaciteti, jo vonesa. Ai është thelbësor për të dhënat e shkallëzueshme, dhe kjo është norma në infrastrukturën moderne të të dhënave.
Edhe pse testet e performancës janë një mënyrë e mirë për të përcaktuar performancën, ajo nuk mund të matet saktësisht para se të fillojë aplikacioni në mjedisin real. Vetëm pas kësaj mund të thuhet se ku ndodhet pikë-ngushtimi: në softuer, disqe, rrjet ose në nivelin e llogaritjes.
Shkallëzueshmëria
Skalueshmëria nënkupton numrin e petabajtëve që mund të vendosen në një hapësirë emërtimi. Oferuesit deklarojnë për skalueshmëri të lehtë, por nuk përmendin se ndërsa sistemi zgjerohet, sistemet masive monolite bëhen të brishta, komplekse, të paqëndrueshme dhe të shtrenjta.
Të dhënat e reja të skalueshmërisë janë numri i hapësirave të emërtimit ose klientëve që mund të mbuloni. Kjo metrikë merret drejtpërdrejt nga hiperskaluesit, ku blloqet ndihmëse të ruajtjes janë të vogla, por skalohen deri në miliarda njësive. Në përgjithësi, kjo është një metrikë e re për cloud.
Kur blloket standard kanë madhësi të vogla, është më e lehtë t'i optimizoni, domethënë të siguroni sigurinë, kontrollin e akseseve, menaxhimin e politikave, ciklit të jetës dhe përditësimeve pa ndërprerje të shërbimit. Dhe në fund të fundit, të sigurohet performanca. Madhësia e bllokut ndërtues është një funksion i menaxhueshmërisë së zonës së dështimit, kështu ndërtohen sistemet me qëndrueshmëri të lartë.
Multikonsolimi ka shumë karakteristika. Megjithëse parametri flet për mënyrën se si organizatat ofrojnë akses në të dhëna dhe aplikacione, ai gjithashtu i referohet aplikacioneve të vetë dhe logjikës së izolimit të tyre nga njëra-tjetra.
Karakteristikat e qasjes moderne ndaj multikonsolimit:
- Në një kohë të shkurtër numri i klientëve mund të rritet nga disa qindra në disa milion.
- Klientët janë plotësisht të izoluar nga njëri-tjetri. Kjo u lejon atyre të ekzekutojnë versione të ndryshme të të njëjtit softuer dhe të ruajnë objekte me konfigurime, leje, funksione, nivele sigurie dhe mirëmbajtjeje të ndryshme. Kjo është e nevojshme kur ndodhin zgjerime të serverëve të rinj, përditësimeve dhe rajoneve gjeografike.
- Depozita është elastikisht e shkallëzueshme, burimet ofrohen me kërkesë.
- Ădo operacion menaxhohet nga API dhe automatizohet pa pĂ«rfshirjen e njeriut.
- Softueri mund të vendoset në kontejnerë dhe të përdorë sisteme standarde orkestrimi, si Kubernetes.
Kompatibiliteti me S3
Amazon S3 API Ă«shtĂ« nĂ« tĂ« vĂ«rtetĂ« standardi pĂ«r depozitat objekt. Ădo ofrues softueri pĂ«r depozita objekt pretendon se Ă«shtĂ« i kompatibilitetshĂ«m me tĂ«. Kompatibiliteti me S3 Ă«shtĂ« binar: ose Ă«shtĂ« realizuar plotĂ«sisht, ose nuk Ă«shtĂ«.
Në praktikë, mund të ndodhin qindra dhe mijëra skenarë të kufirit kur përdoret një depozitë objekt dhe diçka shkon keq. Kjo është veçanërisht e vërtetë për ofruesit e softuerëve dhe shërbimeve pronësore. Skenarët e saj kryesorë të përdorimit janë arkivimi direkt ose kopjimi rezervë, prandaj arsyet për thirrjen e API-së janë të pakta, dhe opsionet e përdorimit janë homogjene.
Softueri me burim të hapur ka përparësi të konsiderueshme. Ai mbulon shumicën e skenarëve të kufirit, duke marrë parasysh madhësinë dhe diversitetin e aplikacioneve, sistemeve operative dhe arkitekturave të harduerit.
KĂ«to janĂ« tĂ« rĂ«ndĂ«sishme pĂ«r zhvilluesit e aplikacioneve, pĂ«r kĂ«tĂ« arsye Ă«shtĂ« e rekomandueshme tĂ« testoni funksionimin e aplikacionit me ofruesit e ruajtjes. Kodi i hapur e lehtĂ«son procesin â Ă«shtĂ« mĂ« e thjeshtĂ« tĂ« kuptoni se cila platformĂ« i pĂ«rshtatet aplikacionit tuaj. Ofruesi mund tĂ« pĂ«rdoret si njĂ« pikĂ« e vetme hyrĂ«se nĂ« ruajtje â do tĂ« thotĂ«, ai do tĂ« kĂ«naqĂ« nevojat tuaja.Â
Kodi i hapur do të thotë: aplikacionet nuk janë të lidhura me ofruesin dhe janë më të drejtpërdrejta. Kjo siguron një cikël të gjatë jetësor për aplikacionin.
Dhe disa vĂ«rejtje rreth kodit tĂ« hapur dhe S3.Â
Nëse po lançoni një aplikacion për të punuar me të dhëna të mëdha, S3 SELECT e rrit dukshëm performancën dhe efikasitetin. Kjo ndodh përmes përdorimit të SQL për të ekstraktuar nga ruajtja vetëm objektet që ju nevojiten.
NjĂ« pikĂ« kyçe Ă«shtĂ« mbĂ«shtetje pĂ«r njoftimet e kovĂ«ve. Njoftimet e kovĂ«ve e lehtĂ«sojnĂ« pĂ«rpunimin pa server â njĂ« komponent i rĂ«ndĂ«sishĂ«m i çdo arkitekture mikroshĂ«rbimesh qĂ« ofrohet si njĂ« shĂ«rbim. Duke pasur parasysh se ruajtja e objekteve Ă«shtĂ« nĂ« thelb ruajtje nĂ« re, kjo mundĂ«si bĂ«het vendimtare kur ruajtja e objekteve pĂ«rdoret nga aplikacionet nĂ« re.
NĂ« fund, implementimi i S3 duhet tĂ« mbĂ«shtesĂ« ndĂ«rfaqet e API-sĂ« pĂ«r enkriptimin nĂ« anĂ«n e shĂ«rbimit: SSE-C, SSE-S3, SSE-KMS. Edhe mĂ« mirĂ«, nĂ«se S3 mbĂ«shtet njĂ« sistem mbrojtjeje nga akses tĂ« paautorizuar qĂ« Ă«shtĂ« me tĂ« vĂ«rtetĂ« i sigurt.Â
Reagimi ndaj dështimeve
Një tregues që ndoshta shpesh kalon pa u vënë re është se si sistemi menaxhon dështimet. Dështimet ndodhin për arsye të ndryshme dhe ruajtja e objekteve duhet t'i menaxhojë të gjitha.
Për shembull, ekziston një pikë e vetme dështimi, metrika e së cilës është zero.
FatkeqĂ«sisht, shumĂ« sisteme ruajtjeje objekte pĂ«rdorin nyje speciale, tĂ« cilat duhet tĂ« aktivizohen pĂ«r funksionimin e duhur tĂ« grumbullit. KĂ«to pĂ«rfshijnĂ« nyjet e emrit ose serverĂ«t e tĂ« dhĂ«nave tĂ« metadave â kjo krijon njĂ« pikĂ« tĂ« vetme dĂ«shtimi.
Edhe nĂ«se parashikohen disa pika dĂ«shtimi, aftĂ«sia pĂ«r tĂ« pĂ«rballuar dĂ«shtime katastrofike Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme. Disqet dĂ«shtojnĂ«, serverat dĂ«shtojnĂ«. ĂelĂ«si Ă«shtĂ« krijimi i njĂ« programi qĂ« Ă«shtĂ« i dizajnuar pĂ«r tĂ« trajtuar dĂ«shtimet si njĂ« gjendje normale. Kur njĂ« disk ose nyje dĂ«shtojnĂ«, njĂ« software i tillĂ« do tĂ« vazhdojĂ« tĂ« punojĂ« pa ndryshime.
Mbrojtja e ndĂ«rtuar ndaj fshirjes dhe degradimit tĂ« tĂ« dhĂ«nave garanton: mund tĂ« humbni aq disqe ose nyje sa kanĂ« blloqe pariteti â zakonisht kjo Ă«shtĂ« gjysma e disqeve. VetĂ«m atĂ«herĂ« software-i nuk do tĂ« jetĂ« nĂ« gjendje tĂ« rikthejĂ« tĂ« dhĂ«nat.
Dështimi rrallë kontrollohet nën ngarkesë, por një kontroll i tillë është i domosdoshëm. Modellimi i dështimit nën ngarkesë do të tregojë kostot totale që lidhen me dështimin.
Konsistenca
Të dhënat 100% të konsistencës gjithashtu quhen konsistencë strikte. Konsistenca është një komponent thelbësor i çdo sistemi ruajtjeje, por konsistenca strikte është mjaft e rrallë. Për shembull, Amazon S3 ListObject nuk është me konsistencë strikte, ai është vetëm konsistent në fund.
ĂfarĂ« nĂ«nkupton konsistenca e fortĂ«? PĂ«r tĂ« gjitha operacionet pas njĂ« operacioni tĂ« konfirmuar PUT duhet tĂ« ekzekutohet gjithçka e mĂ«poshtme:
- Vlera e azhurnuar është e dukshme kur lexoni nga çdo nyje.
- Azhurnimi është i mbrojtur nga rezervimi i dështimit të nyjës.
Kjo do të thotë: nëse hiqni kabllon në mes të shkrimit, nuk do të humbasë asgjë. Sistemi kurrë nuk kthehet në të dhëna të dëmtuara apo të vjetra. Kjo është një normë e lartë, e cila ka rëndësi për shumë skenarë: nga aplikacionet transaksionale deri te kopjimi dhe rikuperimi.
PĂ«rfundimi
KĂ«to janĂ« metrika tĂ« reja tĂ« magazinimit tĂ« objekteve, tĂ« cilat pasqyrojnĂ« modelet e pĂ«rdorimit nĂ« organizatat moderne, ku performanca, konsistenca, shkallĂ«zueshmĂ«ria, domainet e dĂ«shtimit dhe pajtueshmĂ«ria me S3 janĂ« blloqe ndĂ«rtimi pĂ«r aplikacionet nĂ« cloud dhe analitikĂ«n e tĂ« dhĂ«nave tĂ« mĂ«dha. Rekomandoj qĂ« tĂ« pĂ«rdorni kĂ«tĂ« listĂ« pĂ«rveç çmimit teksa krijoni stekat e tĂ« dhĂ«nave moderne.Â
PĂ«r magazinimin e objekteve Mail.ru Cloud Solutions: .
ĂfarĂ« tjetĂ«r mund tĂ« lexoni:
- .
- .
- .Â
Burimi: habr.com
