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:

  • 存档访问层仅在 Blob 级别提供,在存储帐户级别不提供。The archive access tier is available only at the blob level and not at the storage account level.
  • 冷访问层中的数据可容许略低的可用性,但仍需要像热数据一样的高持续性和类似的访问时间以及吞吐量特征。Data in the cool access tier can tolerate slightly lower availability, but still requires high durability and similar time-to-access and throughput characteristics as 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 is offline and offers the lowest storage costs but also the highest access costs.
  • 在帐户级别只能设置热和冷访问层。Only the hot and cool access tiers can be set at the account level.
  • 可在对象级别设置热、冷和存档层。Hot, cool, and archive tiers can be set at the object level.

儲存在雲端的資料迅速成長。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.

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

在 Blob 存储或常规用途 v2 (GPv2) 帐户中,只能将对象存储数据分到热层、冷层或存档层。You may only tier your object storage data to hot, cool, or archive in Blob storage and General Purpose v2 (GPv2) accounts. 一般用途 v1 (GPv1) 帳戶不支援階層處理。General Purpose v1 (GPv1) accounts do not support tiering. 不过,可以轻松地将现有的 GPv1 或 Blob 存储帐户转换为 GPv2 帐户,只需在 Azure 门户中单击一下即可。However, you can easily convert existing GPv1 or Blob storage accounts to GPv2 accounts through a one-click process in the Azure portal. GPv2 为 Blob、文件和队列提供新的定价结构,可以访问各种其他的全新存储功能。GPv2 provides a new pricing structure for blobs, files, and queues, and access to a variety of other new storage features. 以后只对 GPv2 帐户提供某些新功能和价格折扣。Going forward, some new features and prices cuts will be offered only in GPv2 accounts. 因此,应使用 GPv2 帐户进行评估,但只应在查看所有服务的定价以后再使用此类帐户。Therefore, you should evaluate using GPv2 accounts but only use them after reviewing the pricing for all services. 某些工作负荷的价格在 GPv2 中可能比在 GPv1 中更高。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 的默认访问层指定为热层或冷层,前提是该 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.

Premium 效能區塊 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. 此程序稱為解除凍結,最多可能需要 15 小時才能完成。This process is known as rehydration and can take up to 15 hours to complete. 為了達到最佳效能,建議使用大型 Blob。Large blob sizes are recommended for optimal performance. 同時解除凍結數個小型 blob 可能會增加額外時間。Rehydrating several small blobs concurrently may add additional time.

在解除凍結期間,您可以查看 [封存狀態] 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 層級的階層處理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 可以在同一帐户中共存。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 门户中,推断属性的访问层与 Blob 访问层(例如,热(推断)或冷(推断))一起显示。In the Azure portal, the access tier inferred property is displayed with the blob access tier (for example, Hot (inferred) or Cool (inferred)).

注意

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

注意

區塊 blob 儲存體帳戶中儲存的資料目前無法經常性存取、 非經常性存取或封存使用分層設定 Blob 層或使用 Azure Blob 儲存體生命週期管理。Data stored in a block blob storage account cannot currently be tiered to hot, cool, or archive using Set Blob Tier or using Azure Blob Storage lifecycle management. 若要移動資料,您必須以同步方式複製 blob 的區塊 blob 儲存體帳戶中不同的帳戶,使用經常性存取層放置區塊從 URL API或版本的 AzCopy 支援此 API。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 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 層級的階層處理計費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 移到更暖的层(存档->冷、存档->热或冷->热)时,操作按从源层读取计费,具体说来就是按源层的读取操作次数(以 10,000 次为单位)和数据检索量(以 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. 下表摘要說明層級變更的計費方式: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

如果帳戶層從經常性存取切換至非經常性存取,您需針對在 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 帳戶從非經常性存取切換至經常性存取,您需支付讀取作業 (每 10,000 個) 和資料擷取 (每 GB) 費用。You will be charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle your Blob storage or GPv2 account from cool to hot. 可能也適用任何移出非經常性存取或封存層之 blob 的提早刪除費用。Early deletion charges for any blob moved out of the cool or archive tier may apply as well.

非經常性存取和封存提前刪除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 屬性 creation-time 來計算提前刪除。You may calculate the early deletion by using the blob property, creation-time, if there has been no access tier changes. 否则,可以通过查看 Blob 属性(即“access-tier-change-time”)来使用最后一次将访问层修改为“冷”或“存档”的时间。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
可用性Availability 99.9%99.9% 99.9%99.9% 99%99% N/AN/A
可用性Availability
(RA-GRS 讀取)(RA-GRS reads)
N/AN/A 99.99%99.99% 99.9%99.9% N/AN/A
使用費用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 天 (僅限 GPv2)30 days (GPv2 only) 180 天180 days
延遲Latency
(距第一位元組時間)(Time to first byte)
單一位數 (毫秒)Single-digit milliseconds 毫秒milliseconds 毫秒milliseconds < 15 小時< 15 hrs

注意

延展性和效能目標,請參閱儲存體帳戶的 Azure 儲存體延展性和效能目標For scalability and performance targets, see Azure Storage scalability and performance targets for storage accounts

快速入門案例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:请依次选择“所有资源”、存储帐户、容器、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 Access tier dropdown menu to select the Hot, Cool, or Archive access tier.

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

價格和計費Pricing and billing

所有儲存體帳戶會對以每個 Blob 層為基礎的 Blob 儲存體使用價格模型。All storage accounts use a pricing model for 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.
  • 更改访问层:将帐户访问层从“冷”更改为“热”会产生费用,费用等于读取存储帐户中存在的所有数据的费用。Changing the access tier: Changing the account access tier from cool to hot incurs a charge equal to reading all the data existing in the storage account. 不過,將帳戶存取層從經常性存取層變更為非經常性存取層,會產生相當於將所有資料寫入非經常性存取層的費用 (僅限 GPv2 帳戶)。However, changing the account access tier from hot to cool incurs a charge equal to writing all the data into the cool tier (GPv2 accounts only).

注意

如需 Blob 儲存體帳戶的定價詳細資訊,請參閱 Azure 儲存體定價頁面。For more information about pricing for Blob storage accounts, 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 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.

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

是的,可以通过设置存储帐户上的“访问层”属性来更改默认访问层。Yes, you can change the default access tier by setting the Access tier attribute on the storage account. 更改访问层适用于存储在帐户中的所有对象,前提是该帐户没有显式设置层。Changing the access tier applies to all objects stored in the account that do not have an explicit tier set. 将访问层从热切换为冷只对 GPv2 帐户中没有设置层的所有 Blob 产生写入操作次数(以 10,000 次为单位)收费,而从冷切换为热则会对 Blob 存储和 GPv2 帐户中的所有 Blob 产生读取操作次数(以 10,000 次为单位)和数据检索量(以 GB 为单位)收费。Toggling the access 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 行為與經常性存取層中的不同?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 具有的可用性服务级别 (SLA) 比存储在热访问层中的 Blob 略低。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?

是。Yes. 經常性存取與非經常性存取之間的所有作業都完全一致。All operations between hot and cool are 100% consistent. 經常性存取與非經常性存取的所有有效封存作業 (包括刪除、列出、取得 blob 屬性/中繼資料,以及設定 blob 層) 都完全一致。All valid archive operations including delete, list, get blob properties/metadata, and set blob tier are 100% consistent with hot and cool. 無法讀取或修改封存層中的 blob。A blob cannot be read or modified while in the archive tier.

將 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. 有关详细信息,请参阅冷层和存档层的早期删除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 Blob storage accounts

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

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

啟用 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