Azure Cosmos DB 整合式快取 - 概觀

適用於：NoSQL

Azure Cosmos DB 整合式快取是記憶體中的快取，可協助您在要求量成長時，確保可管控的成本與低延遲。 整合式快取很容易設定，而且您不需要花時間撰寫用於快取失效的自訂程式碼或管理後端基礎結構。 整合式快取會使用您的 Azure Cosmos DB 帳戶內的專用閘道。 佈建專用閘道時，您可以根據工作負載所需的核心數目和記憶體，選擇節點數目和節點大小。 每個專用閘道節點都有與其他閘道節點不同的整合式快取。

專用閘道內會自動設定整合式快取。 整合式快取有兩個部分：

• 點讀取的項目快取
• 查詢的查詢快取

整合式快取是具有最近最少使用 (LRU) 收回原則的讀取和寫入快取。 項目快取和查詢快取會在整合式快取內共用相同的容量，而 LRU 收回原則也同時適用兩者。 將會根據最近最少使用的時間，從快取收回資料，而不論它是否為點讀取或查詢。 每個節點內的快取資料取決於最近透過該特定節點寫入或讀取的資料。 即使某個節點上快取了某個項目或查詢，其他節點也不一定會快取相同的項目或查詢。

可從整合式快取獲益的工作負載

整合式快取的主要目標是要降低大量讀取工作負載的成本。 低延遲雖然很有幫助，但並不是整合式快取的主要優點，因為 Azure Cosmos DB 即使沒有快取也已經很快速。

命中整合式快取的點讀取和查詢其 RU 費用為 0。 快取命中的每個作業成本會比從後端資料庫讀取的成本更低。

符合下列特性的工作負載應該評估整合式快取是否將有助於降低成本：

• 大量讀取工作負載
• 大型項目上的許多重複點讀取
• 許多重複的高 RU 查詢
• 讀取的經常性存取層分割區索引鍵

預期節省量的最大因素是讀取本身重複的程度。 如果您的工作負載在一小段時間內一致地執行相同的點讀取或查詢，就是整合式快取的絕佳候選項目。 使用整合式快取進行重複讀取時，您只會在第一次讀取時使用 RU。 透過相同專用閘道節點 (在 MaxIntegratedCacheStaleness 視窗內且若資料尚未收回) 路由的後續讀取不會使用輸送量。

某些工作負載不應考慮使用整合式快取，包括：

• 大量寫入工作負載
• 很少重複的點讀取或查詢
• 讀取變更摘要的工作負載

項目快取

項目快取會用於點讀取 (索引鍵/值會根據項目識別碼和分割區索引鍵查閱)。

填入項目快取

• 新的寫入、更新和刪除會自動填入節點 (要求會透過其路由) 的項目快取中
• 如果項目來自點讀取要求，且其中項目尚未在節點 (要求會透過其路由) 的快取中 (快取遺漏)，則這些項目會新增至項目快取
• 讀取多個項目的要求，例如 ReadMany，以集合填入查詢快取，而不是將項目快取填入為個別項目
• 屬於交易式批次或在大量模式中的要求不會填入項目快取

項目快取失效和收回

因為每個節點都有獨立的快取，所以項目可能會在一個節點快取中失效或收回，但在另一個節點快取中不會如此。 指定節點快取中的項目會根據下列準則失效及收回：

• 項目更新或刪除
• 最近最少使用 (LRU)
• 快取保留時間 (換句話說，MaxIntegratedCacheStaleness)

查詢快取

查詢快取的用途是快取查詢。 查詢快取會將查詢轉換為索引鍵值查閱，其中的索引鍵是查詢文字，而值是查詢結果。 整合式快取沒有查詢引擎，只會儲存每個查詢的索引鍵值查閱。 查詢結果會儲存為集合，而且快取不會持續追蹤個別項目。 如果指定的項目出現在多個查詢的結果集中，則可以多次儲存在查詢快取中。 除非達到查詢的整合式快取過期上限，而且查詢是從後端資料庫進行處理，否則基礎項目的更新不會反映在查詢結果中。

填入查詢快取

• 如果用來路由查詢的節點上沒有該查詢的結果 (快取遺漏)，則查詢會傳送至後端。 執行查詢之後，快取會儲存該查詢的結果
• 具有相同形狀但影響結果的參數或要求選項不同的查詢 (例如，項目計數上限) 會儲存為自己的索引鍵/值組
• 讀取多個項目的要求，例如 ReadMany，會填入查詢快取。 ReadMany 結果會儲存為集合，且具有不同輸入的要求會儲存為自己的索引鍵/值組

查詢快取收回

查詢快取收回會以用來路由要求的節點為基礎。 查詢可能會在一個節點上收回或重新整理，但不會在其他節點上如此。

• 最近最少使用 (LRU)
• 快取保留時間 (換句話說，MaxIntegratedCacheStaleness)

使用查詢快取

使用查詢快取時您不需要特殊的程式碼，即使查詢有多個頁面結果亦然。 無論是命中整合式快取的查詢，還是在後端查詢引擎上執行的查詢，查詢分頁的最佳做法和程式碼都相同。

查詢快取會在適用的情況下自動快取查詢接續權杖。 如果您的查詢有多個頁面的結果，則儲存在整合式快取中的任何頁面都會有 0 的 RU 費用。 如果後續查詢結果頁面需要後端執行，則會有來自前一頁的接續權杖，因此可以避免重複先前的工作。

整合式快取一致性

整合式快取僅支援一致性為工作階段和最終的讀取要求。 如果某個讀取擁有一致的首碼、限定過期或強式一致性，則會略過整合式快取，並從後端提供。

為所有讀取設定工作階段或最終一致性最簡單的方式，就是在帳戶層級設定。 但是，如果您只想讓某些讀取具有特定一致性，您也可以在要求層級設定一致性。

工作階段一致性

工作階段一致性同時是單一區域及全域分散式 Azure Cosmos DB 帳戶最普遍使用的一致性層級。 搭配工作階段一致性時，單一用戶端工作階段可以讀取自己的寫入。 如果搭配工作階段一致性的任何讀取沒有相符的工作階段權杖，則會產生 RU 費用。 除非您明確傳遞有效的工作階段權杖，否則這會包括用戶端應用程式啟動或重新啟動時，指定項目或查詢的第一個要求。 使用整合式快取時，在執行寫入的工作階段外部的用戶端將會看到最終一致性。

MaxIntegratedCacheStaleness

MaxIntegratedCacheStaleness 是快取點讀取和查詢的最大可接受過期，不論選取的一致性為何。 MaxIntegratedCacheStaleness 可在要求層級設定。 例如，如果您將 MaxIntegratedCacheStaleness 設定為 2 小時，則如果資料少於 2 小時，您的要求將只會傳回快取的資料。 若要利用整合式快取來增加重複讀取的可能性，您應該將 MaxIntegratedCacheStaleness 設為與您的商務需求所允許一樣高。

在最後填入快取的要求上設定 MaxIntegratedCacheStaleness 時，不會影響快取要求的時間長度。 當您嘗試讀取快取資料時，MaxIntegratedCacheStaleness 會強制執行一致性。 沒有全域 TTL 或快取保留設定，因此只有當整合式快取已滿，或新讀取使用較目前快取的項目存留期更低的 MaxIntegratedCacheStaleness 執行時，才會從快取收回資料。

這是多數快取運作方式的改善，並允許下列其他自訂：

• 您可以針對每個點讀取或查詢設定不同的過期需求
• 只要用戶端不同，即使它們執行相同的點讀取或查詢，您也可以設定不同的 MaxIntegratedCacheStaleness 值
• 如果您想要在修改快取資料的讀取一致性，您可以變更 MaxIntegratedCacheStaleness 以立即影響讀取一致性

若要進一步了解 MaxIntegratedCacheStaleness 參數，請考慮下列範例：

了解如何設定 MaxIntegratedCacheStaleness。

略過整合式快取

整合式快取的儲存容量有限，由佈建的專用閘道 SKU 所決定。 根據預設，如果要求來自設定專用閘道連接字串的用戶端，則所有要求都會經過整合式快取並佔用快取空間。 您可以使用略過整合式快取要求選項，來控制快取哪些項目和查詢。 此要求選項適用於預期不經常重複的項目寫入或讀取要求。 針對不常存取的項目略過整合式快取，可為較常重複的項目省下快取空間，並提高 RU 節省潛力及減少收回。 略過快取的要求仍會透過專用閘道路由傳送。 這些要求會從後端提供，且成本為 RU。

了解如何略過整合式快取。

計量

這對監視整合式快取一些重要的 DedicatedGateway 和 IntegratedCache 計量很有幫助。 若要了解這些計量，請參閱 Microsoft.DocumentDB/DatabaseAccounts 的支援計量 (部分機器翻譯)。

根據預設，所有現有的計量都可從 Azure 入口網站中的計量取得 (而非傳統計量)：

計量是所有專用閘道節點的平均、最大值或總和。 例如，如果您佈建具有五個節點的專用閘道叢集，該計量會反映所有五個節點之間的彙總值。 您無法判斷每個個別節點的計量值。

疑難排解常見問題

下列範例說明如何對一些常見的案例進行偵錯：

我不知道我的應用程式是否使用專用閘道

檢查 DedicatedGatewayRequests。 此計量包含使用專用閘道的所有要求，不論它們是否達到整合式快取。 如果您的應用程式使用標準閘道或直接模式搭配原始連接字串，您將不會看到錯誤訊息，但 DedicatedGatewayRequests 會是零。 如果您的應用程式使用直接模式搭配您的專用閘道連接字串，您可能仍然會看到一些 DedicatedGatewayRequests。

我不知道我的要求是否達到整合式快取

檢查 IntegratedCacheItemHitRate 和 IntegratedCacheQueryHitRate。 如果這兩個值都是零，則要求未達到整合式快取。 確認您使用的是專用閘道連接字串、使用閘道模式連接，並且使用工作階段或最終一致性。

我想要了解我的專用閘道是否太小

檢查 IntegratedCacheItemHitRate 和 IntegratedCacheQueryHitRate。 高值 (例如，高於 0.7-0.8) 是專用閘道夠大的良好訊號。

如果 IntegratedCacheItemHitRate 或 IntegratedCacheQueryHitRate 很低，請查看 IntegratedCacheEvictedEntriesSize。 如果 IntegratedCacheEvictedEntriesSize 很高，可能表示較大的專用閘道大小會有幫助。 您可以藉由增加專用閘道大小並比較新的 IntegratedCacheItemHitRate 和 IntegratedCacheQueryHitRate 來進行實驗。 如果較大的專用閘道無法改善 IntegratedCacheItemHitRate 或 IntegratedCacheQueryHitRate，則可能讀取本身的重複不足以讓整合式快取具影響力。

我想要了解我的專用閘道是否太大

要測量專用閘道是否太大會較測量專用閘道是否太小更困難。 一般來說，您應該從小規模開始，然後再慢慢增加專用閘道的大小，直到 IntegratedCacheItemHitRate 和 IntegratedCacheQueryHitRate 停止改善為止。 在某些情況下，只有兩個快取命中計量的其中一個會是重要的，而非兩者。 例如，如果您的工作負載主要是查詢而非點讀取，則 IntegratedCacheQueryHitRate 比 IntegratedCacheItemHitRate 更為重要。

如果由於超過 MaxIntegratedCacheStaleness 而非 LRU，從快取收回大部分的資料，您的快取可能會大於所需。 如果 IntegratedCacheItemExpirationCount 和 IntegratedCacheQueryExpirationCount 合併幾乎與 IntegratedCacheEvictedEntriesSize 一樣大，您可以使用較小的專用閘道大小進行實驗，並比較效能。

我想要了解是否需要新增更多專用閘道節點

在某些情況下，如果延遲異常地高，您可能需要更多專用閘道節點，而不是較大的節點。 檢查 DedicatedGatewayCPUUsage 和 DedicatedGatewayMemoryUsage 以判斷新增更多專用閘道節點是否會降低延遲。 請記住，因為整合式快取的所有執行個體彼此獨立，新增更多專用閘道節點將不會減少 IntegratedCacheEvictedEntriesSize。 但是，新增更多節點將可改善專用閘道叢集可以處理的要求量。

下一步

• 整合式快取常見問題
• 設定整合式快取
• 專用閘道
• 正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？ 您可以使用現有資料庫叢集的相關資訊進行容量規劃。
  • 如果您知道現有資料庫叢集中的虛擬核心和伺服器數目，請參閱使用虛擬核心或 vCPU 來估計要求單位
  • 如果您知道目前資料庫工作負載的一般要求率，請參閱使用 Azure Cosmos DB 容量規劃工具來估計要求單位