Veri yaşam döngüsünü otomatik olarak yöneterek maliyetleri iyileştirme
Azure Blob Depolama yaşam döngüsü yönetimi, blob verilerini uygun erişim katmanlarına geçirme veya veri yaşam döngüsünün sonunda verilerin süresinin dolması için kullanabileceğiniz kural tabanlı bir ilke sunar.
Yaşam döngüsü yönetimi ilkesiyle şunları yapabilirsiniz:
- Performansı iyileştirmek için blobları seyrek erişimden erişildiğinde hemen sık erişimliye geçirme.
- Maliyeti iyileştirmek için bir blobun geçerli sürümlerini, blobun önceki sürümlerini veya blob anlık görüntülerini bir süre boyunca bu nesnelere erişilmemiş veya değiştirilmemişse daha serin bir depolama katmanına geçirin.
- Blobun geçerli sürümlerini, blobun önceki sürümlerini veya blob anlık görüntülerini yaşam döngülerinin sonunda silin.
- Ad ön eklerini veya blob dizin etiketlerini filtre olarak kullanarak depolama hesabının tamamına, kapsayıcıları seçmek için veya blobların bir alt kümesine kurallar uygulayın.
İpucu
Yaşam döngüsü yönetimi verileri tek bir hesaptaki katmanlar arasında taşımanıza yardımcı olsa da, bu görevi birden çok hesapta büyük ölçekte gerçekleştirmek için bir depolama görevi kullanabilirsiniz. Depolama görevi, Azure Depolama Eylemleri'nde kullanılabilen bir kaynaktır; birden çok depolama hesabında milyonlarca nesne üzerinde ortak veri işlemleri gerçekleştirmek için kullanabileceğiniz sunucusuz bir çerçevedir. Daha fazla bilgi edinmek için bkz . Azure Depolama Eylemleri nedir?.
Genel amaçlı v2, premium blok blobu ve Blob Depolama hesaplarında blok blobları ve ekleme blobları için yaşam döngüsü yönetimi ilkeleri desteklenir. Yaşam döngüsü yönetimi veya $web kapsayıcıları gibi sistem kapsayıcılarını $logs etkilemez.
Önemli
Bir veri kümesinin okunabilir olması gerekiyorsa, blobları arşiv katmanına taşımak için bir ilke ayarlamayın. Arşiv katmanındaki bloblar, zaman alan ve pahalı olabilecek bir işlem olan ilk kez yeniden doldurulmadıkça okunamaz. Daha fazla bilgi için bkz . Arşiv katmanından blob yeniden doldurmaya genel bakış. Bir veri kümesinin sık okunması gerekiyorsa, blobları seyrek erişimli veya soğuk katmanlara taşımak için bir ilke ayarlamayın, bu da işlem maliyetlerinin daha yüksek olmasına neden olabilir.
Veri yaşam döngüsünü yöneterek maliyetleri iyileştirme
Veri kümelerinin benzersiz yaşam döngüleri vardır. Yaşam döngüsünün başlarında, insanlar bazı verilere sık sık erişer. Ancak erişim ihtiyacı genellikle veriler yaşlanırken önemli ölçüde azalır. Bazı veriler bulutta boşta kalır ve depolandıktan sonra nadiren erişilir. Bazı veri kümelerinin süresi oluşturulduktan günler veya aylar sonra dolarken, diğer veri kümeleri yaşam süreleri boyunca etkin bir şekilde okunur ve değiştirilir.
Verilere yaşam döngüsünün ilk aşamalarında, ancak yalnızca iki hafta sonra sıklıkla erişildiği bir senaryo düşünün. İlk ayın ötesinde veri kümesine nadiren erişilir. Bu senaryoda, sık erişimli depolama ilk aşamalarda en iyisidir. Seyrek erişimli depolama, ara sıra erişim için en uygun olandır. Arşiv depolama, veriler bir aydan fazla yaşlandıktan sonra en iyi katman seçeneğidir. Yaşam döngüsü yönetimi ilkesi kurallarıyla verileri yaşına göre uygun depolama katmanına taşıyarak, ihtiyaçlarınız için en düşük maliyetli çözümü tasarlayabilirsiniz.
Yaşam döngüsü yönetimi ilkesi tanımı
Yaşam döngüsü yönetimi ilkesi, bir JSON belgesindeki kurallar koleksiyonudur. Aşağıdaki örnek JSON tam bir kural tanımını gösterir:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
İlke, aşağıdaki tabloda açıklandığı gibi bir kural koleksiyonudur:
| Parametre adı | Parametre türü | Notlar |
|---|---|---|
rules |
Kural nesneleri dizisi | İlkede en az bir kural gereklidir. Bir ilkede en fazla 100 kural tanımlayabilirsiniz. |
İlkedeki her kuralın aşağıdaki tabloda açıklanan çeşitli parametreleri vardır:
| Parametre adı | Parametre türü | Notlar | Zorunlu |
|---|---|---|---|
name |
String | Kural adı en fazla 256 alfasayısal karakter içerebilir. Kural adı büyük/küçük harfe duyarlıdır. İlke içinde benzersiz olmalıdır. | True |
enabled |
Boolean | Kuralın geçici olarak devre dışı bırakılmasına izin vermek için isteğe bağlı boole değeri. Ayarlanmadıysa varsayılan değer true olur. | False |
type |
Sabit listesi değeri | Geçerli geçerli tür: Lifecycle. |
True |
definition |
Yaşam döngüsü kuralını tanımlayan nesne | Her tanım bir filtre kümesinden ve bir eylem kümesinden oluşur. | True |
Yaşam döngüsü yönetimi kuralı tanımı
İlke içindeki her kural tanımı bir filtre kümesi ve bir eylem kümesi içerir. Filtre kümesi , kural eylemlerini kapsayıcı veya nesne adları içindeki belirli bir nesne kümesiyle sınırlar. Eylem kümesi katman veya silme eylemlerini filtrelenmiş nesne kümesine uygular.
Örnek kural
Aşağıdaki örnek kural, içinde sample-container bulunan ve ile blob1başlayan nesnelerde eylemleri çalıştırmak için hesabı filtreler.
- Son değişikliğin ardından 30 gün sonra seyrek erişim katmanına katman blobu
- Katman blobu son değişiklikden 90 gün sonra arşiv katmanına
- Son değişiklik sonrasında blobu 2.555 gün (yedi yıl) silme
- Oluşturma işleminden 90 gün sonra önceki sürümleri silme
{
"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"
]
}
}
}
]
}
Not
Yaşam döngüsü yönetim ilkesindeki baseBlob öğesi, blobun geçerli sürümüne başvurur. version öğesi önceki bir sürüme başvurur.
Kural filtreleri
Filtreler, kural eylemlerini depolama hesabındaki blobların bir alt kümesiyle sınırlar. Birden fazla filtre tanımlanmışsa, mantıksal AND bir tüm filtrelerde çalışır. Hangi blobların dahilleneceğini belirtmek için filtre kullanabilirsiniz. Filtre, dışlanması gereken blobları belirtmek için hiçbir araç sağlamaz.
Filtreler şunlardır:
| Filtre adı | Filtre türü | Notlar | Gerekli |
|---|---|---|---|
| blobTypes | Önceden tanımlanmış sabit listesi değerleri dizisi. | Geçerli sürüm ve appendBlob'yi desteklerblockBlob. yalnızca Delete eylemi için appendBlobdesteklenir; Katman Ayarlama desteklenmez. |
Yes |
| prefixMatch | Ön eklerin eşleştirileceği dize dizisi. Her kural en fazla 10 büyük/küçük harfe duyarlı ön ek tanımlayabilir. Ön ek dizesi bir kapsayıcı adıyla başlamalıdır. Örneğin, altındaki https://myaccount.blob.core.windows.net/sample-container/blob1/...tüm blobları eşleştirmek istiyorsanız prefixMatch değerini olarak sample-container/blob1belirtin. Bu filtre, adları blob1 ile başlayan örnek kapsayıcıdaki tüm bloblarla eşleşecektir.. |
prefixMatch tanımlamazsanız, kural depolama hesabındaki tüm bloblara uygulanır. Ön ek dizeleri joker karakter eşleştirmeyi desteklemez. ve gibi * ? karakterler dize değişmez değerleri olarak değerlendirilir. |
Hayır |
| blobIndexMatch | Blob dizin etiketi anahtarından ve eşleştirilecek değer koşullarından oluşan sözlük değerleri dizisi. Her kural en fazla 10 blob dizini etiketi koşulu tanımlayabilir. Örneğin, bir kural için altındaki https://myaccount.blob.core.windows.net/ tüm blobları ile Project = Contoso eşleştirmek istiyorsanız, blobIndexMatch şeklindedir{"name": "Project","op": "==","value": "Contoso"}. |
blobIndexMatch tanımlamazsanız, kural depolama hesabındaki tüm bloblar için geçerlidir. | Hayır |
Blob dizini özelliği hakkında bilinen sorunlar ve sınırlamalarla birlikte daha fazla bilgi edinmek için bkz. Blob diziniyle Azure Blob Depolama verilerini yönetme ve bulma.
Kural eylemleri
Eylemler, çalıştırma koşulu karşılandığında filtrelenmiş bloblara uygulanır.
Yaşam döngüsü yönetimi geçerli sürümlerin, önceki sürümlerin ve blob anlık görüntülerinin katmanlanması ve silinmesini destekler. Her kural için en az bir eylem tanımlayın.
Not
Katmanlama, premium blok blob depolama hesabında henüz desteklenmiyor. Diğer tüm hesaplar için katmanlama işlemine yalnızca blok bloblarında izin verilir, ekleme ve sayfa blobları için izin verilmez.
| Eylem | Geçerli Sürüm | Anlık Görüntü | Önceki Sürümler |
|---|---|---|---|
| tierToCool | Için desteklenir blockBlob |
Desteklenir | Desteklenir |
| tierToCold | Için desteklenir blockBlob |
Desteklenir | Desteklenir |
| enableAutoTierToHotFromCool1 | Için desteklenir blockBlob |
Desteklenmez | Desteklenmez |
| tierToArchive4 | Için desteklenir blockBlob |
Desteklenir | Desteklenir |
| silme2,3 | ve için blockBlob desteklenir appendBlob |
Desteklenir | Desteklenir |
1 Eylem enableAutoTierToHotFromCool yalnızca çalıştırma koşuluyla daysAfterLastAccessTimeGreaterThan kullanıldığında kullanılabilir. Bu koşul bir sonraki tabloda açıklanmıştır.
2 Hiyerarşik ad alanı etkinleştirilmiş bir hesaba uygulandığında, silme eylemi boş dizinleri kaldırır. Dizin boş değilse, silme eylemi ilk yaşam döngüsü ilkesi yürütme döngüsü içindeki ilke koşullarına uyan nesneleri kaldırır. Bu eylem, ilke koşullarını da karşılayan boş bir dizinle sonuçlanırsa, bu dizin sonraki yürütme döngüsü içinde kaldırılır ve bu şekilde devam eder.
3 Yaşam döngüsü yönetimi ilkesi, blobla ilişkili önceki sürümler veya anlık görüntüler silinene kadar blobun geçerli sürümünü silmez. Depolama hesabınızdaki blobların önceki sürümleri veya anlık görüntüleri varsa, ilkenin bir parçası olarak silme eylemi belirtirken önceki sürümleri ve anlık görüntüleri eklemeniz gerekir.
4 Yalnızca LRS, GRS veya RA-GRS için yapılandırılmış depolama hesapları blobları arşiv katmanına taşımayı destekler. Arşiv katmanı ZRS, GZRS veya RA-GZRS hesapları için desteklenmez. Bu eylem, hesap için yapılandırılan yedekliliğe göre listelenir.
Not
Aynı blob üzerinde birden fazla eylem tanımlarsanız, yaşam döngüsü yönetimi bloba en düşük maliyetli eylemi uygular. Örneğin, eylem eyleminden delete daha tierToArchiveucuzdur. Eylem tierToArchive , eylemden tierToCooldaha ucuzdur.
Çalıştırma koşulları yaşa bağlıdır. Geçerli sürümler son değiştirme zamanını veya son erişim saatini, önceki sürümler sürüm oluşturma zamanını, blob anlık görüntüleri ise yaşı izlemek için anlık görüntü oluşturma süresini kullanır.
| Eylem çalıştırma koşulu | Koşul değeri | Açıklama |
|---|---|---|
| daysAfterModificationGreaterThan | Gün içindeki yaşı gösteren tamsayı değeri | Blobun geçerli sürümündeki eylemlerin koşulu |
| daysAfterCreationGreaterThan | Gün içindeki yaşı gösteren tamsayı değeri | Bir blobun veya blob anlık görüntüsünün geçerli sürümündeki veya önceki sürümündeki eylemlerin koşulu |
| daysAfterLastAccessTimeGreaterThan1 | Gün içindeki yaşı gösteren tamsayı değeri | Erişim izleme etkinleştirildiğinde blobun geçerli sürümünün koşulu |
| daysAfterLastTierChangeGreaterThan | Son blob katmanı değiştirme zamanından sonraki günlerin yaşını gösteren tamsayı değeri | Yeniden doldurulan blobların arşiv katmanına döndürülmeden önce sık, seyrek erişimli veya soğuk katmanlarda tutulacakları gün cinsinden minimum süre. Bu koşul yalnızca eylemler için tierToArchive geçerlidir. |
1 Son erişim zamanı izleme etkin değilse daysAfterLastAccessTimeGreaterThan, blobun özelliği yerine LastAccessTime yaşam döngüsü ilkesinin etkinleştirildiği tarihi kullanır. Bu tarih, özellik null bir değer olduğunda LastAccessTime da kullanılır. Son erişim zamanı izlemesini kullanma hakkında daha fazla bilgi için bkz . Verileri son erişim zamanına göre taşıma.
Yaşam döngüsü ilkesi çalıştırmaları
Bir yaşam döngüsü ilkesini yapılandırdığınızda veya düzenlediğinizde değişikliklerin geçerli olması ve ilk yürütmenin başlatılması 24 saat kadar sürebilir. İlke eylemlerinin tamamlanması için geçen süre, değerlendirilen ve çalıştırılan blob sayısına bağlıdır.
Bir ilkeyi devre dışı bırakırsanız, yeni ilke çalıştırmaları zamanlanmaz, ancak bir çalıştırma zaten devam ederse, bu çalıştırma tamamlanana kadar devam eder ve çalıştırmayı tamamlamak için gereken tüm eylemler için faturalandırılırsınız. Bkz. Bölgesel kullanılabilirlik ve fiyatlandırma.
Yaşam döngüsü ilkesi tamamlandı olayı
Yaşam döngüsü yönetimi ilkesi tarafından tanımlanan eylemler gerçekleştirildiğinde LifecyclePolicyCompleted olayı oluşturulur. İlke tanımına dahil edilen her eylem için bir özet bölümü görüntülenir. Aşağıdaki json, bir ilke için örnek LifecyclePolicyCompleted olayı gösterir. İlke tanımı , , tierToCooltierToColdve tierToArchive eylemlerini içerdiğindendelete, her biri için bir özet bölümü görüntülenir.
{
"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": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
Aşağıdaki tabloda olayın şeması LifecyclePolicyCompleted açıklanmaktadır.
| Alan | Tür | Açıklama |
|---|---|---|
| scheduleTime | Dize | Yaşam döngüsü ilkesinin zamanlandığı zaman |
| deleteSummary | vektör<bayt> | Silme işlemi için zamanlanan blobların sonuç özeti |
| tierToCoolSummary | vektör<bayt> | Katmandan seyrek erişimli işleme zamanlanan blobların sonuç özeti |
| tierToColdSummary | vektör<bayt> | Katmandan soğuğa işlem için zamanlanmış blobların sonuç özeti |
| tierToArchiveSummary | vektör<bayt> | Katmandan arşive işlem için zamanlanan blobların sonuç özeti |
Yaşam döngüsü ilkeleri örnekleri
Aşağıdaki örneklerde, yaşam döngüsü ilkesi kurallarıyla yaygın senaryoların nasıl ele alınıyor olduğu gösterilmektedir.
Eskiyen verileri daha serin bir katmana taşıma
Bu örnekte veya container2/blob2ön ekli blok bloblarının nasıl geçirilir sample-container/blob1 gösterilmektedir. İlke, 30 günden fazla süredir değiştirilmemiş blobları seyrek erişimli depolamaya ve 90 gün içinde değiştirilmeyen blobları arşiv katmanına geçirmektedir:
{
"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 }
}
}
}
}
]
}
Son erişim zamanı temelinde verileri taşıma
Blobunuzun en son ne zaman okunduğuna veya yazıldığından ve blob verilerinizin katmanlanması ve elde tutulmasını yönetmek için filtre olarak kaydını tutmak için son erişim süresi izlemeyi etkinleştirebilirsiniz. Son erişim zamanı izlemeyi etkinleştirmeyi öğrenmek için bkz . İsteğe bağlı olarak erişim süresi izlemeyi etkinleştirme.
Son erişim zamanı izleme etkinleştirildiğinde, blob okunduğunda veya yazıldığında adlı LastAccessTime blob özelliği güncelleştirilir. Blob Alma işlemi erişim işlemi olarak kabul edilir. Blob Özelliklerini Alma, Blob Meta Verilerini Alma ve Blob Etiketlerini Alma işlemleri erişim işlemleri değildir ve bu nedenle son erişim zamanını güncelleştirmez.
Son erişim zamanı izleme etkinleştirildiyse, yaşam döngüsü yönetimi daysAfterLastAccessTimeGreaterThan çalıştırma koşulunun karşılanıp karşılanmadığını belirlemek için kullanırLastAccessTime. Yaşam döngüsü yönetimi, aşağıdaki durumlarda değil LastAccessTime yaşam döngüsü ilkesinin etkinleştirildiği tarihi kullanır:
Blobun
LastAccessTimeözelliğinin değeri null değerdir.Not
Son
lastAccessedOnerişim zamanı izleme etkinleştirildikten sonra bir bloba erişilmemişse blobun özelliği null olur.Son erişim zamanı izleme etkin değil.
Okuma erişimi gecikmesi üzerindeki etkisini en aza indirmek için son 24 saatin yalnızca ilk okuması son erişim saatini güncelleştirir. Aynı 24 saatlik dönemdeki sonraki okumalar son erişim saatini güncelleştirmez. Okumalar arasında bir blob değiştirilirse, son erişim zamanı iki değerin daha yeni olmasıdır.
Aşağıdaki örnekte bloblar 30 gündür erişilmemişse seyrek erişimli depolama alanına taşınır. enableAutoTierToHotFromCool özelliği, seyrek erişimli olarak katmanlandıktan sonra yeniden erişilirse bloba seyrek erişimden sık erişime kadar otomatik olarak katmanlanıp katmanlanmayacağını gösteren bir Boole değeridir.
İpucu
Blob seyrek erişim katmanına taşınır ve 30 gün geçmeden otomatik olarak geri taşınırsa erken silme ücreti alınır. Özelliği ayarlamadan enablAutoTierToHotFromCool önce, beklenmeyen ücretleri azaltabilmek için verilerinizin erişim desenlerini analiz etmeye dikkat edin.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Alındıktan sonra verileri arşivle
Bazı veriler bulutta boşta kalır ve nadiren erişilir. Aşağıdaki yaşam döngüsü ilkesi, veri alındıktan kısa süre sonra arşivlenmek üzere yapılandırılır. Bu örnek, adlı archivecontainer kapsayıcıdaki blok bloblarını arşiv katmanına geçirmektedir. Geçiş, son değiştirme saatinden 0 gün sonra bloblar üzerinde hareket ederek gerçekleştirilir.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Not
Microsoft, daha fazla verimlilik için bloblarınızı doğrudan arşiv katmanına yüklemenizi önerir. Arşiv katmanını Blobu Yerleştir veya Blok Listesini Koy işlemindeki x-ms-access-tier üst bilgisinde belirtebilirsiniz. x-ms-access-tier üst bilgisi REST sürüm 2018-11-09 ve daha yeni veya en son blob depolama istemci kitaplıklarıyla desteklenir.
Yaşa göre verilerin süresinin dolması
Bazı verilerin süresi oluşturulduktan günler veya aylar sonra dolması beklenir. Bir yaşam döngüsü yönetim ilkesini, veri yaşına göre silerek verilerin süresinin dolmasına yönelik olarak yapılandırabilirsiniz. Aşağıdaki örnekte, son 365 gün içinde değiştirilmemiş tüm blok bloblarını silen bir ilke gösterilmektedir.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Blob dizini etiketleriyle verileri silme
Bazı verilerin süresi yalnızca silinmek üzere açıkça işaretlendiğinde sona ermelidir. Blob dizin anahtarı/değer öznitelikleriyle etiketlenmiş verilerin süresinin dolması için bir yaşam döngüsü yönetimi ilkesi yapılandırabilirsiniz. Aşağıdaki örnekte ile Project = Contosoetiketlenmiş tüm blok bloblarını silecek bir ilke gösterilmektedir. Blob dizini hakkında daha fazla bilgi edinmek için bkz. Blob diziniyle Azure Blob Depolama verilerini yönetme ve bulma.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Önceki sürümleri yönetme
Ömrü boyunca düzenli olarak değiştirilen ve erişilen veriler için, bir nesnenin önceki sürümlerini otomatik olarak korumak için blob depolama sürümü oluşturmayı etkinleştirebilirsiniz. Önceki sürümleri katman eklemek veya silmek için bir ilke oluşturabilirsiniz. Sürüm yaşı, sürüm oluşturma zamanı değerlendirilerek belirlenir. Bu ilke kuralı, kapsayıcı activedata içinde sürüm oluşturulduktan sonra 90 gün veya daha eski olan önceki sürümleri seyrek erişim katmanına taşır ve 365 gün veya daha eski olan önceki sürümleri siler.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Bölgesel kullanılabilirlik ve fiyatlandırma
Yaşam döngüsü yönetimi özelliği tüm Azure bölgelerinde kullanılabilir.
Yaşam döngüsü yönetimi ilkeleri ücretsizdir. Blob Katmanı API'sini Ayarla çağrıları için müşteriler standart işlem maliyetleri için faturalandırılır. Silme işlemleri ücretsizdir. Ancak, depolama için Microsoft Defender gibi diğer Azure hizmetleri ve yardımcı programları, bir yaşam döngüsü ilkesi aracılığıyla yönetilen işlemler için ücretlendirilebilir.
Blob'un son erişim zamanına yapılan her güncelleştirme, diğer işlemler kategorisi altında faturalandırılır. Her son erişim zamanı güncelleştirmesi, günde 1000 kez erişilmiş olsa bile nesne başına en fazla 24 saatte bir "başka bir işlem" olarak ücretlendirilir. Bu, okuma işlemleri ücretlerinden ayrıdır.
Fiyatlandırma hakkında daha fazla bilgi için bkz. Blok Blobu fiyatlandırması.
Bilinen sorunlar ve sınırlamalar
Katmanlama, premium blok blob depolama hesabında henüz desteklenmiyor. Diğer tüm hesaplar için katmanlama işlemine yalnızca blok bloblarında izin verilir, ekleme ve sayfa blobları için izin verilmez.
Yaşam döngüsü yönetimi ilkesinin tam olarak okunması veya yazılması gerekir. Kısmi güncelleştirmeler desteklenmez.
Her kuralın en çok 10 büyük/küçük harfe duyarlı ön eki ve en çok 10 blob dizini etiketi koşulu olabilir.
Yaşam döngüsü yönetimi ilkesi, şifreleme kapsamı kullanan bir blobun katmanını değiştiremez.
Yaşam döngüsü yönetimi ilkesinin silme eylemi sabit bir kapsayıcıdaki herhangi bir blobla çalışmaz. Sabit bir ilkeyle, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Daha fazla bilgi için bkz . İş açısından kritik blob verilerini sabit depolama ile depolama.
Sık sorulan sorular (SSS)
Bkz . Yaşam döngüsü yönetimi hakkında SSS.