printah panyimpenan obyek S3 nerjemahake artikel babagan kritΓ©ria apa sing penting nalika milih panyimpenan obyek. Ing ngisor iki minangka teks saka sudut pandang penulis.
Nalika nerangake panyimpenan obyek, wong biasane mung mikir babagan siji: rega saben TB / GB. Mesthine, metrik iki penting, nanging ndadekake pendekatan siji-sisi lan padha karo panyimpenan obyek karo alat panyimpenan arsip. Kajaba iku, pendekatan iki nyuda pentinge panyimpenan obyek kanggo tumpukan teknologi perusahaan.
Nalika milih panyimpenan obyek, sampeyan kudu menehi perhatian marang limang ciri:
- kinerja;
- skalabilitas;
- S3 kompatibel;
- nanggepi kegagalan;
- integritas.
Lima karakteristik iki minangka metrik anyar kanggo panyimpenan obyek, bebarengan karo biaya. Ayo padha ndeleng kabeh.
Produktivitas
Toko obyek tradisional kurang kinerja. Panyedhiya layanan terus-terusan ngorbanake kanggo nggayuh rega sing murah. Nanging, karo panyimpenan obyek modern iku beda.
Macem-macem sistem panyimpenan nyedhaki utawa malah ngluwihi kacepetan Hadoop. Syarat modern kanggo kacepetan maca lan nulis: saka 10 GB / s kanggo hard drive, nganti 35 GB / s kanggo NVMe.
Throughput iki cukup kanggo Spark, Presto, Tensorflow, Teradata, Vertica, Splunk lan kerangka komputasi modern liyane ing tumpukan analytics. Kasunyatan yen basis data MPP dikonfigurasi kanggo panyimpenan obyek nuduhake yen lagi digunakake minangka panyimpenan utama.
Yen sistem panyimpenan ora nyedhiyakake kacepetan sing dibutuhake, sampeyan ora bisa nggunakake data kasebut lan ngekstrak nilai kasebut. Sanajan sampeyan njupuk data saka panyimpenan obyek menyang struktur pangolahan ing memori, sampeyan isih butuh bandwidth kanggo mindhah data menyang lan saka memori. Toko obyek warisan ora cukup.
Iki minangka titik utama: metrik kinerja anyar yaiku throughput, dudu latensi. Dibutuhake kanggo data kanthi skala lan minangka norma ing infrastruktur data modern.
Nalika benchmark minangka cara sing apik kanggo nemtokake kinerja, ora bisa diukur kanthi akurat sadurunge mbukak aplikasi ing lingkungan. Mung sawise sampeyan bisa ngomong ing ngendi persis bottleneck: ing piranti lunak, disk, jaringan utawa ing tingkat komputasi.
Skalabilitas
Skalabilitas nuduhake jumlah petabyte sing cocog karo siji ruang jeneng. Apa sing diklaim vendor minangka skalabilitas sing gampang, sing ora dikandhakake yaiku nalika ukurane, sistem monolitik massive dadi rapuh, rumit, ora stabil, lan larang.
Metrik anyar kanggo skalabilitas yaiku jumlah ruang jeneng utawa klien sing bisa dilayani. Metrik kasebut dijupuk langsung saka hyperscalers, ing ngendi blok bangunan panyimpenan cilik nanging ukurane nganti milyaran unit. UmumΓ©, iki minangka metrik awan.
Nalika blok bangunan cilik, luwih gampang dioptimalake kanggo keamanan, kontrol akses, manajemen kebijakan, manajemen siklus urip, lan nganyari sing ora ngganggu. Lan pungkasane njamin produktivitas. Ukuran blok bangunan minangka fungsi saka kontrol wilayah kegagalan, yaiku carane sistem sing tahan banget dibangun.
Multi-tenancy nduweni akeh ciri. Nalika dimensi ngomong babagan carane organisasi nyedhiyakake akses menyang data lan aplikasi, uga nuduhake aplikasi kasebut dhewe lan logika sing diisolasi saka siji liyane.
Karakteristik pendekatan modern kanggo multi-klien:
- Ing wektu sing cendhak, jumlah klien bisa tuwuh saka pirang-pirang atus nganti pirang-pirang yuta.
- Klien rampung diisolasi saka saben liyane. Iki ngidini kanggo mbukak macem-macem versi piranti lunak sing padha lan nyimpen obyek kanthi konfigurasi, ijin, fitur, keamanan lan tingkat pangopènan sing beda. Iki perlu nalika nggawe skala menyang server anyar, nganyari, lan geografi.
- Panyimpenan bisa diukur kanthi elastis, sumber daya kasedhiya yen dikarepake.
- Saben operasi dikontrol dening API lan otomatis tanpa campur tangan manungsa.
- Piranti lunak bisa di-host ing wadhah lan nggunakake sistem orkestrasi standar kayata Kubernetes.
S3 kompatibel
Amazon S3 API minangka standar de facto kanggo panyimpenan obyek. Saben vendor piranti lunak panyimpenan obyek nyatakake kompatibilitas karo. Kompatibilitas karo S3 yaiku binar: bisa ditindakake kanthi lengkap utawa ora.
Ing laku, ana atusan utawa ewu skenario pinggiran sing ana masalah nalika nggunakake panyimpenan obyek. Utamane saka panyedhiya piranti lunak lan layanan kepemilikan. Kasus panggunaan utamane yaiku pengarsipan utawa serep langsung, mula ana sawetara alasan kanggo nelpon API, kasus panggunaan homogen.
Piranti lunak open source nduweni kaluwihan sing signifikan. Iki kalebu paling akeh skenario pinggiran, amarga ukuran lan macem-macem aplikasi, sistem operasi, lan arsitektur hardware.
Kabeh iki penting kanggo pangembang aplikasi, mula kudu nyoba aplikasi kasebut karo panyedhiya panyimpenan. Open source nggampangake proses - luwih gampang ngerti platform endi sing cocog kanggo aplikasi sampeyan. Panyedhiya bisa digunakake minangka siji titik mlebu menyang panyimpenan, tegese bakal nyukupi kabutuhan sampeyan.
Open source tegese: aplikasi ora disambungake menyang vendor lan luwih transparan. Iki njamin siklus urip aplikasi sing dawa.
Lan sawetara cathetan liyane babagan open source lan S3.
Yen sampeyan nggunakake aplikasi data gedhe, S3 SELECT nambah kinerja lan efisiensi kanthi urutan gedhene. Iki ditindakake kanthi nggunakake SQL kanggo njupuk mung obyek sing dibutuhake saka panyimpenan.
Intine yaiku dhukungan kanggo kabar ember. Kabar bucket nggampangake komputasi tanpa server, komponen penting saka arsitektur microservice sing dikirim minangka layanan. Amarga panyimpenan obyek minangka panyimpenan maya kanthi efektif, kemampuan iki dadi kritis nalika panyimpenan obyek digunakake dening aplikasi berbasis awan.
Pungkasan, implementasi S3 kudu ndhukung API enkripsi sisih server Amazon S3: SSE-C, SSE-S3, SSE-KMS. Luwih apik, S3 ndhukung proteksi tamper sing pancen aman.
Tanggapan kanggo kegagalan
Metrik sing bisa uga asring diabaikan yaiku kepiye sistem nangani kegagalan. Gagal kedadeyan amarga macem-macem alasan, lan panyimpenan obyek kudu ditangani kabeh.
Contone, ana siji titik kegagalan, metrik iki nol.
Sayange, akeh sistem panyimpenan obyek nggunakake simpul khusus sing kudu diaktifake supaya kluster bisa dienggo kanthi bener. Iki kalebu simpul jeneng utawa server metadata - iki nggawe siji titik kegagalan.
Sanajan ana pirang-pirang titik kegagalan, kemampuan kanggo nahan kegagalan bencana iku paling penting. Disk gagal, server gagal. Kuncine yaiku nggawe piranti lunak sing dirancang kanggo ngatasi kegagalan minangka kondisi normal. Yen disk utawa simpul gagal, piranti lunak kasebut bakal terus bisa digunakake tanpa owah-owahan.
Perlindhungan sing dibangun saka penghapusan data lan degradasi data mesthekake yen sampeyan bisa kelangan akeh disk utawa simpul amarga sampeyan duwe blok paritas-biasane setengah disk. Mung banjur piranti lunak ora bisa ngasilake data.
Gagal kasebut jarang dites ing beban, nanging tes kasebut dibutuhake. Simulasi kegagalan beban bakal nuduhake total biaya sing ditindakake sawise kegagalan.
Konsistensi
Skor konsistensi 100% uga diarani konsistensi ketat. Konsistensi minangka komponen utama saka sistem panyimpenan, nanging konsistensi sing kuat arang banget. Contone, Amazon S3 ListObject ora konsisten, mung konsisten ing pungkasan.
Apa tegese konsistensi sing ketat? Kanggo kabeh operasi sawise operasi PUT dikonfirmasi, ing ngisor iki kudu kelakon:
- Nilai sing dianyari katon nalika maca saka simpul apa wae.
- Nganyari dilindhungi saka redundansi kegagalan simpul.
Iki tegese yen sampeyan narik plug ing tengah rekaman, ora bakal ilang. Sistem kasebut ora nate ngasilake data sing rusak utawa ketinggalan jaman. Iki minangka bar dhuwur sing penting ing akeh skenario, saka aplikasi transaksi nganti serep lan pemulihan.
kesimpulan
Iki minangka metrik panyimpenan obyek anyar sing nggambarake pola panggunaan ing organisasi saiki, ing ngendi kinerja, konsistensi, skalabilitas, domain kesalahan lan kompatibilitas S3 minangka blok bangunan kanggo aplikasi awan lan analytics data gedhe. Aku nyaranake nggunakake dhaptar iki saliyane rega nalika mbangun tumpukan data modern.
Babagan panyimpenan obyek Mail.ru Cloud Solutions: .
Apa maneh sing kudu diwaca:
- .
- .
- .
Source: www.habr.com