Object storage — ma’lumotni katalog va bloklar o‘rniga object sifatida saqlaydigan storage arxitekturasidir. Har object payload, metadata va bucket doirasidagi noyob keydan iborat. Client odatda HTTP API orqali objectni to‘liq yozadi, o‘qiydi, nusxalaydi yoki o‘chiradi.
Ma’lumot modeli
Bucket objectlar uchun namespace va policy chegarasi vazifasini bajaradi. Object key ko‘pincha pathga o‘xshab images/2026/logo.png shaklida yoziladi, lekin ko‘p tizimlarda bu haqiqiy katalog emas, bitta tekis nomdir. UI slash belgisi asosida virtual papka ko‘rsatadi.
Metadata content type, checksum, cache policy va application atributlarini saqlashi mumkin. System metadata platforma tomonidan, user metadata client tomonidan beriladi. Katta metadata header chegarasi va listing xarajatiga ta’sir qiladi.
Operatsiyalar
Oddiy API PUT, GET, HEAD, DELETE va LIST amallarini beradi. HEAD payloadni yuklamasdan size, version va metadata olishga yordam beradi. Range request katta objectning faqat kerakli byte qismini o‘qiydi.
Katta fayl multipart upload bilan qismlarga bo‘linadi. Qismlar parallel yuborilib, yakunda bitta objectga birlashtiriladi. Tugallanmagan multipart upload storage egallashi mumkin; lifecycle policy uni ma’lum muddatdan keyin tozalaydi. Har qism va yakuniy object checksum bilan tekshiriladi.
Consistency va versiyalash
Consistency modeli platformaga bog‘liq. Zamonaviy xizmatlar ko‘pincha yangi object, overwrite va delete uchun kuchli consistency beradi, ammo external cache yoki cross-region replication kechikishi alohida qoladi. Application aynan ishlatilayotgan xizmat kafolatiga tayanadi.
Versioning bir keyning oldingi nusxalarini saqlaydi. Delete marker objectni oddiy listingdan yashirishi, eski versiyalar esa saqlanishda davom etishi mumkin. Bu tasodifiy o‘chirishdan qaytishga yordam beradi, lekin retention va xarajatni oshiradi.
Masshtab va performance
Object storage juda ko‘p object va katta hajmga horizontal masshtablanadi. U kichik random block update uchun mo‘ljallanmagan; objectning bir qismini o‘zgartirish ko‘pincha yangi object yozishni talab qiladi. Database fayli yoki VM diskini bevosita object API ustida ishlatish mos semantika bermaydi.
Throughput object hajmi, parallelism, network va request ratega bog‘liq. Ko‘p juda kichik objectda payloadga nisbatan request hamda metadata xarajati katta bo‘ladi. Bir katta archive esa individual elementni olishni qiyinlashtiradi. Packaging access pattern asosida tanlanadi.
Storage class va lifecycle
Hot class tez-tez o‘qiladigan data uchun, infrequent yoki archive class esa arzonroq storage evaziga retrieval va minimal saqlash muddati cheklovlarini beradi. Lifecycle policy yosh, prefix yoki tag bo‘yicha objectni boshqa classga ko‘chiradi va muddati tugaganda o‘chiradi.
Transition darhol iqtisod bermasligi mumkin: retrieval fee, early deletion va restore vaqti ham hisoblanadi. Compliance retention objectni belgilangan muddat o‘chirishdan himoya qilishi mumkin. Legal hold lifecycle delete’dan ustun kelishi mumkin.
Xavfsizlik va durability
Bucket public access default holatda yopiq bo‘lishi kerak. Identity policy, bucket policy, object ACL va signed URL bir-biri bilan kesishadi; effective permission tahlili zarur. Server-side yoki client-side encryption ma’lumotni himoya qiladi, key management esa alohida lifecycle talab qiladi.
Durability ko‘p failure domainlarda nusxa yoki erasure coding bilan ta’minlanadi. U availability yoki backupni aynan anglatmaydi. Region xatosi, credential orqali zararli delete va application corruption uchun replication, versioning hamda mustaqil backup siyosati kerak.
Bog‘liq tushunchalar
Bucket, Object key, Multipart upload, Storage class, Lifecycle policy, Versioning, Signed URL