Veri yaşam döngüsünü otomatik olarak 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. Azure 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şimliden 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. Bu senaryoda yaşam döngüsü yönetim ilkesi nesneleri sık erişimliden seyrek erişimliye, sık erişimliden arşive veya seyrek erişimliden arşive taşıyabilir.
- Bir blobun geçerli sürümlerini, bir blobun önceki sürümlerini veya blob anlık görüntülerini yaşam döngülerinin sonunda silin.
- Depolama hesabı düzeyinde günde bir kez çalıştırılacak kuralları tanımlayın.
- Filtre olarak ad ön eklerini veya blob dizini etiketlerini kullanarak kapsayıcılara veya blobların bir alt kümesine kurallar uygulayın.
Yaşam döngüsünün ilk aşamalarında, ancak yalnızca iki hafta sonra verilere sık sık erişildiği bir senaryoyu 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 seçenektir. Arşiv depolama, veriler bir aydan uzun bir süre 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 ilkeleri genel amaçlı v2, premium blok blobu ve Blob Depolama hesaplarında blok blobları ve ekleme blobları için 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 alıcı ve pahalı olabilecek bir işlem olan ilk kez yeniden doldurulmadığı sürece okunamaz. Daha fazla bilgi için bkz. Arşiv katmanından blob yeniden doldurmaya genel bakış.
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ı 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 | Gerekli |
|---|---|---|---|
name |
Dize | 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. | Doğru |
enabled |
Boole | Kuralın geçici olarak devre dışı bırakılmasına izin veren isteğe bağlı boole değeri. Ayarlanmadıysa varsayılan değer true olur. | Yanlış |
type |
Sabit listesi değeri | Geçerli geçerli tür: Lifecycle. |
Doğru |
definition |
Yaşam döngüsü kuralını tanımlayan bir nesne | Her tanım bir filtre kümesinden ve bir eylem kümesinden oluşur. | Doğru |
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 nesnelerde eylemleri çalıştırmak ve ile blob1başlamak için hesabı filtreler.
- Son değişiklikden 30 gün sonra seyrek erişim katmanına katman blobu
- Katman blobu son değişiklik sonrasında 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
},
"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şvuruyor.
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 tüm filtrelerde çalıştırılır.
Filtreler aşağıdakileri içerir:
| 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 için silme desteklenir appendBlob, küme katmanı 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, bir kural için altındaki https://myaccount.blob.core.windows.net/sample-container/blob1/... tüm blobları eşleştirmek istiyorsanız prefixMatch değeridir sample-container/blob1. |
prefixMatch tanımlamazsanız, kural depolama hesabındaki tüm bloblar için geçerlidir. | 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.
| Eylem | Geçerli Sürüm | Anlık Görüntü | Önceki Sürümler |
|---|---|---|---|
| tierToCool | Için desteklenir blockBlob |
Desteklenir | Desteklenir |
| enableAutoTierToHotFromCool | Için desteklenir blockBlob |
Desteklenmez | Desteklenmez |
| tierToArchive | Için desteklenir blockBlob |
Desteklenir | Desteklenir |
| sil1 | ve için blockBlob desteklenir appendBlob |
Desteklenir | Desteklenir |
1 Hiyerarşik ad alanı etkinleştirilmiş bir hesaba uygulandığında, silme eylemi boş dizinleri kaldırır. Dizin boş değilse, silme eylemi ilk 24 saatlik döngü içinde 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 24 saatlik döngüde kaldırılır ve bu şekilde devam eder.
Not
Aynı blobda 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 olarak yaşı gösteren tamsayı değeri | Blobun geçerli sürümündeki eylemlerin koşulu |
| daysAfterCreationGreaterThan | Gün olarak yaşı gösteren tamsayı değeri | Blobun veya blob anlık görüntüsünün önceki bir sürümündeki eylemlerin koşulu |
| daysAfterLastAccessTimeGreaterThan | Gün olarak yaşı gösteren tamsayı değeri | Erişim izleme etkinleştirildiğinde blobun geçerli sürümünün koşulu |
Yaşam döngüsü ilkeleri örnekleri
Aşağıdaki örnekler, yaşam döngüsü ilkesi kurallarıyla yaygın senaryoların nasıl ele alınduğunu göstermektedir.
Eskiyen verileri daha serin bir katmana taşıma
Bu örnekte, veya container2/blob2ön ekine sahip blok bloblarının nasıl geçirilir sample-container/blob1 gösterilmektedir. İlke, 30 günden uzun 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ığında kaydını tutmak ve blob verilerinizin katmanlama ve saklamasını yönetmek için filtre olarak 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.
Okuma erişim 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 süre içindeki 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şilen bir bloba seyrek erişimliden sık erişimliye otomatik olarak katmanlanıp katmanlanmayacağını gösteren bir Boole değeridir.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Veri alındıktan sonra arşivle
Bazı veriler bulutta boşta kalır ve erişilse bile nadiren erişilir. Aşağıdaki yaşam döngüsü ilkesi, verileri alındıktan kısa süre sonra arşivleyebecek şekilde 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 zamanından 0 gün sonra bloblar üzerinde hareket edilerek 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 Listesine 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 verileri sona erdir
Bazı verilerin oluşturulduktan sonra gün 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 neden olacak şekilde 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ına yönelik bir yaşam döngüsü yönetim ilkesi yapılandırabilirsiniz. Aşağıdaki örnekte ile Project = Contosoetiketlenen tüm blok bloblarını silecek bir ilke gösterilmektedir. Blob dizini hakkında daha fazla bilgi edinmek için bkz. Blob dizini ile 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
Yaşam süresi 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 katmanlayabilir veya silebilirsiniz. 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 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 ö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"
]
}
}
}
]
}
Özellik desteği
Bu özellik için destek Data Lake Storage 2. Nesil, Ağ Dosya Sistemi (NFS) 3.0 protokolü veya SSH Dosya Aktarım Protokolü (SFTP) etkinleştirildiğinde etkilenebilir.
Bu özelliklerden herhangi birini etkinleştirdiyseniz bu özelliğin desteğini değerlendirmek için bkz. Azure Depolama hesaplarında Blob Depolama özelliği desteği.
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.
Fiyatlandırma hakkında daha fazla bilgi için bkz . Blok Blobu fiyatlandırması.
SSS
Yeni bir ilke oluşturdum. Eylemler neden hemen çalıştırılmaz?
Platform yaşam döngüsü ilkesini günde bir kez çalıştırır. İlkeyi yapılandırdıktan sonra bazı eylemlerin ilk kez çalıştırılması 24 saat kadar sürebilir.
Mevcut bir ilkeyi güncelleştirirsem eylemlerin çalıştırılması ne kadar sürer?
Güncelleştirilmiş ilkenin geçerlilik süresi 24 saat kadar sürer. İlke yürürlüğe girdikten sonra eylemlerin çalıştırılması 24 saate kadar sürebilir. Bu nedenle, ilke eylemlerinin tamamlanması 48 saate kadar sürebilir. Güncelleştirme bir kuralı devre dışı bırakmak veya silmek içinse ve enableAutoTierToHotFromCool kullanıldıysa, Sık Erişimli katmana otomatik katmanlama işlemi yine gerçekleşir. Örneğin, son erişime göre enableAutoTierToHotFromCool gibi bir kural ayarlayın. Kural devre dışı bırakılır/silinirse ve bir blob şu anda seyrek erişimdeyse ve sonra erişilirse, yaşam döngüsü yönetimi dışında erişime uygulandığından Sık Erişim'e geri taşınır. Daha sonra yaşam döngüsü yönetim kuralı devre dışı bırakıldığından/silindiğinden blob Sık Erişimli'den Seyrek Erişimli'ye taşınmaz. autoTierToHotFromCool'u engellemenin tek yolu, son erişim zamanı izlemeyi kapatmaktır.
Arşivlenmiş bir blobu el ile yeniden kullanıma aldım. Nasıl yaparım? geçici olarak Arşiv katmanına geri taşınmasını engelliyor?
Bir blob bir erişim katmanından diğerine taşındığında, son değişiklik zamanı değişmez. Arşivlenmiş bir blobu sık erişim katmanına el ile yeniden doldurmanız durumunda, yaşam döngüsü yönetim altyapısı tarafından bu blob arşiv katmanına geri taşınır. Yeniden arşivlenmesini önlemek için bu blobu etkileyen kuralı geçici olarak devre dışı bırakın. Blob arşiv katmanına güvenli bir şekilde geri taşınabilirken kuralı yeniden etkinleştirin. Sık erişimli veya seyrek erişim katmanında kalıcı olarak kalması gerekiyorsa blobu başka bir konuma da kopyalayabilirsiniz.
Blob ön eki eşleştirme dizesi ilkeyi beklenen bloblara uygulamadı
Bir ilkenin blob ön eki eşleştirme alanı, ilke eylemlerinin uygulanmasını istediğiniz blobları eşleştirmek için kullanılan tam veya kısmi bir blob yoludur. Yol, kapsayıcı adıyla başlamalıdır. Hiçbir ön ek eşleştirmesi belirtilmemişse, ilke depolama hesabındaki tüm bloblara uygulanır. Ön ek eşleştirme dizesinin biçimi şeklindedir [container name]/[blob name].
Ön ek eşleştirme dizesiyle ilgili aşağıdaki noktaları göz önünde bulundurun:
- container1/ gibi bir ön ek eşleştirme dizesi kapsayıcı1 adlı kapsayıcıdaki tüm bloblara uygulanır. Sonunda eğik çizgi karakteri (/) olmayan kapsayıcı1 ön eki eşleştirme dizesi, kapsayıcı adının kapsayıcı1 dizesiyle başladığı tüm kapsayıcılardaki tüm bloblara uygulanır. Ön ek container11, container1234, container1ab vb. adlı kapsayıcılarla eşleşir.
- Kapsayıcı1/sub1/ ön eki eşleştirme dizesi, kapsayıcıdaki container1 adlı ve sub1/ dizesiyle başlayan tüm bloblara uygulanır. Örneğin, ön ek container1/sub1/test.txtveya container1/sub1 /sub2/test.txtadlı bloblarla eşleşir.
- Yıldız karakteri
*, blob adında geçerli bir karakterdir. Ön ekte yıldız karakteri kullanılıyorsa, ön ek adlarında yıldız işareti olan bloblarla eşleşir. Yıldız işareti joker karakter olarak çalışmaz. - Soru işareti karakteri
?, blob adında geçerli bir karakterdir. Bir ön ekte soru işareti karakteri kullanılıyorsa, ön ek adlarında soru işareti olan bloblarla eşleşir. Soru işareti joker karakter olarak çalışmaz. - Ön ek eşleşmesi yalnızca pozitif (=) mantıksal karşılaştırmaları dikkate alır. Negatif (!=) mantıksal karşılaştırmalar yoksayılır.
İlkenin yürütüleceği zamanı belirlemenin bir yolu var mı?
Ne yazık ki, ilkenin yürütüleceği zamanı izlemenin bir yolu yoktur çünkü bu bir arka plan zamanlama işlemidir. Ancak platform ilkeyi günde bir kez çalıştırır.