Saqlash klasslari va lifecycle qoidalari: ombor xarajatini kamaytirish

Qisqa javob

Obyektli ombor provayderlari bir nechta saqlash klassini taklif qiladi. Klass gigabayt uchun qanchalik arzon bo‘lsa, ma’lumotni qayta o‘qish shunchalik qimmat va obyektni muddatidan oldin o‘chirsangiz ham, uning uchun shunchalik uzoq to‘laysiz.

Hayot sikli qoidalari (lifecycle rules) obyektlarni yoshi, prefiksi yoki versiyasiga qarab klasslar orasida avtomatik ko‘chiradi va o‘chiradi. To‘g‘ri sozlansa, ular qo‘lda ishlamasdan hisobni kamaytiradi. E’tiborsiz sozlansa, tejalgan summadan ko‘proq o‘qish va muddatidan oldin o‘chirish to‘lovlarini keltirib chiqaradi.

Saqlashning uch darajasi

• Issiq: saqlash narxi eng yuqori, o‘qish to‘lovi va minimal muddat yo‘q. Tez-tez o‘qiladigan ma’lumotlar uchun.
• Kam murojaat: saqlash arzonroq, lekin har bir GB uchun o‘qish to‘lovi va minimal saqlash muddati bor. Zaxira nusxalar va ba’zan o‘qiladigan eski fayllar uchun.
• Arxiv: eng arzon saqlash, eng qimmat o‘qish va eng uzun minimal muddatlar. Azure Archive hamda S3 Glacier Flexible Retrieval yoki Deep Archive’da obyektni o‘qishdan oldin tiklash (rehydrate) kerak, bu soatlab vaqt olishi mumkin.

Avtomatik variantlar ham bor: S3 Intelligent-Tiering va GCS Autoclass obyektlarni haqiqiy murojaatga qarab ko‘chiradi. Ular murojaat xarakteri oldindan bilinmaydigan ma’lumotlarga mos.

O‘qish to‘lovi va minimal muddatlar

Kutilmagan hisoblarning ko‘pi aynan shu ikki parametrdan kelib chiqadi.

Minimal saqlash muddati: obyektni oldinroq o‘chirsangiz, ustidan yozsangiz yoki ko‘chirsangiz ham, butun minimal muddat uchun to‘laysiz. Yozish paytidagi odatiy qiymatlar:

Qoidalarni loyihalashdan oldin provayderingizning joriy narxlar sahifasini tekshiring.

Boshqa xarajat omillari:

• Issiq bo‘lmagan klasslardan har bir GB’ni o‘qish uchun to‘lov.
• Sovuq klasslarda so‘rovlar narxi ko‘pincha yuqoriroq, har bir lifecycle o‘tishi esa o‘zi ham so‘rov hisoblanadi.
• Kichik obyektlar: ba’zi klasslar obyektning minimal o‘lchamini hisoblaydi yoki har bir obyektga qo‘shimcha metama’lumot qo‘shadi. Millionlab mayda fayllar ko‘chirilgandan keyin arzonroq emas, qimmatroq bo‘lib qolishi mumkin.

Oddiy qoida: ma’lumotni sovuq klassga faqat u yerda minimal muddatdan uzoqroq turishiga va kam o‘qilishiga ishonchingiz komil bo‘lsa ko‘chiring.

Lifecycle qoidalarini qanday loyihalash kerak

1. Ma’lumotlarni prefiks yoki teg bo‘yicha guruhlang: logs/, backups/, uploads/. Butun bakket uchun bitta qoida emas, har bir ma’lumot turi uchun bitta qoida.
2. Murojaat xarakterini tushuning: ma’lumot qancha vaqt faol o‘qiladi? Qachondan faqat audit uchun kerak bo‘ladi?
3. Minimal muddatlarga rioya qilib, issiqdan sovuqqa o‘tishlarni belgilang.
4. Ma’lum yoshdan keyin ma’lumot kerak bo‘lmasa, o‘chirishni (expiration) belgilang.
5. Versiyalashni hisobga oling: joriy bo‘lmagan versiyalarni o‘chiring, aks holda o‘chirilgan obyektlar pul talab qilishda davom etadi.
6. Tugallanmagan multipart-yuklashlarni to‘xtating: uzilib qolgan katta yuklashlar ko‘rinmas qismlarni qoldiradi va ular uchun saqlash haqi olinadi.

S3 uchun lifecycle konfiguratsiyasi misoli:

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 120, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 730 }
    },
    {
      "ID": "versions-and-uploads-cleanup",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30, "NewerNoncurrentVersions": 3 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Bu yerda loglar 30 kundan keyin Standard-IA’ga, 120 kundan keyin Glacier Flexible Retrieval’ga o‘tadi va ikki yildan keyin o‘chiriladi. Ikkinchi qoida eski versiyalarni joriy bo‘lmay qolganidan 30 kun o‘tgach o‘chiradi, lekin eng yangi uchtasini doim saqlab qoladi, hamda bir haftadan keyin multipart-yuklashlar qoldiqlarini tozalaydi.

Google Cloud Storage va Azure’da g‘oyalar o‘sha, sintaksis boshqacha: GCS’da age yoki versiya shartlari bilan SetStorageClass, Delete va AbortIncompleteMultipartUpload amallari, Azure lifecycle management siyosatlarida esa tierToCool, tierToArchive va delete amallari. Barcha maydonlar rasmiy S3 lifecycle hujjatlarida tavsiflangan.

Ko‘p uchraydigan xatolar

• Hamma narsani arxivga ko‘chirish, keyin har bir analitik vazifa uchun ma’lumotni tiklash.
• Qisqa yashaydigan ma’lumotlar sovuq klasslarda: bir haftada o‘chiriladigan vaqtinchalik fayllar baribir 30 yoki 90 kun uchun to‘lanadi.
• Tozalashsiz versiyalash: bakket yashirin eski versiyalar va delete marker’lar hisobiga cheksiz o‘sadi.
• Unutilgan multipart-yuklashlar: obyektlar ro‘yxati o‘zgarmasa ham hajm o‘sadi.
• Faqat bitta prefiksga kerak bo‘lganda butun bakketga qoida qo‘llash.
• Testsiz ishga tushirish: yangi qoidalarni avval test prefiksida yoqing va hammasiga qo‘llashdan oldin xarajatlar hisobotini kuzating.