Rapid Cache

重要事項：Anywhere Cache 現已更名為 Rapid Cache。使用特定工具時，工具介面或表面可能仍會顯示「Anywhere Cache」名稱。

本頁介紹 Rapid Cache，這項功能可為 Cloud Storage 值區提供採用 SSD 的可用區讀取快取，讓您提高儲存資料的處理量並降低延遲。Rapid Cache 會根據您的需求，自動調整儲存空間容量和頻寬。

Rapid Cache 具有多項優點，有助於提升效能，並降低與讀取密集型工作負載相關的網路費用。

如要瞭解如何在 Rapid Cache 中建立及管理快取，請參閱「建立及管理快取」。

運作原理

使用 Rapid Cache，您可以在與工作負載相同的區域中建立快取。在可用區中建立快取後，系統會改用快取處理來自該可用區的資料讀取要求，而非 bucket。每個快取都會為與快取位於同一區域的用戶端提供服務。只有當與快取位於相同可用區的 VM 讀取資料時，資料才會從值區擷取到快取中。此外，如果設定寫入時擷取，資料寫入 bucket 時也會擷取。中繼資料不會快取，且物件中繼資料要求是由值區處理，而非快取。

Rapid Cache 是全代管服務，一律會傳回一致的資料。

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

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

快取頻寬上限為 100 Gbps，每儲存 1 TiB 的資料，頻寬上限就會增加 20 Gbps。如要提高起始頻寬或總頻寬上限，可以增加儲存在快取中的資料量、在區域中建立更多快取，或是聯絡技術客戶經理或 Google 代表。

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

在可用區中快取資料

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

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

只要可用區有容量，您就能在可用區中建立快取。 如果建立快取的容量不足，快速快取會持續嘗試建立快取，直到容量足夠或使用者取消建立程序為止。容量可能長時間無法使用。

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

地理區域		位置
	區域名稱	區域	雙區域	多區域	自訂雙區域
亞洲
	asia-east1-a	check		check	check
	asia-east1-b	check		check	check
	asia-east1-c	check		check	check
	asia-northeast1-a	check	check
	asia-northeast1-b	check	check
	asia-northeast1-c	check	check
	asia-south1-a	check
	asia-south1-b	check
	asia-south1-c	check
	asia-southeast1-a	check		check	check
	asia-southeast1-b	check		check	check
	asia-southeast1-c	check		check	check
歐洲
	europe-north1-a	check	check
	europe-north1-b	check	check
	europe-north1-c	check	check
	europe-west1-b	check	check	check	check
	europe-west1-c	check	check	check	check
	europe-west1-d	check	check	check	check
	europe-west4-a	check	check	check	check
	europe-west4-b	check	check	check	check
	europe-west4-c	check	check	check	check
	europe-west6-a	check	check
	europe-west6-b	check	check
美國
	us-central1-a	check	check	check	check
	us-central1-b	check	check	check	check
	us-central1-c	check	check	check	check
	us-central1-f	check	check	check	check
	us-central1-ai1a (AI 可用區)	check
	us-east1-b	check	check	check	check
	us-east1-c	check	check	check	check
	us-east1-d	check	check	check	check
	us-east4-a	check		check	check
	us-east4-b	check		check	check
	us-east4-c	check		check	check
	us-east5-a	check		check	check
	us-east5-b	check		check	check
	us-east5-c	check		check	check
	us-south1-a	check		check	check
	us-south1-b	check		check	check
	us-south1-c	check		check	check
	us-south1-ai1b (AI 可用區)	check
	us-west1-a	check		check	check
	us-west1-b	check		check	check
	us-west1-c	check		check	check
	us-west3-a	check
	us-west3-b	check
	us-west3-c	check
	us-west4-a	check		check	check
	us-west4-b	check		check	check
	us-west4-c	check		check	check

資料擷取

資料首次從 bucket 存取時，一律會擷取至快取。 第一次讀取時，系統會將其視為快取失敗，後續讀取則視為快取命中，加快資料讀取速度。您可以選擇設定快取，在寫入時擷取資料，避免發生初始快取失敗。這有助於還原查核點，或準備訓練模型的資料管道等用途。

將資料擷取至快取時，快速快取會將物件分割成較小的固定大小區塊。將物件分成多個區塊，可實現更精細的快取，特別是對於只存取特定部分的大型檔案。

區塊是 2 MB 的資料區塊。要求物件時，快速快取會找出涵蓋要求位元組範圍的 2 MB 區塊，並獨立管理這些區塊。

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

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

• 如果讀取要求是針對小於 2 MB 的物件 (例如 500 KB 的圖片)，系統會將整個物件擷取到快取中。

快取設定

設定快取時，您可以設定下列屬性：

存留時間 (TTL)

TTL 是指從上次讀取資料區塊到將其從快取剔除之間的時間長度上限。舉例來說，如果 TTL 設為 24 小時，最後一次讀取資料是在週一上午 11 點，且之後未再讀取，則資料區塊會在週二上午 11 點從快取中清除。您可以設定 24 小時到 7 天的存留時間。如未指定，TTL 預設為 24 小時。

寫入時擷取

在物件寫入時將資料擷取到快取中，可加快寫入後讀取工作負載的速度，例如建立檢查點，以及輸出訓練作業的資料準備作業。如果設定快取在寫入時擷取資料，資料上傳至 bucket 時，系統會將資料寫入快取。這種主動做法可避免初始快取未命中，讓工作負載在第一次讀取時，就能立即從快取命中獲益。

更新現有快取的擷取條件時，可以選擇啟用寫入時擷取功能。無法在初始快取建立期間設定。

效能注意事項

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

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

定價

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

控制成本

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

選取 bucket

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

選取可用區

您應只在工作負載可從快取獲益的可用區中建立快取。

存留時間設定

您應指定儲存資料所需的最低 TTL。您可以變更 TTL，不會造成服務中斷。預設值為 1 天。

停用快取

您可以停用快取，從服務中永久移除快取，並停止累積所有相關快取費用。

優點

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

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

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

• 降低擷取費用：從快取讀取資料時，系統不會收取 Nearline Storage、Coldline Storage 和 Archive Storage 值區的擷取費用。

• 讀取作業的費用較低：從 Rapid Cache 執行的讀取作業，費用比從 Standard Storage 的 bucket 執行的 B 級作業低。

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

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

如需定價詳細資料，請參閱「快速快取定價」。如要瞭解配額，請參閱「快速快取配額」。

何時應使用快速快取？

對於不常變更但經常讀取的資料，請使用 Rapid Cache 加快資料讀取速度，以利進行數據分析工作負載和 AI/機器學習模型訓練及載入作業。

假設您要跨多個 Google Kubernetes Engine 節點訓練 AI 模型，所有節點都會重複讀取儲存在 Cloud Storage 值區中的資料，且都在同一區域中執行。在工作負載執行的可用區中建立快取，即可取得額外頻寬，並減少讀取多區域 bucket 資料時產生的資料移轉費用，進而更有效率地執行規模較大的工作負載。

使用快速快取加速 BigQuery 的讀取作業

Rapid Cache 可用於處理 BigQuery 發出的物件讀取要求。使用 Rapid Cache，您就能加快應用程式的資料讀取速度，同時盡量提高成本效益。

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

Rapid Cache 建議工具

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

快取作業

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

建立快取

建立快取時，快取會進入 CREATING 狀態，並在開始運作時進入 RUNNING 狀態。建立快取作業最多可能需要 48 小時，之後作業就會逾時。

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

注意： 如果嘗試取消建立作業，伺服器會盡全力取消建立作業，但不保證一定會成功。

更新快取

您可以在 RUNNING 狀態下更新快取的 TTL 或擷取行為。快取更新期間，pending_update 欄位會評估為 true。pending_update 欄位評估結果為 true 時，快取就無法再次更新。

處於「建立中」或「已停用」狀態的快取無法更新。AnywhereCaches Update API 為非同步，且會傳回長時間執行的作業。

快取項目的存留時間更新完成後，系統會立即將新存留時間套用至快取中的現有和新資料。

取得快取

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

列出快取

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

停用快取

您可以停用快取，從值區的設定中永久移除快取。停用快取後，快取會進入「已停用」狀態。處於這種狀態時，您仍可從快取讀取現有資料，但無法將新資料擷取到快取中。

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

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

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

恢復快取

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

AnywhereCaches Resume API 是同步 API，會傳回 AnywhereCache 資源。

限制和規定

• 如要刪除 bucket，必須先刪除所有相關聯的快取。但使用 Google Cloud 控制台刪除 bucket 時，系統會一併刪除所有相關聯的快取。

• 執行快取建立、停用、繼續或更新作業時，請將作業速率限制為每秒最多一項作業。每秒執行多項作業可能會導致失敗。

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

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

• 您無法使用 BigQuery 讀取 Rapid Cache 建議工具產生的建議和深入分析資料。

排解暫時性資源短缺問題

下列各節說明發生暫時性資源短缺時如何排解問題。如果指定區域的 SSD 容量或服務容量不足，就無法建立快取、增加快取大小或提高快取頻寬上限。

無法建立新快取

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

如何排解問題：為避免快取作業中斷，您可以手動取消快取建立作業，然後在可能還有容量的另一個區域中建立新快取。如要監控或取消快取建立作業，請參閱使用長時間執行的作業。

無法增加快取大小

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

雖然 Rapid Cache 可視需求自動增加快取大小，但快取大小增加與否取決於 SSD 容量是否足夠。如果系統提出自動增加快取大小的要求時，SSD 容量不足，Rapid Cache 會持續提交要求，直到暫時性資源短缺結束，或不再需要增加快取大小為止。

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

• 快取頻寬上限較低、快取處理量較低、資料傳輸頻寬配額用量較高，以及可能影響其他指標
• 帳單費用可能會受到以下影響：
  • 快取擷取費用增加
  • 快取儲存費用降低
  • 快取資料移出費用降低
  • 減少快取資料傳輸作業費用
  • 多區域資料移轉費用增加
  • 使用 B 級作業導致費用增加

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

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

無法提高快取的頻寬上限

快取大小增加時，如果特定區域的輸送量服務資源不足，無法以每 TiB 20 Gbps 的速度擴充現有快取的快取頻寬上限，就可能會暫時發生快取頻寬上限不足的情況。快取頻寬不足時，Rapid Cache 不會允許快取頻寬上限以每 TiB 資料 20 Gbps 的速度擴充，但快取會繼續處理讀取要求。如要要求更多快取頻寬，請與客戶技術顧問或 Google 代表聯絡。如果可用的快取頻寬不足，您可能會發現儲存空間的資料輸出頻寬消耗量增加。

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

後續步驟

• 建立及管理快取。