Object key — object storage bucketi ichida objectni aniqlovchi nom yoki identifikatordir. Bucket nomi va key birgalikda object manzilini hosil qiladi. Key payload mazmuni emas; API GET, PUT, DELETE va listing amallarida qaysi object ustida ishlashni belgilaydi.
Namespace va virtual papka
Ko‘p object storagelarda key UTF-8 matn bo‘lib, slash belgisini o‘z ichiga olishi mumkin. users/42/avatar.png ko‘rinishi katalogga o‘xshaydi, ammo storage ichida haqiqiy users katalogi bo‘lmasligi mumkin. Prefix listing va delimiter UIga virtual ierarxiya yaratadi.
Bir bucketda aynan bir xil key bitta current objectga ishora qiladi. Versioning yoqilgan bo‘lsa bir key ostida bir nechta version ID mavjud bo‘ladi. Version ID ko‘rsatilmagan GET current versiyani qaytaradi.
Key loyihalash
Key application access patterniga mos bo‘lishi kerak. Tenant ID, sana yoki object turi prefixda bo‘lsa listing va lifecycle qoidasi osonlashadi. Biroq keyga foydalanuvchi emaili yoki maxfiy identifikator kiritish log, URL va auditda ma’lumot oshkor qilishi mumkin.
Random UUID collisionni kamaytiradi va nom o‘zgarishidan mustaqil bo‘ladi. Content hashga asoslangan key deduplication va integrityga yordam beradi. Original filename metadata sifatida saqlanishi mumkin; uni bevosita key qilish Unicode, normalization va bir xil nom muammosini keltiradi.
Encoding va canonicalization
Key URL ichida ishlatilganda reserved belgilar percent-encoding talab qiladi. Client SDK odatda encodingni bajaradi, lekin keyni ikki marta encode qilish boshqa objectga murojaat qiladi. +, %, control character va trailing space turli vositalarda chalkash ko‘rinishi mumkin.
Unicode bir xil ko‘rinadigan, ammo turli code point ketma-ketligidagi nomlarni yaratishi mumkin. Application normalization siyosatini key yaratilishidan oldin qo‘llaydi. Case sensitivity ham platforma semantikasiga bog‘liq; ko‘p object storage Logo.png va logo.pngni alohida key deb qabul qiladi.
Atomicity va overwrite
Object PUT muvaffaqiyatli tugaganda yangi object key ostida ko‘rinadi. Bir nechta writer bir keyga yozsa last-write-wins yoki conditional request semantikasi ishlaydi. If-Match va version token eskirgan qiymat ustidan jim overwrite qilishni cheklaydi.
Rename ko‘pincha native metadata amali emas. Object yangi keyga copy qilinib, eski key o‘chiriladi. Bu ikki bosqich orasida ikkala nusxa yoki faqat bittasi ko‘rinishi mumkin. Katta objectda copy vaqt va request xarajati talab qiladi.
Prefix va performance
Prefix bo‘yicha listing pagination bilan bajariladi. Millionlab objectni bitta requestda olish mumkin emas. Continuation token keyingi sahifani davom ettiradi; listing davomida objectlar qo‘shilsa snapshot consistency kafolati platformaga bog‘liq.
Eski storage arxitekturalarida ketma-ket prefix hot partition yaratishi mumkin edi; zamonaviy xizmatlar ko‘pincha avtomatik taqsimlaydi. Shunga qaramay, request rate va partition tavsiyasi aynan tanlangan xizmat hujjatidan olinadi. Key formatini taxminiy optimization uchun murakkablashtirishdan oldin real limit o‘lchanadi.
Access va audit
Policy prefix asosida ma’lum jamoaga faqat tenant-42/ ostidagi objectlarga ruxsat berishi mumkin. User input prefixni chetlab o‘tmasligi uchun key server tomonidan canonical shaklda yaratiladi. Object storage keyi filesystem path bo‘lmasa ham authorization boundary sifatida qat’iy tekshiriladi.
Loglarda keylar ko‘rinishi mumkin, shuning uchun ularning o‘zida secret saqlanmaydi. Signed URL key va vaqtinchalik imzoni birlashtiradi; uning amal muddati, methodi va content constraintlari toraytiriladi.
Bog‘liq tushunchalar
Object storage, Bucket, Prefix, Version ID, Content-addressed storage, Signed URL, Unicode normalization