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.
  • Cool針對儲存不常存取且至少儲存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 的已知問題一文。To review limitations, see the Known issues with 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. 封存層中的資料可能需要幾個小時的時間才能取得。Data in the archive tier can take several hours to retrieve. 資料必須保留在封存層中至少180天,或受限於提早刪除費用。Data must remain in the archive tier for at least 180 days or be subject to an early deletion charge.

當 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 and its properties. 針對封存中的 blob,唯一有效的作業是 GetBlobProperties、GetBlobMetadata、ListBlobs、SetBlobTier、CopyBlob 和 DeleteBlob。For blobs in archive, the only valid operations are GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, CopyBlob, and DeleteBlob. 若要深入瞭解,請參閱從封存層解除凍結 blob 資料See Rehydrate blob data from the archive tier to learn more.

封存存取層的使用案例範例包括: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 入口網站中,[推斷的存取層] 屬性會顯示為 [經常性存取 (推斷) ] 或 [非經常性 (推斷)]。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,支付寫入作業(每10000個)的費用。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 帳戶中從非經常性存取層切換至經常性存取,則會向您收取讀取作業(每10000)和資料抓取(每 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 的層級。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 上傳或移至經常性存取、非經常性存取或封存層時,會在階層變更時立即依對應的費率收費。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 移至較低層(封存->非經常性存取、封存 >經常性存取或 >非經常性存取)時,作業會以從來源層讀取的方式計費,其中適用來源階層的讀取作業(每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. 從封存解除凍結資料需要時間,而資料會以封存價格計費,直到資料在線上還原,以及 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,
熱 >封存,hot->archive,
非經常性 >封存cool->archive
封存->酷炫,archive->cool,
封存->經常性存取、archive->hot,
酷炫 >熱cool->hot

非經常性存取和封存提前刪除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 屬性來計算早期刪除。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
可用性Availability 99.9%99.9% 99.9%99.9% 99%99% 離線Offline
可用性Availability
(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
LatencyLatency
(距第一位元組時間)(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 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.

變更儲存體帳戶層

變更 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. 選取 [經常性存取 ]、[ Archive非經常性存取] 或 [封存] 存取層。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.

變更儲存體帳戶層

價格和計費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.

常見問題集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 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)). 將帳戶層從經常性存取切換至非經常性存取時,會產生所有 blob 的寫入作業(每10000),而不需要 GPv2 帳戶中的設定層,而從非經常性存取切換至經常性存取會產生 Blob 儲存體和 GPv2 帳戶中所有 blob 的讀取作業(每10000)和資料抓取(每 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 與經常性存取層中的 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 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 一律根據 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?

在 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. 您可以選擇在一層或所有三個層級中使用您的所有限制。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