Azure Blob 儲存體: 經常性、非經常性和封存存取層Azure Blob storage: hot, cool, and archive access tiers

Azure 儲存體提供不同的存取層, 可讓您以最符合成本效益的方式儲存 blob 物件資料。Azure storage offers different access tiers, which allow you to store blob object data in the most cost-effective manner. 可用的存取層包括:The available access tiers include:

  • 優化, 用於儲存經常存取的資料。Hot - Optimized for storing data that is accessed frequently.
  • 針對儲存不常存取且至少儲存30天的資料而優化。Cool - Optimized for storing data that is infrequently accessed and stored for at least 30 days.
  • 封存-針對儲存很少存取且至少儲存180天 (有彈性的延遲需求, 以小時為單位) 的資料進行封存。Archive - Optimized for storing data that is rarely accessed and stored for at least 180 days with flexible latency requirements (on the order of hours).

下列考慮適用于不同的存取層:The following considerations apply to the different access tiers:

  • 只有經常性存取和非經常性存取層可以在帳戶層級設定。Only the hot and cool access tiers can be set at the account level. 封存存取層無法在帳戶層級使用。The archive access tier is not available at the account level.
  • 經常性存取、非經常性存取和封存層可以在 blob 層級設定。Hot, cool, and archive tiers can be set at the blob level.
  • 非經常性存取層中的資料可容忍稍微較低的可用性, 但仍需要高持久性、抓取延遲和輸送量特性, 類似于熱資料。Data in the cool access tier can tolerate slightly lower availability, but still requires high durability, retrieval latency, and throughput characteristics similar to hot data. 對於非經常性存取資料, 相較于經常性資料, 可用性服務等級協定 (SLA) 和更高的存取成本是可接受的取捨, 以降低儲存成本。For cool data, a slightly lower availability service-level agreement (SLA) and higher access costs compared to hot data are acceptable trade-offs for lower storage costs.
  • 封存儲存體會在離線時儲存資料, 並提供最低的儲存成本, 以及最高的資料解除凍結和存取成本。Archive storage stores data offline and offers the lowest storage costs but also the highest data rehydrate and access costs.

儲存在雲端的資料迅速成長。Data stored in the cloud grows at an exponential pace. 若要為不斷擴充的儲存體需求來管理成本,根據存取頻率和計劃性保留期來組織您的資料,進而將成本最佳化很有幫助。To manage costs for your expanding storage needs, it's helpful to organize your data based on attributes like frequency-of-access and planned retention period to optimize costs. 儲存在雲端的資料在其存留期內的產生、處理和存取方式可能有所不同。Data stored in the cloud can be different in terms of how it's generated, processed, and accessed over its lifetime. 有些資料在其存留期內會積極地存取及修改。Some data is actively accessed and modified throughout its lifetime. 有些資料在其存留期的早期存取頻率很高,但存取頻率隨著資料老化而大幅下滑。Some data is accessed frequently early in its lifetime, with access dropping drastically as the data ages. 有些資料在雲端維持閒置狀態, 而且在儲存之後, 幾乎不常存取。Some data remains idle in the cloud and is rarely, if ever, accessed after it's stored.

這些資料存取案例中的每個都是從針對特定存取模式優化的不同存取層來獲益。Each of these data access scenarios benefits from a different access tier that is optimized for a particular access pattern. 使用經常性、非經常性和封存存取層時, Azure Blob 儲存體可透過不同的計價模式, 滿足這項差異化存取層的需求。With hot, cool, and archive access tiers, Azure Blob storage addresses this need for differentiated access tiers with separate pricing models.

注意

只有當您在 Data Lake Storage 上的多通訊協定存取公開預覽版中註冊時,本文所述的功能才可用於具有階層命名空間的帳戶。The features described in this article are available to accounts that have a hierarchical namespace only if you enroll in the public preview of multi-protocol access on Data Lake Storage. 若要檢閱限制,請參閱已知問題一文。To review limitations, see the known issues article.

支援階層處理的儲存體帳戶Storage accounts that support tiering

僅 Blob 儲存體和一般用途 v2 (GPv2) 帳戶支持對象儲存體資料分層處理至經常性存取、非經常性存取或封存。Object storage data tiering to hot, cool, or archive is only supported in Blob storage and General Purpose v2 (GPv2) accounts. 一般用途 v1 (GPv1) 帳戶不支援階層處理。General Purpose v1 (GPv1) accounts do not support tiering. 不過,客戶可以透過 Azure 入口網站中簡單的單鍵程序,輕鬆地將現有的 GPv1 或 Blob 儲存體帳戶轉換為 GPv2 帳戶。However, customers can easily convert their existing GPv1 or Blob storage accounts to GPv2 accounts through a simple one-click process in the Azure portal. GPv2 提供 blob、檔案和佇列的新定價結構, 以及存取各種新的儲存功能。GPv2 provides a new pricing structure for blobs, files, and queues, as well as, access to a variety of new storage features. 此外,接下來只會在 GPv2 帳戶中提供一些新功能與降價。Furthermore, going forward some new features and prices cuts will only be offered in GPv2 accounts. 因此, 客戶應該在全面審查新定價後, 評估使用 GPv2 帳戶, 因為某些工作負載在 GPv2 上可能會比 GPv1 更昂貴。Therefore, customers should evaluate using GPv2 accounts after comprehensively reviewing the new pricing as some workloads can be more expensive on GPv2 than GPv1. 如需詳細資訊,請參閱 Azure 儲存體帳戶概觀For more information, see Azure storage account overview.

Blob 儲存體和 GPv2 帳戶會在帳戶層級公開 [存取層] 屬性。Blob storage and GPv2 accounts expose the Access Tier attribute at the account level. 此屬性可讓您針對儲存體帳戶中未在物件層級設定明確層的任何 blob, 將預設存取層指定為經常性或非經常性。This attribute allows you to specify the default access tier as hot or cool for any blob in the storage account that doesn't have an explicit tier set at the object level. 對於已在物件層級設定儲存層的物件,不會套用此帳戶層。For objects with the tier set at the object level, the account tier will not apply. 封存層只能套用於物件層級。The archive tier can be applied only at the object level. 您可以隨時在這些存取層之間切換。You can switch between these access tiers at any time.

Premium 性能區塊 blob 儲存體Premium performance block blob storage

Premium 性能區塊 blob 儲存體可透過高效能硬體提供經常存取的資料。Premium performance block blob storage makes frequently accessed data available via high-performance hardware. 此效能層級中的資料會儲存在固態硬碟 (Ssd) 上, 並針對低和一致延遲進行優化。Data in this performance tier is stored on solid-state drives (SSDs), which are optimized for low and consistent latency. 相較于傳統硬碟, Ssd 提供更高的交易速率和輸送量。SSDs provide higher transactional rates and throughput compared to traditional hard drives.

Premium 效能區塊 blob 儲存體非常適合需要快速且一致回應時間的工作負載。Premium performance block blob storage is ideal for workloads that require fast and consistent response times. 最適合執行許多小型交易的工作負載, 例如, 捕捉遙測資料、訊息和資料轉換。It's best for workloads that perform many small transactions, such as capturing telemetry data, messaging, and data transformation. 涉及使用者的資料 (例如互動式影片編輯、靜態 web 內容和線上交易) 也是不錯的候選項目。Data that involves end users, such as interactive video editing, static web content, and online transactions are also good candidates.

高階效能區塊 blob 儲存體只能透過區塊 blob 儲存體帳戶類型使用, 而且目前不支援對經常性存取、非經常性存取或封存存取層進行分層。Premium performance block blob storage is available only via the block blob storage account type, and does not currently support tiering to hot, cool, or archive access tiers.

經常性存取層Hot access tier

經常性存取層的儲存成本高於非經常性和封存層, 但存取成本最低。The hot access tier has higher storage costs than cool and archive tiers, but the lowest access costs. 熱存取層的使用案例範例包括:Example usage scenarios for the hot access tier include:

  • 經常使用或預期存取 (讀取和寫入) 的資料。Data that's in active use or expected to be accessed (read from and written to) frequently.
  • 針對處理和最終遷移至非經常性存取層而暫存的資料。Data that's staged for processing and eventual migration to the cool access tier.

非經常性存取層Cool access tier

相較于經常性儲存體, 非經常性存取層的儲存成本較低, 且存取成本較高。The cool access tier has lower storage costs and higher access costs compared to hot storage. 這一層適用於將保留在非經常性存取層至少 30 天的資料。This tier is intended for data that will remain in the cool tier for at least 30 days. 非經常性存取層的使用案例範例包括:Example usage scenarios for the cool access tier include:

  • 短期備份和災害復原資料集。Short-term backup and disaster recovery datasets.
  • 不再經常檢視,但存取時應立即可用的較舊媒體內容。Older media content not viewed frequently anymore but is expected to be available immediately when accessed.
  • 當收集較多資料以供未來處理時,需要以符合成本效益方式預存的大型資料集。Large data sets that need to be stored cost effectively while more data is being gathered for future processing. (例如,科學資料、來自製造工廠的原始遙測資料等長期儲存)(For example, long-term storage of scientific data, raw telemetry data from a manufacturing facility)

封存存取層Archive access tier

相較于經常性存取層與非經常性存取層, 封存存取層具有最低的儲存成本和更高的資料提取成本。The archive access tier has the lowest storage cost and higher data retrieval costs compared to hot and cool tiers. 這一層適用於可承受擷取延遲數個小時,而且將保留在封存層中至少 180 天的資料。This tier is intended for data that can tolerate several hours of retrieval latency and will remain in the archive tier for at least 180 days.

當 blob 位於封存儲存體時, blob 資料會離線, 而且無法讀取、複製、覆寫或修改。While a blob is in archive storage, the blob data is offline and cannot be read, copied, overwritten, or modified. 您無法在封存儲存體中拍攝 blob 的快照集。You can't take snapshots of a blob in archive storage. 不過,Blob 中繼資料會保持連線且可以取得,讓您可列出 Blob 和其屬性。However, the blob metadata remains online and available, allowing you to list the blob and its properties. 針對封存中的 blob, 唯一有效的作業是 GetBlobProperties、GetBlobMetadata、ListBlobs、SetBlobTier 和 DeleteBlob。For blobs in archive, the only valid operations are GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, and DeleteBlob.

封存存取層的使用案例範例包括:Example usage scenarios for the archive access tier include:

  • 長期備份、次要備份和封存資料集Long-term backup, secondary backup, and archival datasets
  • 即使已處理成最終可用格式,但還是需要保存的原始資料。Original (raw) data that must be preserved, even after it has been processed into final usable form. (例如,轉碼成其他格式之後的原始媒體檔案)(For example, Raw media files after transcoding into other formats)
  • 需要儲存一段時間且幾乎不曾存取的相容性和封存資料。Compliance and archival data that needs to be stored for a long time and is hardly ever accessed. (例如, 安全攝影機的素材、醫療保健組織的舊 X 片//mri、音訊錄製, 以及針對金融服務的客戶電話記錄)(For example, security camera footage, old X-Rays/MRIs for healthcare organizations, audio recordings, and transcripts of customer calls for financial services)

Blob 解除凍結Blob rehydration

若要閱讀封存儲存體中的資料,您必須先將 blob 層變更為經常性存取或非經常性存取。To read data in archive storage, you must first change the tier of the blob to hot or cool. 此程式稱為解除凍結, 可能需要數小時才能完成。This process is known as rehydration and can take hours to complete. 我們建議大型 blob 大小以獲得最佳的解除凍結效能。We recommend large blob sizes for optimal rehydration performance. 同時解除凍結數個小型 blob 可能會增加額外時間。Rehydrating several small blobs concurrently may add additional time. 目前有兩個解除凍結優先順序: 高 (預覽) 和標準, 可以透過設定 Blob 層複製 blob作業上的選擇性 [ x 毫秒-解除凍結-優先順序] 屬性來設定。There are currently two rehydrate priorities, High (preview) and Standard, which can be set via the optional x-ms-rehydrate-priority property on a Set Blob Tier or Copy Blob operation.

  • 標準優先順序:解除凍結要求會依照收到的連續處理, 最多可能需要15小時。Standard priority: The rehydration request will be processed in the order it was received and may take up to 15 hours.
  • 高優先順序 (預覽) :解除凍結要求會優先于標準要求, 而且可能會在1小時內完成。High priority (preview): The rehydration request will be prioritized over Standard requests and may finish in under 1 hour. 高優先順序可能需要超過1小時的時間, 視 blob 大小和目前的需求而定。High priority may take longer than 1 hour, depending on blob size and current demand. 高優先順序的要求保證優先于標準優先順序要求。High priority requests are guaranteed to be prioritized over Standard priority requests.

注意

[標準優先權] 是 [封存] 的預設解除凍結選項。Standard priority is the default rehydration option for archive. 高優先順序是較快速的選項, 其成本高於標準的優先順序解除凍結, 而且通常保留供緊急資料還原情況使用。High priority is a faster option that will cost more than Standard priority rehydration and is usually reserved for use in emergency data restoration situations.

在解除凍結期間,您可以查看 [封存狀態] blob 屬性,以確認是儲存層否已變更。During rehydration, you may check the Archive Status blob property to confirm if the tier has changed. 視目的地層而定,狀態會顯示為 "rehydrate-pending-to-hot" 或 "rehydrate-pending-to-cool"。The status reads "rehydrate-pending-to-hot" or "rehydrate-pending-to-cool" depending on the destination tier. 完成時,系統會移除封存狀態屬性,而 [存取層] blob 屬性會反映新的經常性存取或非經常性存取層。Upon completion, the archive status property is removed, and the Access Tier blob property reflects the new hot or cool tier.

若要深入瞭解, 請參閱從封存層解除凍結 blob 資料See Rehydrate blob data from the archive tier to learn more.

帳戶層級的階層處理Account-level tiering

這三個存取層中的 blob 可以並存于相同的帳戶內。Blobs in all three access tiers can coexist within the same account. 若 blob 未明確指派任何階層,則系統會從帳戶存取層的設定加以推斷。Any blob that does not have an explicitly assigned tier infers the tier from the account access tier setting. 如果存取層是從帳戶推斷而來,您會看到 [推斷的存取層] blob 屬性設定為 "true",而且 blob [存取層] blob 屬性符合帳戶層。If the access tier is inferred from the account, you see the Access Tier Inferred blob property set to "true", and the blob Access Tier blob property matches the account tier. 在 Azure 入口網站中, [推斷的存取層] 屬性會顯示為 [經常性存取 (推斷) ] 或 [非經常性 (推斷) ]。In the Azure portal, the access tier inferred property is displayed with the blob access tier as Hot (inferred) or Cool (inferred).

變更帳戶存取層會套用至未設定明確層的帳戶中儲存的所有_存取層推斷_物件。Changing the account access tier applies to all access tier inferred objects stored in the account that do not have an explicit tier set. 如果帳戶層從經常性存取切換至非經常性存取,您需針對在 GPv2 帳戶中未設定存取層的所有 blob 支付寫入作業費用 (每 10,000 個)。If you toggle the account tier from hot to cool, you will be charged for write operations (per 10,000) for all blobs without a set tier in GPv2 accounts only. 此變更在 Blob 儲存體帳戶中不收費。There is no charge for this change in Blob storage accounts. 如果您在 Blob 儲存體或 GPv2 帳戶中從非經常性存取層切換至經常性存取, 則會向您收取讀取作業 (每 10000) 和資料抓取 (每 GB) 的費用。You will be charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle from cool to hot in Blob storage or GPv2 accounts.

Blob 層級的階層處理Blob-level tiering

Blob 層級的階層處理可讓您使用稱為設定 Blob 層的單一作業,在物件層級變更您的資料層。Blob-level tiering allows you to change the tier of your data at the object level using a single operation called Set Blob Tier. 您可以隨著使用模式變更,在經常性存取、非經常性存取或封存層之間輕鬆地變更 blob 的存取層,而不必在帳戶之間移動資料。You can easily change the access tier of a blob among the hot, cool, or archive tiers as usage patterns change, without having to move data between accounts. 所有的存取層變更都會立即發生。All tier changes happen immediately. 但是,從封存解除凍結 Blob 可能需要數小時的時間。However, rehydrating a blob from archive can take several hours.

最後一個 blob 層變更的時間會透過 [存取層變更時間] blob 屬性公開。The time of the last blob tier change is exposed via the Access Tier Change Time blob property. 如果 blob 位於封存層中, 則無法覆寫, 因此在此情況下不允許上傳相同的 blob。If a blob is in the archive tier, it can't be overwritten, so uploading the same blob is not permitted in this scenario. 您可以覆寫經常性存取或非經常性存取層中的 blob, 在此情況下, 新的 blob 會繼承已覆寫的 blob 層。You can overwrite a blob in a hot or cool tier, in which case the new blob inherits the tier of the blob that was overwritten.

注意

封存儲存體與 Blob 層級階層處理只支援區塊 blob。Archive storage and blob-level tiering only support block blobs. 您目前也無法變更具有快照集之區塊 blob 的層級。You also cannot currently change the tier of a block blob that has snapshots.

Blob 生命週期管理Blob lifecycle management

Blob 儲存體生命週期管理提供豐富、以規則為基礎的原則, 可讓您將資料轉換到最佳存取層, 並在其生命週期結束時使資料過期。Blob Storage lifecycle management offers a rich, rule-based policy that you can use to transition your data to the best access tier and to expire data at the end of its lifecycle. 若要深入了解,請參閱管理 Azure Blob 儲存體生命週期See Manage the Azure Blob storage lifecycle to learn more.

注意

儲存在區塊 blob 儲存體帳戶 (Premium 效能) 中的資料目前無法使用設定 Blob 層或使用 Azure Blob 儲存體生命週期管理來分層至經常性存取、非經常性存取或封存。Data stored in a block blob storage account (Premium performance) cannot currently be tiered to hot, cool, or archive using Set Blob Tier or using Azure Blob Storage lifecycle management. 若要移動資料, 您必須使用Put Block FROM URL API或支援此 API 的 AzCopy 版本, 以同步方式將 blob 從區塊 blob 儲存體帳戶複製到不同帳戶中的經常性存取層。To move data, you must synchronously copy blobs from the block blob storage account to the hot access tier in a different account using the Put Block From URL API or a version of AzCopy that supports this API. Put Block From URL API 會同步複製伺服器上的資料,這表示只有將所有資料從原始伺服器位置移動到目標位置後,才會完成呼叫。The Put Block From URL API synchronously copies data on the server, meaning the call completes only once all the data is moved from the original server location to the destination location.

Blob 層級的階層處理計費Blob-level tiering billing

當 Blob 移至存取頻率較低的階層 (經常性存取 -> 非經常性存取、經常性存取 -> 封存,或非經常性存取 -> 封存) 時,此作業會在寫入目的地階層時計費,且適用目的地階層的寫入作業 (每 10,000 個) 和資料寫入 (每 GB) 費用。When a blob is moved to a cooler tier (hot->cool, hot->archive, or cool->archive), the operation is billed as a write operation to the destination tier, where the write operation (per 10,000) and data write (per GB) charges of the destination tier apply.

當 blob 移至較低層 (封存-> 非經常性存取、封存 > 經常性存取或 > 非經常性存取) 時, 作業會以從來源層讀取的方式計費, 其中適用來源階層的讀取作業 (每 10000) 和資料抓取 (每 GB) 費用。When a blob is moved to a warmer tier (archive->cool, archive->hot, or cool->hot), the operation is billed as a read from the source tier, where the read operation (per 10,000) and data retrieval (per GB) charges of the source tier apply. 可能也適用任何移出非經常性存取或封存層之 blob 的提早刪除費用。Early deletion charges for any blob moved out of the cool or archive tier may apply as well. 下表摘要說明層級變更的計費方式:The following table summarizes how tier changes are billed.

寫入費用 (作業 + 存取)Write Charges (Operation + Access) 讀取費用 (作業 + 存取)Read Charges (Operation + Access)
SetBlobTier 方向SetBlobTier Direction 經常性 > 很酷,hot->cool,
熱 > 封存,hot->archive,
非經常性 > 封存cool->archive
封存-> 酷炫,archive->cool,
封存-> 經常性存取、archive->hot,
酷炫 > 熱cool->hot

非經常性存取和封存提前刪除Cool and archive early deletion

除了每 GB、每月費用,任何移入非經常性存取層 (僅限 GPv2 帳戶) 的 blob 都受制於 30 天的非經常性存取提早刪除期間,而且任何移入封存層的 blob 都受制於 180 天的封存提早刪除期間。In addition to the per GB, per month charge, any blob that is moved into the cool tier (GPv2 accounts only) is subject to a cool early deletion period of 30 days, and any blob that is moved into the archive tier is subject to an archive early deletion period of 180 days. 此費用按比例計算。This charge is prorated. 例如,如果 blob 移至封存,然後在 45 天後遭到刪除或移至經常倖存取層,您需支付相當於在封存中儲存該 blob 135 (180 減去 45) 天的提早刪除費用。For example, if a blob is moved to archive and then deleted or moved to the hot tier after 45 days, you will be charged an early deletion fee equivalent to 135 (180 minus 45) days of storing that blob in archive.

如果沒有存取層變更, 您可以使用 [上次修改時間] blob 屬性來計算早期刪除。You may calculate the early deletion by using the blob property, Last-Modified, if there has been no access tier changes. 否則, 您可以藉由查看 blob 屬性:存取層-變更時間來使用上次修改存取層為非經常性或封存的時間。Otherwise you can use when the access tier was last modified to cool or archive by viewing the blob property: access-tier-change-time. 如需 Blob 屬性的詳細資訊,請參閱取得 Blob 屬性For more information on blob properties, see Get Blob Properties.

比較區塊 blob 儲存體選項Comparing block blob storage options

下表顯示高階效能區塊 blob 儲存體和經常性存取、非經常性存取和封存存取層的比較。The following table shows a comparison of premium performance block blob storage, and the hot, cool, and archive access tiers.

Premium 效能Premium performance 經常性存取層Hot tier 非經常性存取層Cool tier 封存層Archive tier
AvailabilityAvailability 99.9%99.9% 99.9%99.9% 99%99% 離線Offline
AvailabilityAvailability
(RA-GRS 讀取)(RA-GRS reads)
N/AN/A 99.99%99.99% 99.9%99.9% 離線Offline
使用費用Usage charges 儲存成本較高, 存取和交易成本較低Higher storage costs, lower access and transaction cost 儲存成本較高,存取和交易成本較低Higher storage costs, lower access, and transaction costs 儲存成本較低,存取和交易成本較高Lower storage costs, higher access, and transaction costs 儲存成本最低,存取和交易成本最高Lowest storage costs, highest access, and transaction costs
最小物件大小Minimum object size N/AN/A N/AN/A N/AN/A N/AN/A
最小儲存持續時間Minimum storage duration N/AN/A N/AN/A 30天130 days1 180 天180 days
延遲Latency
(距第一位元組時間)(Time to first byte)
單一位數的毫秒數Single-digit milliseconds 毫秒milliseconds 毫秒milliseconds 時數2hours2

在 GPv2 帳戶的非經常性存取層中, 有1個物件的保留期間至少為30天。1 Objects in the cool tier on GPv2 accounts have a minimum retention duration of 30 days. 非經常性存取層的 Blob 儲存體帳戶沒有最小保留期間。Blob storage accounts do not have an minimum retention duration for the cool tier.

2封存儲存體目前支援2個解除凍結優先順序 (高和標準), 以提供不同的抓取延遲。2 Archive Storage currently supports 2 rehydrate priorities, High and Standard, that offer different retrieval latencies. 如需詳細資訊, 請參閱Blob 解除凍結For more information, see Blob rehydration.

注意

Blob 儲存體帳戶支援與一般用途 v2 儲存體帳戶相同的效能和擴充性目標。Blob storage accounts support the same performance and scalability targets as general-purpose v2 storage accounts. 如需詳細資訊,請參閱 Azure 儲存體延展性和效能目標For more information, see Azure Storage Scalability and Performance Targets.

快速入門案例Quickstart scenarios

在這一節中,我們會使用 Azure 入口網站示範下列案例︰In this section, the following scenarios are demonstrated using the Azure portal:

  • 如何變更 GPv2 或 Blob 儲存體帳戶的預設帳戶存取層。How to change the default account access tier of a GPv2 or Blob storage account.
  • 如何在 GPv2 或 Blob 儲存體帳戶中變更 Blob 的存取層。How to change the tier of a blob in a GPv2 or Blob storage account.

變更 GPv2 或 Blob 儲存體帳戶的預設帳戶存取層Change the default account access tier of a GPv2 or Blob storage account

  1. 登入 Azure 入口網站Sign in to the Azure portal.

  2. 瀏覽至儲存體帳戶、選取 [所有資源],然後選取您的儲存體帳戶。To navigate to your storage account, select All Resources, then select your storage account.

  3. 在 [設定] 刀鋒視窗中按一下 [組態] ,以檢視和/或變更帳戶組態。In the Settings blade, click Configuration to view and/or change the account configuration.

  4. 依據您的需求選取正確的存取層:將 [存取層] 設定為 [非經常性存取] 或 [經常性存取]。Select the right access tier for your needs: Set the Access tier to either Cool or Hot.

  5. 按一下刀鋒視窗頂端的 [儲存] 。Click Save at the top of the blade.

變更 GPv2 或 Blob 儲存體帳戶中的 blob 層Change the tier of a blob in a GPv2 or Blob storage account

  1. 登入 Azure 入口網站Sign in to the Azure portal.

  2. 若要瀏覽至儲存體帳戶,請選取 [所有資源],選取您的儲存體帳戶,選取您的容器,然後選取您的 Blob。To navigate to your blob in your storage account, select All Resources, select your storage account, select your container, and then select your blob.

  3. 在 [ Blob 屬性] 分頁中, 選取 [變更層] 按鈕以開啟 [層] 分頁。In the Blob properties blade, select the Change tier button to open the tier blade.

  4. 選取 [經常性存取]、[非經常性存取] 或 [封存] 存取層。Select the Hot, Cool, or Archive access tier. 如果您的 blob 目前在封存中, 而您想要解除凍結至線上層, 您也可以選取 [標準] 或 [] 的解除凍結優先權。If your blob is currently in Archive and you want to rehydrate to an online tier, you may also select a Rehydrate Priority of Standard or High.

  5. 按一下刀鋒視窗底部的 [確定]。Click OK at the bottom of the blade.

價格和計費Pricing and billing

所有儲存體帳戶都會根據每個 blob 的層級, 使用區塊 blob 儲存體的定價模型。All storage accounts use a pricing model for Block blob storage based on the tier of each blob. 請注意下列計費考量:Keep in mind the following billing considerations:

  • 儲存成本:除了儲存的資料量以外, 儲存資料的成本會隨著存取層而有所不同。Storage costs: In addition to the amount of data stored, the cost of storing data varies depending on the access tier. 每 GB 的成本會隨著儲存層存取頻率降低而減少。The per-gigabyte cost decreases as the tier gets cooler.
  • 資料存取成本:資料存取費用會隨著儲存層存取頻率降低而增加。Data access costs: Data access charges increase as the tier gets cooler. 對於非經常性存取和封存存取層中的資料, 您需支付讀取的每 gb 資料存取費用。For data in the cool and archive access tier, you are charged a per-gigabyte data access charge for reads.
  • 交易成本:所有層都有每筆交易的費用,該費用會隨著儲存層存取頻率降低而增加。Transaction costs: There is a per-transaction charge for all tiers that increases as the tier gets cooler.
  • 異地複寫資料傳輸成本:此費用適用於已設定異地複寫的帳戶,包括 GRS 和 RA-GRS。Geo-Replication data transfer costs: This charge only applies to accounts with geo-replication configured, including GRS and RA-GRS. 異地複寫資料傳輸會產生每 GB 費用。Geo-replication data transfer incurs a per-gigabyte charge.
  • 輸出資料傳輸成本:輸出資料傳輸 (從 Azure 區域傳出的資料) 會產生每 GB 頻寬使用量費用,與一般用途的儲存體帳戶一致。Outbound data transfer costs: Outbound data transfers (data that is transferred out of an Azure region) incur billing for bandwidth usage on a per-gigabyte basis, consistent with general-purpose storage accounts.
  • 變更存取層:變更帳戶存取層會導致_存取層所推斷_的 blob 儲存在未設定明確層的帳戶中的階層變更費用。Changing the access tier: Changing the account access tier will result in tier change charges for access tier inferred blobs stored in the account that do not have an explicit tier set. 如需變更單一 blob 之存取層的相關資訊, 請參閱blob 層級的階層處理計費。For information on changing the access tier for a single blob, please refer to Blob-level tiering billing.

注意

如需有關區塊 blob 定價的詳細資訊, 請參閱Azure 儲存體定價頁面。For more information about pricing for Block blobs, see Azure Storage Pricing page. 如需輸出資料傳輸費用的詳細資訊,請參閱資料傳輸定價詳細資料頁面。For more information on outbound data transfer charges, see Data Transfers Pricing Details page.

常見問題集FAQ

如果我想要將我的資料進行階層處理,應使用 Blob 儲存體或 GPv2 帳戶?Should I use Blob storage or GPv2 accounts if I want to tier my data?

建議您 GPv2,而不要使用 Blob 儲存體帳戶進行階層處理。We recommend you use GPv2 instead of Blob storage accounts for tiering. GPv2 支援 Blob 儲存體帳戶支援的所有功能,以及其他許多功能。GPv2 support all the features that Blob storage accounts support plus a lot more. Blob 儲存體與 GPv2 之間的價格幾乎相同,但是 GPv2 帳戶將提供一些新功能和降價。Pricing between Blob storage and GPv2 is almost identical, but some new features and price cuts will only be available on GPv2 accounts. GPv1 帳戶不支援階層處理。GPv1 accounts do not support tiering.

GPv1 與 GPv2 帳戶之間的價格結構不同,客戶在決定使用 GPv2 帳戶之前,應該仔細評估兩者。Pricing structure between GPv1 and GPv2 accounts is different and customers should carefully evaluate both before deciding to use GPv2 accounts. 您可以透過簡單的單鍵程序,輕鬆地將現有的 Blob 儲存體或 GPv1 帳戶轉換為 GPv2。You can easily convert an existing Blob storage or GPv1 account to GPv2 through a simple one-click process. 如需詳細資訊,請參閱 Azure 儲存體帳戶概觀For more information, see Azure storage account overview.

我可以在同一個帳戶中, 儲存所有三個 (經常性存取、非經常性存取和封存) 存取層中的物件嗎?Can I store objects in all three (hot, cool, and archive) access tiers in the same account?

是的。Yes. 在帳戶層級設定的 [存取層] 屬性是套用至該帳戶中所有物件的預設帳戶層 (沒有明確設定的層級)。The Access Tier attribute set at the account level is the default account tier that applies to all objects in that account without an explicit set tier. 不過,blob 層級的階層處理功能可讓您在物件層級上設定存取層,而不管帳戶上設定的存取層為何。However, blob-level tiering allows you to set the access tier on at the object level regardless of what the access tier setting on the account is. 三個存取層 (經常性、非經常性或封存) 中的 blob 可能存在於相同的帳戶內。Blobs in any of the three access tiers (hot, cool, or archive) may exist within the same account.

我可以變更 Blob 或 GPv2 儲存體帳戶的預設存取層嗎?Can I change the default access tier of my Blob or GPv2 storage account?

是, 您可以在儲存體帳戶上設定 [存取層] 屬性, 以變更預設帳戶層級。Yes, you can change the default account tier by setting the Access tier attribute on the storage account. 變更帳戶層會套用至帳戶中儲存但未設定明確層的所有物件 (例如經常性存取 (推斷) 或非經常性存取 (推斷) )。Changing the account tier applies to all objects stored in the account that do not have an explicit tier set (for example, Hot (inferred) or Cool (inferred)). 將帳戶層從經常性存取切換至非經常性存取時, 會產生所有 blob 的寫入作業 (每10000個), 而不需要 GPv2 帳戶中的設定層, 而從非經常性存取切換至經常性存取會產生 Blob 儲存體中所有 blob 的讀取作業 (每 10000) 和資料抓取 (每 GB) 費用和 GPv2 帳戶。Toggling the account tier from hot to cool incurs write operations (per 10,000) for all blobs without a set tier in GPv2 accounts only and toggling from cool to hot incurs both read operations (per 10,000) and data retrieval (per GB) charges for all blobs in Blob storage and GPv2 accounts.

是否可以將我的預設帳戶存取層設定為封存?Can I set my default account access tier to archive?

資料分割No. 只有經常性存取和非經常性存取層可以設定為預設帳戶存取層。Only hot and cool access tiers may be set as the default account access tier. 封存只能設定於物件層級。Archive can only be set at the object level.

在哪些區域中可以使用經常性、非經常性和封存存取層?In which regions are the hot, cool, and archive access tiers available in?

經常性存取和非經常性存取層以及 blob 層級的階層處理在所有區域都有提供。The hot and cool access tiers along with blob-level tiering are available in all regions. 封存儲存體一開始只在精選區域中提供。Archive storage will initially only be available in select regions. 如需完整清單,請參閱 Azure 依區域提供的產品For a complete list, see Azure products available by region.

非經常性存取層中的 blob 與經常性存取層中的 blob 的行為有何不同?Do the blobs in the cool access tier behave differently than the ones in the hot access tier?

經常性存取層中的 blob 與 GPv1、GPv2 和 Blob 儲存體帳戶中的 blob 具有相同的延遲。Blobs in the hot access tier have the same latency as blobs in GPv1, GPv2, and Blob storage accounts. 非經常性存取層中的 blob 與 GPv1、GPv2 和 Blob 儲存體帳戶中的 blob 有類似的延遲 (以毫秒為單位)。Blobs in the cool access tier have a similar latency (in milliseconds) as blobs in GPv1, GPv2, and Blob storage accounts. 封存存取層中的 blob 在 GPv1、GPv2 和 Blob 儲存體帳戶中有數小時的延遲。Blobs in the archive access tier have several hours of latency in GPv1, GPv2, and Blob storage accounts.

非經常性存取層中的 blob 與儲存在經常性存取層中的 blob 有稍微較低的可用性服務等級 (SLA)。Blobs in the cool access tier have a slightly lower availability service level (SLA) than the blobs stored in the hot access tier. 如需詳細資訊,請參閱儲存體 SLAFor more information, see SLA for storage.

經常性存取、非經常性存取和封存層之間的作業是否相同?Are the operations among the hot, cool, and archive tiers the same?

經常性存取與非經常性存取之間的所有作業都完全一致。All operations between hot and cool are 100% consistent. 所有有效的封存作業 (包括 GetBlobProperties、GetBlobMetadata、ListBlobs、SetBlobTier 和 DeleteBlob) 都與經常性存取和非經常性存取 100% 一致。All valid archive operations including GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, and DeleteBlob are 100% consistent with hot and cool. 在封存層中, 無法讀取或修改 Blob 資料, 直到解除凍結;封存時僅支援 blob 中繼資料讀取作業。Blob data cannot be read or modified while in the archive tier until rehydrated; only blob metadata read operations are supported while in archive.

將 Blob 從封存層解凍至經常性存取或非經常性存取層時,我要如何知道解除凍結已完成?When rehydrating a blob from archive tier to the hot or cool tier, how will I know when rehydration is complete?

在解除凍結期間,您可以使用「取得 blob 屬性」作業來輪詢 [封存狀態] 屬性,以確認存取層變更何時完成。During rehydration, you may use the get blob properties operation to poll the Archive Status attribute to confirm when the tier change is complete. 視目的地層而定,狀態會顯示為 "rehydrate-pending-to-hot" 或 "rehydrate-pending-to-cool"。The status reads "rehydrate-pending-to-hot" or "rehydrate-pending-to-cool" depending on the destination tier. 完成時,系統會移除封存狀態屬性,而 [存取層] blob 屬性會反映新的經常性存取或非經常性存取層。Upon completion, the archive status property is removed, and the Access Tier blob property reflects the new hot or cool tier.

設定 blob 的存取層之後,何時會開始以適當的費率計費?After setting the tier of a blob, when will I start getting billed at the appropriate rate?

每個 Blob 一律根據 Blob [存取層] 屬性所指定的存取層計費。Each blob is always billed according to the tier indicated by the blob's Access Tier property. 當您為為 Blob 設定新存取層時,[存取層] 屬性會立即反映所有轉換的新存取層。When you set a new tier for a blob, the Access Tier property immediately reflects the new tier for all transitions. 不過,將封存層的 Blob 解除凍結至經常性存取或非經常性存取層可能需要數小時的時間。However, rehydrating a blob from the archive tier to a hot or cool tier can take several hours. 在此情況下,您會以封存費率計費,直到解除凍結完成為止,[存取層] 屬性會反映新的存取層。In this case, you are billed at archive rates until rehydration is complete, at which point the Access Tier property reflects the new tier. 屆時,您會以經常性存取或非經常性存取費率,為該 Blob 付費。At that point you are billed for that blob at the hot or cool rate.

如何判斷在刪除 blob 或將它移出非經常性存取或封存層時,我是否需支付提早刪除費用?How do I determine if I will incur an early deletion charge when deleting or moving a blob out of the cool or archive tier?

在 30 天前和 180 天前遭到刪除或移出非經常性存取 (僅限 GPv2 帳戶) 或封存層的任何 Blob,分別會產生按比例計算的提早刪除費用。Any blob that is deleted or moved out of the cool (GPv2 accounts only) or archive tier before 30 days and 180 days respectively will incur a prorated early deletion charge. 檢查 [存取層變更時間] Blob 屬性 (該屬性提供最後一次存取層變更的戳記),即可判斷 Blob 放在非經常性存取或封存層中的時間長度。You can determine how long a blob has been in the cool or archive tier by checking the Access Tier Change Time blob property, which provides a stamp of the last tier change. 如果 blob 的層級永遠不會變更, 您可以檢查上次修改的 blob 屬性。If the blob's tier was never changed, you can check the Last Modified blob property. 如需詳細資訊, 請參閱非經常性存取和封存提前刪除For more information, see Cool and archive early deletion.

哪些 Azure 工具和 SDK 支援 blob 層級的階層處理和封存儲存體?Which Azure tools and SDKs support blob-level tiering and archive storage?

Azure 入口網站、PowerShell 和 CLI 工具,以及 .NET、Java、Python 和 Node.js 用戶端程式庫全都支援 blob 層級的階層處理和封存儲存體。Azure portal, PowerShell, and CLI tools and .NET, Java, Python, and Node.js client libraries all support blob-level tiering and archive storage.

我可以在經常性存取、非經常性存取和封存層中儲存多少資料?How much data can I store in the hot, cool, and archive tiers?

資料儲存體與其他限制會設定于帳戶層級, 而不是每個存取層。Data storage along with other limits are set at the account level and not per access tier. 因此,您可以選擇在其中一層或在全部三個層中使用所有限制。Therefore, you can choose to use all of your limit in one tier or across all three tiers. 如需詳細資訊,請參閱 Azure 儲存體延展性和效能目標For more information, see Azure Storage scalability and performance targets.

後續步驟Next steps

評估 GPv2 和 Blob 儲存體帳戶中的經常性存取、非經常性存取和封存Evaluate hot, cool, and archive in GPv2 and Blob storage accounts

依照區域檢查經常性存取、非經常性存取和封存的可用性Check availability of hot, cool, and archive by region

管理 Azure Blob 儲存體生命週期Manage the Azure Blob storage lifecycle

瞭解如何從封存層解除凍結 blob 資料Learn about rehydrating blob data from the archive tier

啟用 Azure 儲存體計量以評估您目前的儲存體帳戶使用量Evaluate usage of your current storage accounts by enabling Azure Storage metrics

依照區域檢查 Blob 儲存體和 GPv2 帳戶中的經常性存取、非經常性存取和封存價格Check hot, cool, and archive pricing in Blob storage and GPv2 accounts by region

檢查資料傳輸價格Check data transfers pricing