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/秒的處理量,並縮短延遲時間,加快讀取速度。

  • 降低多區域資料移轉費用:與直接從多區域 bucket 讀取的資料相比,從快取讀取的資料會收取較低的資料移轉費用。

  • 降低擷取費用:從快取讀取資料時,系統不會收取 Nearline Storage、Coldline Storage 和 Archive Storage bucket 的擷取費用。

  • 讀取作業的費用較低:從 Rapid Cache 執行的讀取作業,費用比從 Standard 儲存空間 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 中的資料時產生的資料移轉費用,進而更有效率地執行大規模工作負載。

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

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 位於 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 擷取資料。系統將擷取的資料傳送給使用者的同時,也會將資料擷取到快取中。

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

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

以區塊形式擷取資料

將資料擷取至快取時,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 (預設值),系統會從直屬上層資源繼承寫入時擷取啟用設定,上層資源可以是上層受管理資料夾,也可以是包含受管理資料夾的儲存空間。
    • 如果快取未在政策對應中指定,系統會將其視為 ingestOnWrite 設定為 unspecified。

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

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

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

    • 行為:系統會為寫入 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 天之間的值 (含頭尾)。如未指定,TTL 預設為 24 小時。

快取作業

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

建立快取

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

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

更新快取

更新快取時,您可以設定快取的存留時間或資料擷取行為。你只能更新處於 RUNNING 狀態的快取。無法更新處於 「建立中」或「已停用」狀態的快取。

快取更新期間,pending_update 欄位會評估為 true。pending_update 欄位評估結果為 true 時, 快取無法再次更新。快取 TTL 更新完畢後,系統會立即將新 TTL 套用至快取中的現有和新資料。

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

取得快取

取得快取時,Rapid Cache 會傳回快取例項的狀態和設定。AnywhereCaches Get API 是同步的,會傳回 AnywhereCache 資源。

列出快取

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

停用快取

你可以停用快取,從儲存空間的設定中永久移除快取。停用快取後,快取會進入「已停用」狀態。在此狀態下,您仍可從快取讀取現有資料,但無法將新資料擷取到快取中。

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

快取遭到刪除前的一小時內,您可以恢復快取,藉此還原 DISABLED 狀態,此時快取會恢復為 RUNNING 狀態。

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

恢復快取

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

AnywhereCaches Resume API 是同步 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 服務完成增加快取大小為止。

    無論如何,您的資料仍會安全地儲存在來源值區中。如果資料因 TTL 到期以外的原因從快取中捨棄,Rapid Cache 服務會嘗試將資料重新擷取到快取中,這項作業不會產生任何費用,也不會對您造成影響。如果資料無法以透明方式重新擷取,或因 TTL 到期而遭到捨棄,Rapid Cache 服務會在首次讀取時重新擷取資料。

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

效能注意事項

  • 區塊未命中:如果要求涵蓋多個區塊,且部分區塊位於快取中,其他區塊則否,Rapid Cache 會從來源值區透明地擷取遺失的區塊。

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

定價

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

費用控管

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

選取 bucket

您應只為包含要快取資料的 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 的資料輸出頻寬用量增加。

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

後續步驟