تحسين التكاليف من خلال إدارة دورة حياة البيانات تلقائيا

  • مقالة

توفر إدارة دورة حياة تخزين Azure Blob نهج يستند إلى القواعد يمكنك استخدامه لانتقال بيانات الكائن الثنائي كبير الحجم إلى مستويات الوصول المناسبة أو انتهاء صلاحية البيانات في نهاية دورة حياة البيانات.

باستخدام نهج إدارة دورة الحياة، يمكنك:

  • انقل الكائنات الثنائية كبيرة الحجم من النقاط الباردة إلى الساخنة فور الوصول إليها لتحسين الأداء.
  • مرحلة انتقالية للإصدارات الحالية من عنصر ثنائي كبير الحجم، أو الإصدارات السابقة من عنصر ثنائي كبير الحجم، أو لقطات عنصر ثنائي كبير الحجم إلى لقطة طبقة تخزين أكثر برودة إذا لم يتم الوصول إلى هذه العناصر أو تعديلها لفترة من الوقت، لتحسين التكلفة.
  • قم بحذف الإصدارات الحالية من كائنات البيانات الثنائية، أو الإصدارات السابقة منها، أو لقطاتها في نهاية دورات حياتها.
  • تطبيق القواعد على حساب تخزين كامل، أو لتحديد حاويات، أو على مجموعة فرعية من الكائنات الثنائية كبيرة الحجم باستخدام بادئات الأسماء أو علامات فهرس الكائنات الثنائية كبيرة الحجم كعوامل تصفية.

تلميح

بينما تساعدك إدارة دورة الحياة على نقل البيانات بين المستويات في حساب واحد، يمكنك استخدام مهمة تخزين لإنجاز هذه المهمة على نطاق واسع عبر حسابات متعددة. مهمة التخزين هي مورد متوفر في Azure Storage Actions؛ إطار عمل بلا خادم يمكنك استخدامه لتنفيذ عمليات البيانات الشائعة على ملايين العناصر عبر حسابات تخزين متعددة. لمعرفة المزيد، راجع ما هي إجراءات تخزين Azure؟.

يتم دعم نهج إدارة دورة الحياة لـblobs كتلة وإلحاق الكائنات الثنائية كبيرة الحجم في الأغراض العامة v2، والكائنات الثنائية كبيرة الحجم للكتلة المتميزة، وحسابات تخزين Blob. لا تؤثر إدارة دورة الحياة على حاويات النظام مثل حاويات $logs أو $web.

هام

إذا كانت مجموعة البيانات تتطلب أن تكون قابلة للقراءة، فلا تقم بتعيين نهج لنقل كائنات البيانات الثنائية كبير الحجم إلى طبقة الأرشيف. لا يمكن قراءة كائنات البيانات الثنائية كبير الحجم في طبقة الأرشيف ما لم يتم إلغاء تسلسلها أولًا، وهي عملية قد تستغرق وقتًا طويلًا وتكلفة كبيرة. لمزيد من المعلومات، اطّلع على نظرة عامة على إلغاء تسلسل كائنات البيانات الثنائي من طبقة الأرشيف. إذا كانت مجموعة البيانات تحتاج إلى القراءة في كثير من الأحيان، فلا تقم بتعيين نهج لنقل الكائنات الثنائية كبيرة الحجم إلى المستويات الباردة أو الباردة لأن هذا قد يؤدي إلى ارتفاع تكاليف المعاملات.

تحسين التكاليف من خلال إدارة دورة حياة البيانات

تحتوي مجموعات البيانات على دورة حياة فريدة. في وقت مبكر من دورة الحياة، يصل الأشخاص إلى بعض البيانات في كثير من الأحيان. ولكن غالبًا ما تقل الحاجة إلى الوصول بشكل جذري مع قِدم البيانات. تظل بعض البيانات مُعطلة في السحابة ونادرًا ما يتم الوصول إليها بمجرد تخزينها. تنتهي صلاحية بعض مجموعات البيانات بعد أيام أو أشهر من الإنشاء، بينما تتم قراءة مجموعات البيانات الأخرى وتعديلها على نحوٍ فعال طوال مدة بقائها.

فكّر في سيناريو يتم فيه الوصول إلى البيانات بشكل متكرر أثناء المراحل الأولى من دورة الحياة، ولكن أحيانًا بعد أسبوعين فقط. بعد الشهر الأول، نادراً ما يتم الوصول إلى مجموعة البيانات. في هذا السيناريو، يعد التخزين في طبقة Hot الخيار الأفضل أثناء المراحل المبكرة. ويعد التخزين في طبقة Cool الخيار الأكثر ملاءمة للوصول العرضي. يعتبر التخزين في طبقة Archive أفضل خيار بعد أن تتقادم البيانات لأكثر من شهر. بنقل البيانات إلى طبقة التخزين المناسبة استنادًا إلى قِدمها حسب قواعد نهج إدارة دورة الحياة، يمكنك تصميم الحل الأقل تكلفة المناسب لاحتياجاتك.

تعريف نهج إدارة دورة الحياة

نهج إدارة دورة الحياة هو مجموعة من القواعد في مستند JSON. تعرض عينة JSON التالية تعريفًا كاملًا للقاعدة:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

إن النهج هو مجموعة من القواعد، كما هو موضح في الجدول التالي:

اسم المعلمة نوع المعلمة ملاحظات
rules صفيفة من عناصر القاعدة مطلوب قاعدة واحدة على الأقل في النهج. يمكنك تحديد ما يصل إلى 100 قاعدة في النهج.

تحتوي كل قاعدة ضمن النهج على عدة معلّمات، موضحة في الجدول التالي:

اسم المعلمة نوع المعلمة ملاحظات المطلوب
name السلسلة‬ يمكن أن يتضمن اسم القاعدة ما يصل إلى 256 حرفاً أبجدياً رقمياً. اسم القاعدة حساس لحالة الأحرف. يجب أن يكون فريداً من نوعه في إطار النهج. صواب
enabled Boolean قيمة منطقية اختيارية للسماح بتعطيل قاعدة مؤقتاً. القيمة الافتراضية صحيحة إذا لم يتم تعيينها. خطأ
type قيمة قائمة التعداد النوع الصحيح الحالي هو Lifecycle. صواب
definition عنصر يحدد قاعدة دورة الحياة يتكون كل تعريف من مجموعة عوامل تصفية ومجموعة إجراءات. صواب

تعريف قاعدة إدارة دورة الحياة

يتضمن كل تعريف قاعدة ضمن نهج مجموعة عوامل تصفية ومجموعة إجراءات. تحد مجموعة عوامل التصفية من إجراءات القاعدة لمجموعة معينة من العناصر داخل الحاوية أو أسماء العناصر. تُطبّق مجموعة الإجراءات إجراءات الطبقة أو تحذفها من مجموعة العناصر المصفاة.

قاعدة النموذج

تقوم قاعدة النموذج التالية بتصفية الحساب لتشغيل الإجراءات على العناصر الموجودة بالداخل sample-container والبدء بها blob1.

  • طبقة blob لتبريد الطبقة بعد 30 يوماً من آخر تعديل
  • طبقة blob لأرشفة الطبقة بعد 90 يوماً من آخر تعديل
  • حذف blob بعد 2555 يوماً (سبع سنوات) من التعديل الأخير
  • حذف الإصدارات السابقة بعد 90 يومًا من الإنشاء
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

إشعار

يشير عنصر baseBlob في نهج إدارة دورة الحياة إلى الإصدار الحالي من blob. يشير عنصر الإصدار إلى إصدارٍ سابقٍ.

عوامل تصفية القواعد

تحدد عوامل التصفية إجراءات القاعدة على مجموعة فرعية من blobs داخل حساب التخزين. إذا تم تحديد أكثر من عامل تصفية واحد، فسيتم تشغيل AND المنطقي على جميع عوامل التصفية. يمكنك استخدام عامل تصفية لتحديد الكائنات الثنائية كبيرة الحجم المراد تضمينها. لا يوفر عامل التصفية أي وسيلة لتحديد الكائنات الثنائية كبيرة الحجم التي يجب استبعادها.

وتشمل عوامل التصفية:

اسم عامل التصفية نوع عامل التصفية ملاحظات مطلوب
أنواع blob مصفوفة من قيم التعداد المحددة مسبقاً. يدعم الإصدار الحالي blockBlob و appendBlob. يتم دعم إجراء الحذف فقط ل appendBlob؛ Set Tier غير مدعوم. ‏‏نعم‬
prefixMatch مصفوفة من سلاسل البادئات لمطابقتها. يمكن لكل قاعدة تحديد ما يصل إلى 10 بادئات تُحسس حالة الأحرف. يجب أن تبدأ سلسلة بادئة باسم حاوية. على سبيل المثال، إذا كنت تريد مطابقة كافة الكائنات الثنائية كبيرة الحجم ضمن https://myaccount.blob.core.windows.net/sample-container/blob1/...، فحدد البادئةMatch ك sample-container/blob1. سيطابق عامل التصفية هذا جميع الكائنات الثنائية كبيرة الحجم في حاوية العينة التي تبدأ أسماؤها ب blob1.

.		 إذا لم تحدد prefixMatch، فإن القاعدة تنطبق على جميع الكائنات الثنائية كبيرة الحجم داخل حساب التخزين. لا تدعم سلاسل البادئة مطابقة أحرف البدل. يتم التعامل مع الأحرف مثل * و ? كأحرف سلسلة حرفية. لا
blobIndexMatch مصفوفة من قيم القاموس تتكون من مفتاح علامة فهرس blob وشروط القيمة المراد مطابقتها. يمكن لكل قاعدة تحديد ما يصل إلى 10 شروط لعلامة فهرس blob. على سبيل المثال، إذا كنت تريد مطابقة جميع كائنات البيانات الثنائية كبير الحجم مع Project = Contoso ضمن https://myaccount.blob.core.windows.net/ في القاعدة، فإن blobIndexMatch هي {"name": "Project","op": "==","value": "Contoso"}. إذا لم تقم بتعريف blobIndexMatch، فستنطبق القاعدة على جميع كائنات البيانات الثنائية كبيرة الحجم داخل حساب التخزين. لا

لمعرفة المزيد حول ميزة فهرس blob بالإضافة إلى المشكلات والقيود المعروفة، راجع إدارة البيانات والبحث عنها على Azure Blob Storage باستخدام فهرس blob.

إجراءات القاعدة

يتم تطبيق الإجراءات على blobs المصفاة عند استيفاء شرط التشغيل.

تدعم إدارة دورة الحياة ترتيب الطبقات وحذف الإصدارات الحالية والإصدارات السابقة ولقطات blob. حدّد على الأقل إجراء واحدًا لكل قاعدة.

إشعار

لا يتم دعم ترتيب المستويات بعد في حساب تخزين كائن ثنائي كبير الحجم للكتلة المتميزة. بالنسبة لجميع الحسابات الأخرى، يسمح بالتصنيف فقط على الكائنات الثنائية كبيرة الحجم للكتلة وليس للكائنات الثنائية كبيرة الحجم للإلحاق والصفحة.

الإجراء الإصدار الحالي اللقطة الإصدارات السابقة
tierToCool يدعم blockBlob مدعوم مدعوم
tierToCold يدعم blockBlob مدعوم مدعوم
تمكينAutoTierToHotFromCool1 يدعم blockBlob غير مدعوم غير مدعوم
tierToArchive4 يدعم blockBlob مدعوم مدعوم
حذف2,3 يدعم blockBlob و appendBlob مدعوم مدعوم

1enableAutoTierToHotFromCool يتوفر الإجراء فقط عند استخدامه مع daysAfterLastAccessTimeGreaterThan شرط التشغيل. يتم وصف هذا الشرط في الجدول التالي.

2 عند تطبيقه على حساب مع تمكين مساحة اسم هرمية، يزيل إجراء الحذف الدلائل الفارغة. إذا لم يكن الدليل فارغا، فسيزيل إجراء الحذف العناصر التي تفي بشروط النهج ضمن دورة تنفيذ نهج دورة الحياة الأولى. إذا كان هذا الإجراء ينتج دليلا فارغا يلبي أيضا شروط النهج، فستتم إزالة هذا الدليل ضمن دورة التنفيذ التالية، وهكذا.

3 لن يحذف نهج إدارة دورة الحياة الإصدار الحالي من كائن ثنائي كبير الحجم حتى يتم حذف أي إصدارات سابقة أو لقطات مقترنة بهذا الكائن الثنائي كبير الحجم. إذا كانت الكائنات الثنائية كبيرة الحجم في حساب التخزين الخاص بك تحتوي على إصدارات أو لقطات سابقة، فيجب عليك تضمين الإصدارات واللقطات السابقة عند تحديد إجراء حذف كجزء من النهج.

4 فقط حسابات التخزين التي تم تكوينها ل LRS أو GRS أو RA-GRS تدعم نقل الكائنات الثنائية كبيرة الحجم إلى طبقة الأرشيف. طبقة الأرشيف غير مدعومة لحسابات ZRS أو GZRS أو RA-GZRS. يتم سرد هذا الإجراء استنادا إلى التكرار الذي تم تكوينه للحساب.

إشعار

إذا قمت بتحديد أكثر من إجراء واحد على نفس blob، فإن إدارة دورة الحياة تطبق الإجراء الأقل تكلفة على الـ blob. على سبيل المثال، إجراء delete أرخص من الإجراء tierToArchive. إجراء tierToArchive أرخص من الإجراء tierToCool.

وتستند شروط التشغيل على العمر. تستخدم الإصدارات الحالية تاريخ آخر تعديل أو تاريخ آخر وصول، وتستخدم الإصدارات السابقة زمن إنشاء الإصدار، وتستخدم لقطات blob زمن إنشاء اللقطة لتتبع العمر.

إجراء تشغيل الشرط قيمة الشرط ‏‏الوصف
daysAfterModificationGreaterThan قيمة عدد صحيح تشير إلى العمر بالأيام شرط تنفيذ الإجراءات على الإصدار الحالي لـ blob
daysAfterCreationGreaterThan قيمة عدد صحيح تشير إلى العمر بالأيام شرط الإجراءات على الإصدار الحالي أو الإصدار السابق من كائن ثنائي كبير الحجم أو لقطة كائن ثنائي كبير الحجم
daysAfterLastAccessTimeGreaterThan1 قيمة عدد صحيح تشير إلى العمر بالأيام شرط الإصدار الحالي لـ blob عند تمكين تتبع الوصول
daysAfterLastTierChangeGreaterThan قيمة عدد صحيح تشير إلى العمر بالأيام بعد آخر وقت لتغيير طبقة الكائن الثنائي كبير الحجم ينطبق هذا الشرط فقط على الإجراءات tierToArchive ويمكن استخدامه فقط مع الشرط daysAfterModificationGreaterThan.

1 إذا لم يتم تمكين تعقب وقت الوصول الأخير، فإن daysAfterLastAccessTimeGreaterThan يستخدم تاريخ تمكين نهج دورة الحياة بدلا من LastAccessTime خاصية الكائن الثنائي كبير الحجم. يتم استخدام هذا التاريخ أيضا عندما تكون الخاصية LastAccessTime قيمة خالية. لمزيد من المعلومات حول استخدام تعقب وقت الوصول الأخير، راجع نقل البيانات استنادا إلى آخر وقت تم الوصول إليه.

يتم تشغيل نهج دورة الحياة

يقوم النظام الأساسي بتشغيل نهج دورة الحياة مرة واحدة في اليوم. عند تكوين نهج دورة حياة أو تحريره. قد يستغرق الأمر ما يصل إلى 24 ساعة حتى تدخل التغييرات حيز التنفيذ وبدء التنفيذ الأول. يعتمد الوقت المستغرق لإكمال إجراءات النهج على عدد الكائنات الثنائية كبيرة الحجم التي تم تقييمها وتشغيلها.

إذا قمت بتعطيل نهج، فلن تتم جدولة أي عمليات تشغيل جديدة للنهج، ولكن إذا كان هناك تشغيل قيد التقدم بالفعل، فسيستمر هذا التشغيل حتى يكتمل وتتم محاسبتك على أي إجراءات مطلوبة لإكمال التشغيل. راجع التوفر الإقليمي والتسعير.

الحدث المكتمل لنهج دورة الحياة

LifecyclePolicyCompleted يتم إنشاء الحدث عند تنفيذ الإجراءات المحددة بواسطة نهج إدارة دورة الحياة. يعرض ملف json التالي مثالاً على الحدث LifecyclePolicyCompleted.

{
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
    "subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
    "eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
    "eventTime": "2022-05-26T00:00:40.1880331",    
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "data": {
        "scheduleTime": "2022/05/24 22:57:29.3260160",
        "deleteSummary": {
            "totalObjectsCount": 16,
            "successCount": 14,
            "errorList": ""
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

يصف الجدول التالي مخطط الحدث LifecyclePolicyCompleted.

الحقل نوع ‏‏الوصف
وقت الجدولة سلسلة الوقت الذي تمت فيه جدولة نهج دورة الحياة
deleteSummary بايت متجه<> ملخص نتائج الكائنات الثنائية كبيرة الحجم المجدولة لعملية الحذف
tierToCoolSummary بايت متجه<> ملخص نتائج الكائنات الثنائية كبيرة الحجم المجدولة لعملية من المستوى إلى التبريد
tierToArchiveSummary بايت متجه<> ملخص نتائج الكائنات الثنائية كبيرة الحجم المجدولة لعملية من المستوى إلى الأرشيف

أمثلة على نُهج دورة الحياة

توضح الأمثلة التالية كيفية معالجة السيناريوهات الشائعة باستخدام قواعد نهج دورة الحياة.

نقل البيانات القديمة إلى طبقة بادرة

يوضح هذا المثال كيفية نقل كتلة كائنات البيانات الثنائية كبير الحجم المسبوقة بـ sample-container/blob1 أو container2/blob2. تنقل السياسة كائنات البيانات الثنائية كبيرة الحجم التي لم يتم تعديلها منذ أكثر من 30 يومًا إلى التخزين البارد، والـ blobs التي لم يتم تعديلها خلال 90 يومًا إلى طبقة الأرشيف:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

نقل البيانات استنادًا إلى آخر زمن للوصول

يمكنك تمكين تتبع آخر زمن للوصول للاحتفاظ بسجلٍّ عن تاريخ آخر قراءة لـ blob أو كتابتها وعاملٍ للتصفية لإدارة ترتيب بيانات blob والاحتفاظ بها. لمعرفة كيفية تمكين تعقب تاريخ آخر وصول، انظر تمكين تعقب تاريخ الوصول بشكل اختياري.

عند تمكين تتبع تاريخ آخر وصول، يتم تحديث خاصية blob المسماة LastAccessTime عند قراءة كائن blob أو كتابته. تعتبر عملية Get Blob هي عملية وصول. لا تعدالحصول على خصائص كائن ثنائي كبير الحجم، والحصول على بيانات التعريف لكائن ثنائي كبير الحجم، والحصول على علامات كائن ثنائي كبير الحجم عمليات وصول، وبالتالي لا تقم بتحديث وقت الوصول الأخير.

إذا تم تمكين تعقب وقت الوصول الأخير، تستخدم LastAccessTime إدارة دورة الحياة لتحديد ما إذا كان شرط التشغيل DaysAfterLastAccessTimeGreaterThan استيفاء أم لا. تستخدم إدارة دورة الحياة تاريخ تمكين نهج دورة الحياة بدلا من LastAccessTime الحالات التالية:

  • قيمة الخاصية LastAccessTime للكائن الثنائي كبير الحجم قيمة خالية.

    إشعار

    lastAccessedOn الخاصية للكائن الثنائي كبير الحجم فارغة إذا لم يتم الوصول إلى كائن ثنائي كبير الحجم منذ تمكين تعقب وقت الوصول الأخير.

  • لم يتم تمكين تعقب وقت الوصول الأخير.

تصغير التأثير على زمن انتقال وصول للقراءة فقط، فإن القراءة الأولى فقط لآخر 24 ساعة تحديث وقت الوصول الأخير. لا تقوم عمليات القراءة اللاحقة خلال فترة الـ 24 ساعة نفسها بتحديث تاريخ آخر وقت وصول. إذا تم تعديل الـ blob بين عمليات القراءة، فإن تاريخ آخر وصول هو الأحدث بين القيمتين.

في المثال التالي، يتم نقل كائنات البيانات الثنائية كبير الحجم إلى التخزين البارد إذا لم يتم الوصول إليه لمدة 30 يومًا. الخاصية enableAutoTierToHotFromCool هي خاصية منطقية تشير إلى ما إذا كان يجب ترتيب كائن ثنائي كبير الحجم تلقائياً من بارد إلى ساخن إذا تم الوصول إليه مرة أخرى بعد ترتيب طبقاته ليبرد.

تلميح

إذا تم نقل كائن ثنائي كبير الحجم إلى المستوى البارد، ثم تم نقله تلقائيا مرة أخرى قبل انقضاء 30 يوما، يتم فرض رسوم حذف مبكرة. قبل تعيين الخاصية enablAutoTierToHotFromCool ، تأكد من تحليل أنماط الوصول لبياناتك حتى تتمكن من تقليل الرسوم غير المتوقعة.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

أرشفة البيانات بعد إدخالها

تظل بعض البيانات مُعطّلة في السحابة ونادرًا ما يتم الوصول إليها، إن حدث ذلك. تم تكوين نهج دورة الحياة متابعة لأرشفة البيانات بعد وقت قصير من استيعابها. يقوم هذا المثال بنقل كتلة كائنات البيانات الثنائية كبير الحجم في حاوية تسمى archivecontainer إلى طبقة الأرشيف. يتم تنفيذ الانتقال من خلال العمل على كائنات البيانات الثنائية كبير الحجم لمدة 0 أيام بعد تاريخ آخر تعديل.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

إشعار

توصي Microsoft بتحميل الكائنات الثنائية كبيرة الحجم مباشرة إلى طبقة الأرشيف لمزيد من الكفاءة. يمكنك تحديد طبقة الأرشيف من عنوان x-ms-access-tierفي عملية Put Blob أو Put Block List. يتم دعم عنوان x-ms-access-tier في إصدار REST 2018-11-09 ومكتبات عميل تخزين blob الحديثة أو في إصدارها الأخير.

البيانات منتهية الصلاحية بناء على القِدم

من المتوقع أن تنتهي صلاحية بعض البيانات بعد أيام أو أشهر من إنشائها. يمكنك تكوين نهج إدارة دورة حياة لتنتهي صلاحية البيانات بحذفها استنادًا إلى قِدم البيانات. يوضح المثال التالي نهج يحذف كافة الكائنات الثنائية كبيرة الحجم للكتلة التي لم يتم تعديلها في آخر 365 يوماً.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

حذف البيانات باستخدام علامات فهرس blob

ينبغي أن تنتهي صلاحية بعض البيانات فقط إذا تم وضع علامة صريحة عليها بالحذف. يمكنك تكوين نهج إدارة دورة حياة لانتهاء صلاحية البيانات التي تم وضع علامة عليها بسمات مفتاح/قيمة فهرس blob. يوضح المثال التالي نهجًا يحذف جميع كتل كائنات البيانات الثنائية كبير الحجم عليها علامة Project = Contoso. لمعرفة المزيد حول فهرس كائن ثنائي كبير الحجم، راجع إدارة البيانات والبحث عنها على مساحة تخزين Azure Blob باستخدام فهرس كائن ثنائي كبير الحجم.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

إدارة الإصدارات السابقة

بالنسبة للبيانات التي يتم تعديلها والوصول إليها بانتظام طوال مدة بقائها، يمكنك تمكين تعيين إصدار تخزين blob للحفاظ تلقائيًّا على الإصدارات السابقة للكائن. يمكنك إنشاء نهج لترتيب الإصدارات السابقة أو حذفها. يتم تحديد عمر الإصدار من خلال تقييم وقت إنشاء الإصدار. تتدرج قاعدة النهج هذه لنقل الإصدارات السابقة داخل الحاوية activedata التي تبلغ 90 يوماً أو أقدم بعد إنشاء الإصدار إلى مستوى بارد، وتحذف الإصدارات السابقة التي تبلغ 365 يوماً أو أقدم.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

التوافر الإقليمي والتسعير

تتوفر ميزة إدارة دورة الحياة في جميع مناطق Azure.

إن نُهج إدارة دورة الحياة مجانية. تتم فوترة العملاء مقابل تكاليف التشغيل القياسية لاستدعاء واجهة برمجة تطبيقات Set Blob Tier. إن عمليات الحذف مجانية. ومع ذلك، قد تفرض خدمات وأدوات مساعدة أخرى في Azure مثلMicrosoft Defender لتخزين رسوماً مقابل العمليات التي تتم إدارتها من خلال نهج دورة الحياة.

تتم فوترة كل تحديث لتاريخ آخر وصول لـ blob ضمن فئة العمليات الأخرى. يتم فرض رسوم على كل تحديث لوقت الوصول الأخير ك "معاملة أخرى" مرة واحدة على الأكثر كل 24 ساعة لكل كائن حتى إذا تم الوصول إليه 1000 مرة في اليوم. هذا منفصل عن رسوم معاملات القراءة.

لمزيد من المعلومات حول الأسعار، راجع أسعار Block Blob.

المشكلات المعروفة والقيود

  • لا يتم دعم ترتيب المستويات بعد في حساب تخزين كائن ثنائي كبير الحجم للكتلة المتميزة. بالنسبة لجميع الحسابات الأخرى، يسمح بالتصنيف فقط على الكائنات الثنائية كبيرة الحجم للكتلة وليس للكائنات الثنائية كبيرة الحجم للإلحاق والصفحة.

  • يجب قراءة نهج إدارة دورة الحياة أو كتابته بالكامل. التحديثات الجزئية غير معتمدة.

  • يمكن أن تحتوي كل قاعدة على ما يصل إلى 10 بادئات لتحسين حالة الأحرف وما يصل إلى 10 شروط علامة فهرس وكائن ثنائي كبير الحجم.

  • إذا قمت بتمكين قواعد جدار الحماية لحساب التخزين الخاص بك، فقد يتم حظر طلبات إدارة دورة الحياة. يمكنك إلغاء حظر هذه الطلبات من خلال توفير استثناءات لخدمات Microsoft الموثوقة. لمزيد من المعلومات، راجع قسم الاستثناءات في تكوين جدران الحماية والشبكات الظاهرية.

  • لا يمكن لنهج إدارة دورة الحياة تغيير طبقة الكائن الثنائي كبير الحجم الذي يستخدم نطاق تشفير.

  • لن يعمل إجراء الحذف الخاص بنهج إدارة دورة الحياة مع أي كائن ثنائي كبير الحجم في حاوية غير قابلة للتغيير. باستخدام نهج غير قابل للتغيير، يمكن إنشاء الكائنات وقراءتها، ولكن لا يمكن تعديلها أو حذفها. لمزيد من المعلومات، راجع تخزين بيانات البيانات الثنائية الكبيرة المهمة للأعمال باستخدام وحدة تخزين ثابتة.

الأسئلة الشائعة (FAQ)

راجع الأسئلة المتداولة حول إدارة دورة الحياة.

الخطوات التالية