S3 Objekta Stokado-Teamo tradukis artikolon pri kiaj kriterioj gravas dum elektado de objektostokejo. Plia teksto nome de la aŭtoro.
Kiam temas pri objekta stokado, homoj emas pensi nur pri unu metriko: kosto por TB/GB. Kvankam ĉi tiu metriko estas grava, ĝi ankaŭ igas la aliron unupartia kaj egaligas objektan stokadon al arkiva stokada ilo. Plie, ĉi tiu aliro reduktas la gravecon de objekta stokado por entreprena teknologia stako.
Kiam oni elektas objektostokadon, estas kvin karakterizaĵoj konsiderindaj:
- agado;
- skaleblo;
- S3 kongrua;
- respondo al fiaskoj;
- integreco.
Ĉi tiuj kvin karakterizaĵoj estas la novaj metrikoj de objekta stokado, kune kun kosto. Ni rigardu ilin ĉiujn.
Produkteco
Tradicia objekta stokado ne estas konata pro sia efikeco. Servoprovizantoj ĉiam oferis ĝin serĉante malaltajn prezojn. Tamen, kun moderna objekta stokado, aferoj estas malsamaj.
La rapido de diversaj stokadoprocezoj alproksimiĝas al aŭ eĉ superas Hadoop. Modernaj postuloj por legaj kaj skribaj rapidoj: de 10 GB/s por diskoj ĝis 35 GB/s por NVMe.
Ĉi tiu trairo sufiĉas por Spark, Presto, Tensorflow, Teradata, Vertica, Splunk kaj aliaj modernaj komputilaj kadroj en la analiza stako. La fakto, ke MPP-datumbazoj estas agorditaj por objektostokado, indikas, ke ĝi estas pli kaj pli uzata kiel la ĉefa stokado.
Se via stokadosistemo ne estas sufiĉe rapida, vi ne povas uzi la datumojn kaj ĉerpi valoron el ili. Eĉ se vi ĉerpas datumojn el objekta stokado al memora prilaborstrukturo, vi ankoraŭ bezonas bendlarĝon por translokigi la datumojn en kaj el la memoro. Hereditaj objektaj stokadsistemoj ne havas sufiĉe da ĝi.
Jen la ŝlosila punkto: la nova rendimenta metriko estas trairo, ne latenteco. Ĝi estas necesa por skaleblaj datumoj, kaj ĝi estas la normo en moderna datum-infrastrukturo.
Kaj kvankam komparnormoj estas bona maniero por determini rendimenton, estas neeble precize mezuri ĝin ĝis la aplikaĵo funkcias en la medio. Nur tiam vi povas scii ĉu la proplempunkto estas en la programaro, diskoj, reto aŭ komputado.
Skalebleco
Skalebleco estas difinita kiel la nombro da petabajtoj, kiuj taŭgas en unuopan nomspacon. Vendistoj asertas facilan skaleblon, sed kion ili ne diras al vi estas, ke dum vi skaliĝas, masivaj monolitaj sistemoj fariĝas delikataj, kompleksaj, malstabilaj kaj multekostaj.
La nova metriko pri skalebleco estas la nombro da nomspacoj aŭ luantoj, kiujn vi povas servi. La metriko estas prenita rekte de hiperskaliloj, kie la konstrubriketoj de stokado estas malgrandaj sed skaleblas al miliardoj da unuoj. Esence, ĝi estas nuba metriko.
Kiam la konstrubriketoj estas malgrandaj, ili estas pli facile optimumigeblaj, t.e., ili provizas sekurecon, alirkontrolon, strategiadministradon, vivciklan administradon kaj neinterrompajn ĝisdatigojn. Kaj finfine, rendimenton. La grandeco de la konstrubriketo estas funkcio de la administrebleco de la paneodomajno, kaj tiel oni konstruas tre rezistemajn sistemojn.
Plurluado havas multajn karakterizaĵojn. Dum la parametro rilatas al kiel organizoj provizas aliron al datumoj kaj aplikaĵoj, ĝi ankaŭ rilatas al la aplikaĵoj mem kaj la logiko de izolado de ili unu de la alia.
Karakterizaĵoj de la moderna aliro al multklienta administrado:
- En mallonga tempo, la nombro de klientoj povas kreski de kelkaj centoj ĝis pluraj milionoj.
- Klientoj estas tute izolitaj unu de la alia. Tio permesas al ili ruligi malsamajn versiojn de la sama programaro kaj konservi objektojn kun malsamaj agordoj, permesoj, funkcioj, sekurecniveloj kaj servoniveloj. Tio necesas dum skalado de novaj serviloj, ĝisdatigoj kaj geografioj.
- La stokado estas elaste skalebla, resursoj estas provizitaj laŭpete.
- Ĉiu operacio estas API-regata kaj aŭtomatigita sen homa interveno.
- La programaro povas esti metita en ujojn kaj uzi normajn orkestradsistemojn kiel Kubernetes.
Kongrueco kun S3
La Amazon S3 API estas la fakta normo por objektostokado. Ĉiu vendisto de objektstokada programaro asertas kongruecon kun ĝi. La kongrueco kun S3 estas binara: aŭ ĝi estas plene efektivigita, aŭ ĝi ne estas.
En praktiko, ekzistas centoj aŭ miloj da randaj kazoj kie io misfunkcias dum uzado de objekta stokado. Precipe por proprieta programaro kaj servoprovizantoj. Ĝiaj ĉefaj uzkazoj estas rekta arkivado aŭ sekurkopio, do estas malmultaj kialoj por voki la API-on, la uzkazoj estas homogenaj.
Malfermitkoda programaro havas signifajn avantaĝojn. Ĝi kovras plej multajn randajn scenarojn, konsiderante la grandecon kaj diversecon de aplikaĵoj, operaciumoj kaj aparataraj arkitekturoj.
Ĉio ĉi gravas por programistoj de programoj, do valoras testi la rendimenton de via programo kun provizantoj de stokado. Malfermitkoda kodo simpligas la procezon — estas pli facile kompreni, kiu platformo taŭgas por via programo. La provizanto povas esti uzata kiel ununura enirejo al stokado, kio signifas, ke ĝi plenumos viajn bezonojn.
Malfermitkoda signifas: aplikaĵoj ne estas ligitaj al vendisto kaj estas pli travideblaj. Tio certigas longan vivciklon de la aplikaĵo.
Kelkaj pliaj notoj pri malfermitkoda programaro kaj S3.
Se vi uzas aplikon por grandaj datumoj, S3 SELECT plibonigas rendimenton kaj efikecon je grandordo per uzado de SQL por preni nur la objektojn, kiujn vi bezonas el la stokado.
La ŝlosilo estas subteno por sitelaj sciigoj. Sitelaj sciigoj faciligas servilan komputadon, gravan komponenton de iu ajn mikroserva arkitekturo, kiu estas liverita kiel servo. Ĉar objekta stokado estas efike nuba stokado, ĉi tiu kapablo fariĝas kritika kiam nubaj aplikaĵoj uzas objektan stokadon.
Fine, la efektivigo de S3 devus subteni la servilajn ĉifradajn APIojn de Amazon S3: SSE-C, SSE-S3, SSE-KMS. Eĉ pli bone, S3 devus subteni protekton kontraŭ manipulado, kiu estas vere sekura.
Reago al fiaskoj
Metriko, kiu verŝajne ofte estas preteratentata, estas kiel la sistemo traktas paneojn. Paneoj okazas pro diversaj kialoj, kaj objekta stokado devas pritrakti ilin ĉiujn.
Ekzemple, se ekzistas ununura punkto de fiasko, la metriko por tio estas nulo.
Bedaŭrinde, multaj objektaj stokadsistemoj uzas specialajn nodojn, kiuj devas esti ebligitaj por ke la areto funkciu ĝuste, kiel ekzemple nomnodoj aŭ metadatenaj serviloj, kio kreas ununuran punkton de fiasko.
Eĉ kie oni celas plurajn punktojn de paneo, la kapablo elteni katastrofajn paneojn estas plej grava. Diskoj paneas, serviloj paneas. La ŝlosilo estas konstrui programaron desegnitan por trakti paneojn kiel normalan staton. Se disko aŭ nodo paneas, la programaro daŭre funkcios sen modifo.
Enkonstruita protekto kontraŭ forviŝado kaj datuma degenero certigas, ke vi povas perdi tiom da diskoj aŭ nodoj kiom vi havas egalecajn blokojn - kutime duonon de la diskoj - kaj nur tiam la programaro ne povos reakiri la datumojn.
Fiasko malofte estas testata sub ŝarĝo, sed ĝi estas nepra. Simulado de fiasko sub ŝarĝo montros la akumulajn kostojn altiritajn post la fiasko.
Konsekvenco
Konsekvenca poentaro de 100% ankaŭ nomiĝas strikta konsistenco. Konsekvenco estas ŝlosila komponanto de iu ajn stokada sistemo, sed strikta konsistenco estas sufiĉe malofta. Ekzemple, Amazon S3 ListObject ne estas strikte kohera, ĝi estas kohera nur ĉe la fino.
Kion signifas strikta konsistenco? Por ĉiuj operacioj post konfirmita PUT-operacio, la jena devas esti vera:
- La ĝisdatigita valoro estas videbla dum legado de iu ajn nodo.
- La ĝisdatigo estas protektita kontraŭ nodfiasko per redundo.
Tio signifas, ke se vi ĉesigas skribadon meze de ĝi, nenio perdiĝas. La sistemo neniam redonas koruptitajn aŭ malaktualiĝintajn datumojn. Ĉi tio estas alta normo, kiu gravas por multaj scenaroj, de transakciaj aplikaĵoj ĝis sekurkopioj kaj reakiroj.
konkludo
Jen novaj metrikoj pri objekta stokado, kiuj reflektas uzpadronojn en modernaj organizoj, kie rendimento, konsistenco, skalebleco, erardomajnoj kaj S3-kongruo estas la konstrubriketoj de nubaj aplikaĵoj kaj granddatuma analitiko. Mi rekomendas uzi ĉi tiun liston aldone al prezo dum konstruado de modernaj datumaj stakoj.
Pri la objekta stokado de Mail.ru Cloud Solutions: .
Kion alian legi:
- .
- .
- .
fonto: www.habr.com
