Azure Blob 存储的访问层 - 热、冷和存档Access tiers for Azure Blob Storage - hot, cool, and archive

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 isn't available at the account level.
  • 可以在上传期间或上传后在 Blob 级别设置热层、冷层和存档层。Hot, cool, and archive tiers can be set at the blob level during upload or after upload.
  • 冷访问层中的数据可容许略低的可用性,但仍需类似于热数据的高持久性、检索延迟和吞吐量特征。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 based on 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.


本文中所述的功能现在可用于具有分层命名空间的帐户。The features described in this article are now available to accounts that have a hierarchical namespace. 若要查看限制,请参阅 Azure Data Lake Storage Gen2 中可用的 Blob 存储功能一文。To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

支持分层的存储帐户Storage accounts that support tiering

只有 Blob 存储和常规用途 v2 (GPv2) 帐户支持在热层、冷层和存档层之间将对象存储数据分层。Object storage data tiering between hot, cool, and archive is only supported in Blob Storage and General Purpose v2 (GPv2) accounts. 常规用途 v1 (GPv1) 帐户不支持分层。General Purpose v1 (GPv1) accounts don't support tiering. 客户可以通过 Azure 门户轻松将其现有的 GPv1 或 Blob 存储帐户转换为 GPv2 帐户。Customers can easily convert their existing GPv1 or Blob Storage accounts to GPv2 accounts through the Azure portal. GPv2 为 Blob、文件和队列提供新的定价与功能。GPv2 provides new pricing and features for blobs, files, and queues. 某些功能和价格折扣仅在 GPv2 帐户中提供。Some features and prices cuts are only offered in GPv2 accounts. 请在全面了解定价之后,评估是否使用 GPv2 帐户。Evaluate using GPv2 accounts after comprehensively reviewing pricing. 某些工作负荷的价格在 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 的指定默认访问层。This attribute allows you to specify the default access tier for any blob that doesn't have it explicit set at the object level. 对于已在对象级别设置该层的对象,不会应用帐户层。For objects with the tier set at the object level, the account tier won't apply. 存档层仅适用于对象级别。The archive tier can be applied only at the object level. 可以随时在这些访问层之间进行切换。You can switch between these access tiers at any time.

热访问层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. 但与热层和冷层相比,数据检索成本更高。But it has higher data retrieval costs compared to the hot and cool tiers. 存档层中的数据必须至少保留 180 天,否则需要支付提前删除费。Data must remain in the archive tier for at least 180 days or be subject to an early deletion charge. 存档层中的数据可能需要几个小时才能检索,具体取决于解除冻结的优先级。Data in the archive tier can take several hours to retrieve depending on the priority of the rehydration. 对于小型对象,优先级高的解除冻结可能会在 1 小时内从存档中检索到对象。For small objects, a high priority rehydrate may retrieve the object from archive in under 1 hour. 若要了解详细信息,请参阅从存档层解冻 Blob 数据See Rehydrate blob data from the archive tier to learn more.

如果 Blob 位于存档存储中,则 Blob 数据处于脱机状态,不能读取、覆盖或修改。While a blob is in archive storage, the blob data is offline and can't be read, overwritten, or modified. 若要在存档中读取或下载 Blob,必须首先将其解除冻结到联机层。To read or download a blob in archive, you must first rehydrate it to an online tier. 不能创建存档存储中 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, its properties, and metadata. 不允许设置或修改存档中的 Blob 元数据;对于存档中的 Blob,仅以下操作有效:GetBlobProperties、GetBlobMetadata、ListBlobs、SetBlobTier、CopyBlob 和 DeleteBlob。Setting or modifying the blob metadata while in archive is not allowed; For blobs in archive, the only valid operations are GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, CopyBlob, 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.
  • 需要长时间存储并且几乎不访问的合规性和存档数据。Compliance and archival data that needs to be stored for a long time and is hardly ever accessed.

帐户级分层Account-level tiering

所有三个访问层中的 Blob 可以在同一帐户中共存。Blobs in all three access tiers can coexist within the same account. 如果 Blob 没有显式分配的层,则会从帐户访问层设置推断相应的层。Any blob that doesn't have an explicitly assigned tier infers the tier from the account access tier setting. 如果访问层来自帐户,则你可以看到“推断的访问层”Blob 属性已设置为“true”,而“访问层”Blob 属性与帐户层匹配。 If the access tier comes from the account, you see the Access Tier Inferred blob property set to "true", and the 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 as Hot (inferred) or Cool (inferred).

更改帐户访问层适用于帐户中存储的未设置显式层的所有“推断访问层”对象。Changing the account access tier applies to all access tier inferred objects stored in the account that don't have an explicit tier set. 如果将帐户层从热切换为冷,则只按 GPv2 帐户中没有设置层的所有 Blob 的写入操作次数(以 10,000 次为单位)收费。If you toggle the account tier from hot to cool, you'll be charged for write operations (per 10,000) for all blobs without a set tier in GPv2 accounts only. 不会在 Blob 存储帐户中对此更改收费。There's no charge for this change in Blob Storage accounts. 如果在 Blob 存储或 GPv2 帐户中从冷切换为热,则会按读取操作次数(以 10,000 次为单位)和数据检索量(以 GB 为单位)收费。You'll 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 级别分层,就可以使用 Put BlobPut 块列表操作将数据上传到所选的访问层,并使用设置 Blob 层操作或生命周期管理功能在对象级别更改数据的层。Blob-level tiering allows you to upload data to the access tier of your choice using the Put Blob or Put Block List operations and change the tier of your data at the object level using the Set Blob Tier operation or Lifecycle management feature. 可以将数据上传到所需的访问层,然后在使用模式更改时轻松地在热、冷或存档层之间更改 Blob 访问层,不需在帐户之间移动数据。You can upload data to your required access tier then easily change the blob access tier among the hot, cool, or archive tiers as usage patterns change, without having to move data between accounts. 所有层更改请求会立即发生,热和冷之间的层更改是即时的。All tier change requests happen immediately and tier changes between hot and cool are instantaneous. 但是,从存档层中解除冻结 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 访问层,否则新创建的 blob 将继承被覆盖的 blob 的层的属性。When overwriting a blob in the hot or cool tier, the newly created blob inherits the tier of the blob that was overwritten unless the new blob access tier is explicitly set on creation. 如果 Blob 位于存档层中,则无法被覆盖,因此在这种情况下,不允许上传相同的 Blob。If a blob is in the archive tier, it can't be overwritten, so uploading the same blob isn't permitted in this scenario.


存档存储和 Blob 级别分层仅支持块 Blob。Archive storage and blob-level tiering only support block blobs.

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 层或使用 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. 若要移动数据,必须使用通过 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. 通过 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 上传或移动到热层、冷层或存档层时,系统会在层更改时立即按相应的费率收费。When a blob is uploaded or moved to the hot, cool, or archive tier, it is charged at the corresponding rate immediately upon tier change.

将 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. 也可能还会收取从池或存档层移出的任何 Blob 的早期删除费用。Early deletion charges for any blob moved out of the cool or archive tier may apply as well. 将数据从存档中解除冻结需要一段时间,并且数据会按存档价格计费,直到将数据联机还原并将 blob 层更改为热层或冷层为止。Rehydrating data from archive takes time and data will be charged archive prices until the data is restored online and blob tier changes to hot or cool. 下表总结了如何对层更改进行计费:The following table summarizes how tier changes are billed:

写入费用(操作 + 访问)Write Charges (Operation + Access) 读取费用(操作 + 访问)Read Charges (Operation + Access)
SetBlobTier 方向SetBlobTier Direction 热->冷hot->cool,

“冷”层和“存档”层提前删除Cool and archive early deletion

移到冷层(仅限 GPv2 帐户)中的 Blob 会有一个 30 天的冷层提前删除期限。Any blob that is moved into the cool tier (GPv2 accounts only) is subject to a cool early deletion period of 30 days. 移到存档层中的 Blob 会有一个 180 天的存档提前删除期限。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'll be charged an early deletion fee equivalent to 135 (180 minus 45) days of storing that blob in archive.

如果未发生访问层更改,可以使用 Blob 属性 Last-Modified 来计算提前删除费用。You may calculate the early deletion by using the blob property, Last-Modified, 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 performance 热存储层Hot tier 冷存储层Cool tier 存档存储层Archive tier
可用性Availability 99.9%99.9% 99.9%99.9% 99%99% OfflineOffline
(RA-GRS 读取)(RA-GRS reads)
空值N/A 99.99%99.99% 99.9%99.9% OfflineOffline
使用费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/A 空值N/A 不适用N/A 空值N/A
最短存储持续时间Minimum storage duration 空值N/A 空值N/A 30 天130 days1 180 天180 days
(距第一字节时间)(Time to first byte)
一位数的毫秒数Single-digit milliseconds 毫秒milliseconds 毫秒milliseconds 小时2hours2

1 GPv2 帐户冷层中的对象的最短保留期为 30 天。1 Objects in the cool tier on GPv2 accounts have a minimum retention duration of 30 days. Blob 存储帐户的冷层没有最短保留期。Blob Storage accounts don't have a minimum retention duration for the cool tier.

2 存档存储目前支持 2 种解冻优先级:“高”和“标准”,它们提供不同的检索延迟。2 Archive Storage currently supports 2 rehydrate priorities, High and Standard, that offers different retrieval latencies. 有关详细信息,请参阅从存档层解冻 Blob 数据For more information, see Rehydrate blob data from the archive tier.


Blob 存储帐户支持与常规用途 v2 存储帐户相同的性能和可伸缩性目标。Blob Storage accounts support the same performance and scalability targets as general-purpose v2 storage accounts. 有关详细信息,请参阅 Blob 存储可伸缩性和性能目标For more information, see Scalability and performance targets for Blob Storage.

快速入门方案Quickstart scenarios

本部分使用 Azure 门户和 PowerShell 演示以下方案:In this section, the following scenarios are demonstrated using the Azure portal and PowerShell:

  • 如何更改 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. 在 Azure 门户中,搜索并选择“所有资源”。In the Azure portal, search for and select All Resources.

  3. 选择存储帐户。Select your storage account.

  4. 在“设置”中,选择“配置”以查看和更改帐户配置 。In Settings, select Configuration to view and change the account configuration.

  5. 根据需求选择合适的访问层:将“访问层”设置为“冷”或“热”。Select the right access tier for your needs: Set the Access tier to either Cool or Hot.

  6. 单击顶部的“保存”。Click Save at the top.

在 Azure 门户中更改默认帐户层

更改 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. 在 Azure 门户中,搜索并选择“所有资源”。In the Azure portal, search for and select All Resources.

  3. 选择存储帐户。Select your storage account.

  4. 选择容器,然后选择 Blob。Select your container and then select your blob.

  5. 在“Blob 属性”中选择“更改层”。 In the Blob properties, select Change tier.

  6. 选择“热”、“冷”或“存档”访问层。 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.

  7. 选择底部的“保存”。Select Save at the bottom.

在 Azure 门户中更改 Blob 层

定价和计费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're charged a per-gigabyte data access charge for reads.
  • 事务成本:层越冷,每个层的按事务收费越高。Transaction costs: There's 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 don't have an explicit tier set. 有关更改单个 Blob 的访问层的信息,请参阅 Blob 级分层计费For information on changing the access tier for a single blob, 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.


如果要对数据分层,是应该使用 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 don't 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 级别分层允许在对象级别设置访问层,不管该帐户上的访问层设置如何。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 don't have an explicit tier set (for example, Hot (inferred) or Cool (inferred)). 将帐户层从热切换为冷只对 GPv2 帐户中没有设置层的所有 Blob 产生写入操作次数(以 10,000 次为单位)收费,而从冷切换为热则会对 Blob 存储和 GPv2 帐户中的所有 Blob 产生读取操作次数(以 10,000 次为单位)和数据检索量(以 GB 为单位)收费。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. 上传 blob 时,无论默认帐户层是哪个,都可以将所选访问层指定为热层、冷层或存档层。On blob upload, You specify the access tier of your choice to be hot, cool, or archive regardless of the default account tier. 使用此功能可以将数据直接写入存档层,从而从在 Blob 存储中创建数据的那一刻起就实现了节省成本。This functionality allows you to write data directly into the archive tier to realize cost-savings from the moment you create data in blob storage.

哪些区域提供了热、冷、存档访问层?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?

热层和冷层中的所有操作 100% 一致。All operations between hot and cool are 100% consistent. 所有有效的存档操作(包括 GetBlobProperties、GetBlobMetadata、ListBlobs、SetBlobTier 和 DeleteBlob)在热层和冷层中完全一致。All valid archive operations including GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, and DeleteBlob are 100% consistent with hot and cool. 在解冻之前,无法读取或修改存档层中的 Blob 数据;仅支持对存档中的 Blob 元数据执行读取操作。Blob data can't 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 and 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 数据See Rehydrate blob data from the archive tier to learn more.

设置 Blob 的层以后,何时开始按相应费率收费?After setting the tier of a blob, when will I start getting billed at the appropriate rate?

每个 blob 始终按其“访问层”属性指示的层收费。Each blob is always billed according to the tier indicated by the blob's Access Tier property. 为 blob 设置新的联机层后,“访问层”属性会立即为所有转换显示该新层。When you set a new online tier for a blob, the Access Tier property immediately reflects the new tier for all transitions. 但是,将 blob 从脱机存档层解除冻结到热层或冷层可能需要几个小时。However, rehydrating a blob from the offline archive tier to a hot or cool tier can take several hours. 在这种情况下,仍按存档层费率计费,直至解除冻结操作完成。解冻后“访问层”属性会反映该新层。In this case, you're billed at archive rates until rehydration is complete, at which point the Access Tier property reflects the new tier. 一旦解除冻结到联机层,就会按热层或冷层费率对该 blob 计费。Once rehydrated to the online tier, you're billed for that blob at the hot or cool rate.

如何确定在删除或移出冷层或存档层的 Blob 时是否会产生提前删除费?How do I determine if I'll incur an early deletion charge when deleting or moving a blob out of the cool or archive tier?

在删除或移出冷层(仅限 GPv2 帐户)或存档层的任何 Blob 时,如果相应的存储时间不足 30 天(冷层)和 180 天(存档层),则会产生按比例计费的早期删除费用。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. 可以选择在一个层中用完所有存储配额,也可以分散用于三个层。You can choose to use all of your limit in one tier or across all three tiers. 有关详细信息,请参阅标准存储帐户的可伸缩性和性能目标For more information, see Scalability and performance targets for standard storage accounts.

后续步骤Next steps

评估 GPv2 和 Blob 存储帐户中的热、冷和存档层Evaluate hot, cool, and archive in GPv2 and Blob Storage accounts