Rapid Cache

本頁面說明 Rapid Cache,這項功能可為 Cloud Storage bucket 提供 SSD 支援的可用區讀取快取,提高儲存資料的處理量並降低延遲。Rapid Cache 提供儲存空間容量和頻寬,可根據需求自動調整資源配置。Rapid Cache 是全代管服務,可傳回一致的資料。

Rapid Cache 有助於提升讀取密集型工作負載的效能,並降低網路費用。詳情請參閱「福利」。

請參閱「建立及管理快取」,瞭解如何使用 Rapid Cache 建立及管理快取。

Rapid Cache 的運作方式

Rapid Cache 可讓您在工作負載所在的可用區建立快取。在可用區建立快取後,來自該可用區的資料讀取要求會由快取處理,而非 bucket。每個快取都會為與快取位於相同可用區的用戶端提供服務。

當 VM 讀取 bucket 中的資料時,資料會擷取至快取,前提是 VM 和快取位於相同可用區。如果設定寫入時擷取行為,資料寫入 bucket 時也會擷取至快取。

中繼資料不會快取。物件中繼資料的要求一律由值區處理,而非快取。

如要進一步瞭解資料如何擷取至快取,請參閱「資料擷取」。建立或更新快取時,您可以設定快取的存留時間 (TTL) 和寫入時擷取行為。

優點

使用 Rapid Cache 快取資料,可享有下列優點:

  • 加快資料存取速度:Rapid Cache 會將資料與運算資源放在同一個可用區,並完全由 SSD 支援。這項功能可讓工作負載達到高達 2.5 TB/s 的處理量,並縮短延遲時間,加快讀取速度。

  • 降低多區域資料移轉費用:相較於直接從多區域 bucket 讀取資料,從快取讀取資料可降低資料移轉費用。

  • 降低擷取費用:從快取讀取資料時,不需支付 Nearline Storage、Coldline Storage 和 Archive Storage 儲存空間 bucket 的擷取費用。

  • 降低讀取作業費用:透過 Rapid Cache 執行的讀取作業,費用低於透過 Standard Storage 儲存空間 bucket 執行的 B 類作業。

  • 自動調整快取大小:Rapid Cache 的動態 SSD 快取會根據用量自動調整,您不必指定快取大小。

  • 有效率地使用快取:您可以在現有 bucket 啟用 Rapid Cache,不必變更現有應用程式或 API。儲存在 Rapid Cache 的資料具有同步一致性。

如要瞭解定價詳情,請參閱「Rapid Cache 定價」。如要瞭解配額,請參閱「Rapid Cache 配額」。

何時該使用 Rapid Cache?

對於不常變更、但經常讀取的資料,使用 Rapid Cache 可加快讀取速度,提升數據分析工作負載、AI/機器學習模型訓練和載入作業的效率。

假設您在多個 Google Kubernetes Engine 節點上訓練 AI 模型,這些節點會重複讀取儲存在 Cloud Storage bucket 中的資料,並在同一個可用區中執行。在工作負載執行的可用區建立快取後,快取會提供額外頻寬,並協助您降低讀取多區域 bucket 資料的相關資料移轉費用,讓您更有效率地執行更大規模的工作負載。

自動調整快取大小和頻寬限制

Rapid Cache 提供暫時儲存空間容量和頻寬,可根據快取中儲存的資料量自動擴充或縮減。

快取頻寬限制從 100 Gbps 開始,並以每 1 TiB 儲存資料 20 Gbps 的速率擴充。如要提高起始頻寬或總頻寬限制,可以增加快取中儲存的資料量、在可用區中建立更多快取,或與客戶技術顧問或 Google 代表聯絡。

如要進一步瞭解 Rapid Cache 的大小和頻寬限制,請參閱「Cloud Storage 配額與限制」。

在可用區中快取資料

為 bucket 建立快取時,快取必須建立在 bucket 位置內的可用區。舉例來說,如果 bucket 位於 us-east1 區域,您可以在 us-east1-b 建立快取,但無法在 us-central1-c 建立。如果 bucket 位於 ASIA 雙區域,您可以在組成 asia-east1 和 asia-southeast1 區域的任何可用區中建立快取。

每個 bucket 在各可用區最多只能建立一個快取。舉例來說,如果 bucket 位於 us-east1 區域,您可以在 us-east1-b 建立快取,並在 us-east1-c 建立另一個快取。如果 bucket 位於涵蓋 us-central1 和 us-east1 的多區域,您可以在 us-central1-a 建立快取,並在 us-east1-b 建立另一個快取。

只要可用區有可用容量,您就能在該可用區建立快取。如果無法建立快取,Rapid Cache 會持續嘗試建立快取,直到有可用容量或使用者取消建立程序為止。容量可能長時間無法使用。

您可以在下列可用區使用 Rapid Cache。這些可用區域取決於 bucket 的位置類型。

亞洲

下表列出亞洲地理區域中,Rapid Cache 可用的可用區和位置類型。

區域名稱 區域 雙區域 多區域 自訂雙區域
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c

歐洲

下表列出歐洲地理區域中,Rapid Cache 可用的可用區和位置類型。

區域名稱 區域 雙區域 多區域 自訂雙區域
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west3-a
europe-west3-b
europe-west3-c
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a (AI 可用區)
europe-west6-a
europe-west6-b

美國

下表列出美國地理區域中,Rapid Cache 可用的可用區和位置類型。

區域名稱 區域 雙區域 多區域 自訂雙區域
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (AI 可用區)
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b (AI 可用區)
us-west1-a
us-west1-b
us-west1-c
us-west2-a
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

快取資料擷取

根據預設,資料會在首次要求後擷取至快取。

初始要求送達時,快取是空的,因此無法在快取中找到資料。這會導致初始快取失敗,系統會改為從備份 Cloud Storage bucket 擷取資料。系統將擷取的資料提供給使用者時,也會同時將資料擷取到快取中。

完成首次要求後,資料會保留在快取中,後續所有讀取作業都能直接從快取提供,成為高速快取命中。這項行為可大幅縮短讀取延遲時間,並加快資料擷取速度。擷取的資料會保留在快取中,直到存留時間到期,資料才會從快取中移除。

如要完全避免初始要求速度緩慢,除了在首次讀取後擷取資料外,您也可以將快取設定為在寫入時擷取資料。

以區塊形式擷取資料

將資料擷取至快取時,Rapid Cache 會將物件拆分為較小的固定大小區塊。將物件拆成區塊可進行更精細的快取,特別是只存取特定部分的大型檔案。

一個區塊是 2 MB 的資料。當系統要求物件時,Rapid Cache 會找出哪些 2 MB 區塊涵蓋要求的位元組範圍,並獨立管理這些區塊。

資料擷取行為會因擷取至快取的物件大小而異:

  • 如果讀取要求針對的是大於 2 MB 的物件,系統只會擷取包含要求位元組範圍的區塊。舉例來說,讀取 100 MB 檔案的前 1 MB 時,只會擷取前 2 MB 的區塊。

  • 如果讀取要求針對的是小於 2 MB 的物件 (例如 500 KB 的圖片),整個物件都會擷取至快取。

寫入時擷取資料

如果啟用快取,在寫入時擷取資料,資料寫入 bucket 時,就會擷取至快取。除了初始讀取後擷取資料的預設快取行為外,您也可以選擇啟用這項行為。

寫入時擷取功能可消除初始快取失敗,讓工作負載在首次讀取資料時,就能立即命中快取。在寫入時擷取資料,可加快寫入後讀取工作負載的速度,例如還原系統檢查點,或準備用於模型訓練的資料管道。

您可以在建立或更新快取時,啟用快取在寫入時擷取資料的功能。您可以設定快取,擷取寫入 bucket 的所有物件 (也稱為「bucket 層級寫入時擷取」),或選擇性擷取寫入指定代管資料夾下 bucket 的物件 (也稱為「前置字串層級寫入時擷取」)。

舉例來說,假設您啟用快取,對 bucket my-bucket 中名稱含有前置字串 red/ 的物件,執行前置字串層級的寫入時擷取。接著,您將三個物件上傳至 my-bucket:物件 red/my-dog.png、blue/my-cat.png 和 red/my-goldfish.png。因此,只有物件 red/my-dog.png 和 red/my-goldfish.png 上傳至 my-bucket 時,才會擷取至快取。

使用特定工具 (例如Cloud de Confiance 控制台) 設定前置字元層級的寫入時擷取功能時,如果您指定的前置字元不是現有代管資料夾的名稱,系統會自動為您建立新的代管資料夾。不過,使用 JSON API 時,您必須手動建立代管資料夾,並為每個快取可用區套用 ingestOnWrite 設定。如要瞭解如何使用各項工具啟用或停用寫入時擷取功能,請參閱「使用 Rapid Cache」一文。

如要瞭解如何在使用 JSON API 時,在 bucket 或前置字元層級啟用或停用寫入時擷取功能,請展開「瞭解如何啟用寫入時擷取功能」部分。本節資訊主要僅適用於 JSON API;其他工具 (例如Cloud de Confiance 控制台) 會模糊處理部分設定,以便啟用及管理寫入時擷取功能。

瞭解如何啟用寫入時擷取功能

本節說明如何使用 JSON API 設定,為寫入 bucket 的所有物件啟用寫入時擷取功能,或只為寫入 bucket 且位於代管資料夾前置字元下的特定物件啟用這項功能。

您可以透過兩項設定,控管快取是否在寫入時擷取值區中所有物件的資料,或只擷取前置字元下特定物件的資料:

  • 如要在 bucket 層級啟用寫入時擷取功能,請使用快取資源的 ingestOnWrite 欄位。欄位如下所示:

    {
    "zone": "us-east1-a",
    "ttl": "24h",
    "ingestOnWrite": true
    }
    • 如果設為 true,系統會為寫入 bucket 的所有物件啟用寫入時擷取功能。這會覆寫任何代管資料夾層級設定,依前置字串為特定物件啟用寫入時擷取功能。
    • 如果設為 false,系統會停用 bucket 範圍物件的寫入時擷取功能。這項設定可讓您透過代管資料夾設定,依前置字元為特定物件啟用寫入時擷取功能。
  • 如要在前置字串層級啟用寫入時擷取功能,請使用代管資料夾,代表以前置字串路徑結尾的斜線 (例如:my-prefix/)。啟用前置字串層級的寫入時擷取功能後,快取只會在物件名稱中含有前置字串時,選擇性擷取寫入時的物件。

    前置字串層級的寫入時擷取功能,是透過代管資料夾資源中 rapidCacheConfig.policies 對應的 ingestOnWrite 欄位控制。必須有快取執行個體,才能在 rapidCacheConfig.policies 對應中指定。

    代管資料夾的 rapidCacheConfig.policies 對應關係如下所示:

    "rapidCacheConfig": {
      "policies": {
        "us-east1-a": {
          "rapidCacheId": "us-east1-a",
          "ingestOnWrite": "unspecified"
        }
        "us-east1-b": {
          ...,
          ...
        }
      }
    }
    • policies 對應中指定的快取執行個體必須已存在,前置字元層級的寫入時擷取功能才能運作。舉例來說,如要在 policies 對應中指定 rapidCacheId: "us-east1-a",您必須先有可用區 us-east1-a 的快取。
    • 您可以在單一 API 呼叫中,更新 policies 對應中指定的多個快取執行個體。
    • 如果 ingestOnWrite 設為 enabled,系統會為寫入這個代管資料夾前置字元下 bucket 的所有物件,啟用寫入時擷取功能。只有在快取資源的 ingestOnWrite 欄位為 false 時,才能啟用前置字元層級的寫入時擷取功能。
    • 如果設為 unspecified (預設),寫入時擷取啟用狀態會從直接上層資源繼承,該資源可能是上層代管資料夾,也可能是包含代管資料夾本身的 bucket。
    • 凡是未在政策對應中指定的快取,系統都會視為其 ingestOnWrite 設定設為 unspecified。

以下摘要說明如何設定快取和代管資料夾資源,在 bucket 層級或前置字元層級啟用或停用寫入時擷取功能:

  • 啟用值區層級的寫入時擷取功能 (而非前置字串層級)

    • 設定:將快取資源的 ingestOnWrite 欄位設為 true。

    • 行為:系統會為寫入 bucket 的所有物件啟用寫入時擷取功能。這項 bucket 範圍設定會覆寫任何代管資料夾層級設定 (也就是說,系統會略過選擇性的前置字串層級設定)。

  • 啟用前置字串層級的寫入時擷取功能 (但非 bucket 層級)

    • 設定:

      1. 將快取資源的 ingestOnWrite 欄位設為 false。
      2. 在代管資料夾資源中,設定有效的 policies 對應關係 (非空值)。
      3. 將代管資料夾的 ingestOnWrite 欄位設為 enabled (如果子資料夾從已啟用的上層代管資料夾繼承 enabled,則設為 unspecified)。
    • 行為:只有在相符的代管資料夾前置字元下寫入的物件,才會在寫入時擷取。

  • 在上層與下層代管資料夾啟用前置字串層級的寫入時擷取功能

    如要為子代管資料夾啟用寫入時擷取功能,必須同時在上層代管資料夾啟用這項功能。

  • 同時停用 bucket 和前置字串的寫入時擷取功能

    • 設定:

      1. 將快取資源的 ingestOnWrite 欄位設為 false。
      2. 將所有代管資料夾的 ingestOnWrite 欄位設為 unspecified,確保上層代管資料夾的 ingestOnWrite 欄位不是 enabled。

        或者,您也可以不設定任何政策,只要將 policies 對應 null 留空,或完全省略 rapidCacheConfig 設定即可。

    • 行為:值區和所有前置字串的寫入時擷取功能都會停用。

在上層代管資料夾啟用前置字串層級的寫入時擷取功能後,該資料夾下所有巢狀子代管資料夾也會啟用這項功能。如要進一步瞭解資源如何沿用寫入時擷取功能的啟用和停用狀態,請展開「寫入時擷取功能的沿用機制」一節。

寫入時擷取繼承機制的運作方式

如果代管資料夾未明確啟用寫入時擷取功能 (代管資料夾的 ingestOnWrite 欄位設為 unspecified),快取的寫入時擷取行為會沿用代管資料夾的父項資源,無論是來自 bucket 還是父項代管資料夾。

在前置字元層級使用寫入時擷取功能時,您在上層代管資料夾設定的寫入時擷取設定,會由所有子代管資料夾沿用。

我們舉以下情境為例:

  • 您有一個代管資料夾 a/,其父項資源為 bucket my-bucket。
  • 您有一個代管資料夾 a/b/,其父項資源是 my-bucket 中的代管資料夾 a/。

寫入名為 a/b/info.txt 的物件時,Rapid Cache 會由上而下評估設定階層:

  1. 檢查直接代管資料夾:如果 a/b/ 設為 enabled,則在 a/b/ 下寫入的物件會啟用前置字串層級的寫入時擷取功能。如果 a/b/ 設為 unspecified,Rapid Cache 會檢查直接上層資源,也就是代管資料夾 a/。
  2. 檢查上層代管資料夾:如果 a/ 設為 enabled,則 a/ 和 a/b/ 會啟用前置字串層級的寫入時擷取功能。如果 a/ 設為 unspecified,Rapid Cache 會檢查父項 bucket。
  3. 檢查 bucket 的快取層級 ingestOnWrite 設定:如果快取的 ingestOnWrite 欄位設為 true,則 bucket 層級的寫入時擷取功能會啟用,並覆寫任何已設定前置字元層級寫入時擷取功能的代管資料夾。如果快取的 ingestOnWrite 欄位為 false,且父項和子項代管資料夾的 ingestOnWrite 欄位皆為 unspecified,則 bucket 中位於父項和子項代管資料夾下的物件會停用寫入時擷取功能。在這種情況下,如果 bucket 中沒有其他已設定寫入時擷取的受管理資料夾,則 bucket 中所有物件的寫入時擷取功能都會停用。

存留時間 (TTL)

快取的存留時間 (TTL) 決定資料在快取中保留多久後會遭到剔除。TTL 是指資料從最後一次讀取後,保留在快取中的時間長度。舉例來說,如果 TTL 設為 24 小時,最後一次讀取時間為週一上午 11 點,且之後沒有再讀取,則該資料區塊會在週二上午 11 點從快取中移除。

您可以在建立或更新快取時,設定快取的存留時間。快取的存留時間可設為 24 小時至 7 天 (含) 之間的值。如未指定,存留時間預設為 24 小時。

快取作業

本節說明可對 Rapid Cache 快取執行的操作。有些作業是非同步作業,會傳回長時間執行的作業,其他作業則是同步作業,會立即完成並傳回 AnywhereCache 資源。

建立快取

建立快取時,您可以設定快取的位置、存留時間和資料擷取行為。快取建立時會進入「CREATING」狀態,並在開始執行時進入「RUNNING」狀態。快取建立作業最多可能需要 48 小時,之後作業就會逾時。

AnywhereCaches Create API 是非同步 API。建立作業會導致系統傳回長時間執行的作業。長時間執行的作業會提供建立作業的狀態,並可讓您在作業完成前取消作業。

更新快取

更新快取時,可以設定快取的存留時間或資料擷取行為。您只能更新處於「RUNNING」狀態的快取。無法更新處於「CREATING」或「DISABLED」狀態的快取。

快取更新期間,pending_update 欄位會評估為 true。pending_update 欄位評估為 true 時,無法再次更新快取。快取的存留時間更新完成後,新的存留時間會立即套用至快取中的現有和新資料。

AnywhereCaches Update API 為非同步,會傳回長時間執行的作業。

取得快取

取得快取時,Rapid Cache 會傳回快取執行個體的狀態和設定。AnywhereCaches Get API 是同步作業,會傳回 AnywhereCache 資源。

列出快取

您可以傳回特定 bucket 的相關聯快取清單。AnywhereCaches List API 是同步 API,支援分頁。

停用快取

您可以停用快取,從 bucket 設定中永久移除快取。停用快取後,快取會進入「DISABLED」狀態。在這個狀態下,您仍可從快取讀取現有資料,但無法將新資料擷取至快取。

停用快取後,您可以在 1 小時的寬限期內,透過恢復快取來取消停用。1 小時寬限期過後,快取就會刪除。刪除快取時,快取中的所有資料都會遭到剔除,且快取會從 bucket 中移除。

在快取刪除前的 1 小時內,您可以恢復快取,將狀態從「DISABLED」還原為「RUNNING」。

AnywhereCaches Disable API 是同步 API,會傳回 AnywhereCache 資源。

恢復快取

只要停用的快取仍在 1 小時寬限期內,您就可以恢復處於「停用」狀態的快取。1 小時寬限期過後,系統會盡可能繼續執行作業,因為快取隨時可能遭到刪除。快取恢復後,會進入 RUNNING 狀態。

AnywhereCaches Resume API 是同步作業,會傳回 AnywhereCache 資源。

Rapid Cache 建議工具

Rapid Cache 建議工具會分析資料用量和儲存空間,針對在 bucket 與可用區組合建立快取提供建議和洞察資訊。如需 Rapid Cache 建議工具的總覽資訊和使用說明,請參閱「Rapid Cache 建議工具」。

使用 Rapid Cache 加快 BigQuery 讀取速度

Rapid Cache 可用於提供 BigQuery 發出的物件讀取要求資料。使用 Rapid Cache,即可加快應用程式的資料讀取速度,同時提高成本效益。

BigQuery 是區域性服務,但其基礎運算資源有時可能會在可用區之間轉移,以平衡負載。最佳做法是在區域的所有可用區中,為 BigQuery 工作負載啟用 Rapid Cache,確保基礎運算資源變更可用區時,有可用的快取。如果未在可用區使用快取,就不會產生額外費用,因為 Rapid Cache 是按用量付費。請注意,如果工作負載的資源變更可用區,新可用區中的快取需要重新擷取資料,資料擷取費用可能會一次性增加。

快取資料加密

資料會以原始的伺服器端加密格式儲存在快取中,與 Cloud Storage 支援的加密選項相容。

限制和規定

  • 如要刪除 bucket,必須先刪除所有相關聯的快取。唯一的例外狀況是使用 Cloud de Confiance 控制台刪除 bucket,這會一併刪除所有相關聯的快取。

  • 執行快取建立、停用、恢復或更新作業時,請將作業頻率限制在每秒不超過一次。每秒執行超過一項作業可能會導致失敗。

  • Rapid Cache 並非耐用儲存空間,資料可能會在多種情況下從快取中移除。其中一種情況是快取會自動調整大小,確保工作負載有足夠的可用資源。在這種情況下,系統可能會根據最近最少使用 (LRU) 演算法,逐一移除部分資料,直到 Rapid Cache 服務完成增加快取大小為止。

    無論如何,資料都會安全地儲存在來源 bucket 中。如果資料因存留時間到期以外的原因從快取中刪除,Rapid Cache 服務會嘗試將資料重新擷取至快取,過程透明且不收取任何費用。如果資料無法透明地重新擷取,或因存留時間到期而遭到捨棄,Rapid Cache 服務會在首次讀取時重新擷取資料。

  • 無法使用 BigQuery 讀取 Rapid Cache 推薦工具產生的建議和洞察資料。

效能注意事項

  • 區塊未命中:如果要求涵蓋多個區塊,且部分區塊在快取中,其他區塊不在快取中,Rapid Cache 會以透明方式從來源 bucket 擷取缺少的區塊。

  • TTL 和淘汰:存留時間 (TTL) 和最近最少使用 (LRU) 淘汰政策也會對區塊執行。大型檔案中經常使用的部分可能會保留在快取中,不常使用的部分則會遭到移除。

定價

如要瞭解 Rapid Cache 的使用費用,請參閱「Rapid Cache 定價」。

費用控管

展開下列提示,瞭解如何盡可能降低執行快取的成本:

選取 bucket

請只為含有要快取資料的值區建立快取。

選取可用區

請只在工作負載可受益於快取的可用區建立快取。

存留時間設定

請指定在快取中儲存資料所需的最短存留時間。您可以變更存留時間,不會造成干擾。預設值為 1 天。

停用快取

您可以停用快取,從服務中永久移除快取,並停止產生所有相關快取費用。

排解暫時性資源短缺問題

下列各節說明如何排解暫時性資源短缺問題,也就是指定可用區中的 SSD 容量或服務容量不足,無法建立快取、增加快取大小或提高快取頻寬限制。

無法建立新快取

如果 SSD 容量不足或處理量服務資源不足,Rapid Cache 可能無法在特定可用區建立新的快取,導致資源暫時短缺。在這段時間範圍內,Rapid Cache 會嘗試建立新的快取,最長可達 48 小時。如果資源在 48 小時內可用,Rapid Cache 會成功完成快取建立要求。如果資源未在 48 小時內可用,快取建立要求就會失敗。

疑難排解方式:為避免快取作業中斷,您可以手動取消快取建立作業,並在可能有可用容量的其他可用區建立新快取。如要監控或取消快取建立作業,請參閱「使用長時間執行的作業」。

無法增加快取大小

如果快取所在可用區沒有足夠的 SSD 容量,Rapid Cache 可能無法增加快取大小。

雖然 Rapid Cache 會隨選自動增加快取大小,但快取大小增加與否取決於 SSD 容量可用性。如果提出自動增加快取大小的要求時,SSD 容量不足,Rapid Cache 會繼續提交要求,直到暫時資源短缺結束,或不再需要增加快取大小。

在資源暫時不足期間,系統會擷取新資料,並根據最近最少使用的原則,剔除快取中的現有資料。如果快取空間夠大,足以儲存大部分熱資料,快取指標幾乎不會受到影響。如果快取容量小於熱門資料量,則與不受資源短缺影響的快取相比,可能會更常剔除資料並重新擷取相同資料。如果快取的實際大小遠小於所需容量,可能會發生下列與資源短缺相關的行為:

  • 快取頻寬限制較低、快取處理量較低、資料移轉頻寬配額用量較高,且可能影響其他指標
  • 計費方式可能會受到下列影響:
    • 快取擷取費用增加
    • 快取儲存費用降低
    • 快取資料轉出費用降低
    • 快取資料轉出作業費用降低
    • 多區域資料移轉費用增加
    • B 類作業用量增加,導致費用提高

如要瞭解這些費用,請參閱「Rapid Cache 定價」。

如何疑難排解:為在資源暫時短缺期間獲得最佳結果,建議您監控快取,並視需求停用不必要的快取或工作負載。

無法提高快取的頻寬限制

增加快取大小時,如果特定可用區中提供資源的處理量不足,無法以每 TiB 20 Gbps 的速度擴充現有快取的頻寬限制,就可能暫時發生快取頻寬限制不足的情況。如果可用的快取頻寬不足,Rapid Cache 不會允許快取頻寬限制以每 TiB 資料 20 Gbps 的速度擴充,但快取會繼續提供讀取要求。如要申請更多快取頻寬,請與客戶技術顧問或 Google 代表聯絡。如果可用的快取頻寬不足,bucket 的資料輸出頻寬用量可能會增加。

如何疑難排解:為在暫時資源短缺期間獲得最佳結果,建議您監控快取,並根據需求停用不必要的快取或工作負載。

後續步驟