共用方式為

Azure Cosmos DB 整合式快取常見問題集

  • 發行項

適用於：NoSQL

Azure Cosmos DB 整合式快取是內建於 Azure Cosmos DB 中的記憶體內部快取。 本文可回答關於 Azure Cosmos DB 整合式快取的常見問題。

常見問題集

為什麼整合式快取需要專用閘道？

如果您使用閘道模式連接到 Azure Cosmos DB，則是使用標準閘道。 雖然 Azure Cosmos DB 後端 (您佈建的輸送量和儲存體) 具有每個容器的專用容量，標準閘道卻會在許多客戶間共用。 由於每個客戶取用的計算資源很小，因此對許多客戶來說，共用標準網路閘道是很務實的做法。 因為整合式快取是您的 Azure Cosmos DB 帳戶專屬，並需要大量 CPU 和記憶體，因此需要使用專用閘道。

什麼是專用閘道？

專用閘道是伺服器端計算，其為通往 Azure Cosmos DB 帳戶中資料的前端。 當您使用閘道模式連線到專用閘道端點時，應用程式會傳送要求給專用閘道，後者再將要求路由傳送到不同的後端分割區。 支援使用具有專用閘道的直接模式，但這些要求不會使用整合式快取。

使用專用閘道會較使用標準閘道提供任何其他效能優勢？

一般情況下，由專用閘道路由的要求，其延遲會比標準閘道所路由的要求稍低且更一致。 即使是未使用整合式快取的要求，其延遲仍會比標準閘道稍低。

我應從整合式快取預期的延遲類型為何？

整合式快取所提供的要求速度較快，因為快取的資料會儲存於專用閘道上的記憶體中，而不是在後端上。

針對快取的點讀取，您應該預期平均延遲為 2-4 毫秒。 針對快取的查詢，延遲取決於查詢。 查詢快取的運作方式是快取特定查詢的查詢引擎回應。 然後，此回應會傳送回用戶端到 SDK 供處理。 若為簡單的查詢，則需要 SDK 中最少量的工作，且平均延遲通常為 2-4 毫秒。 使用 GROUP BY 或 DISTINCT 的較複雜查詢，則需要在 SDK 中進行更多處理，因此延遲可能較高 (即使使用查詢快取也一樣)。

如果您先前使用直接模式連接到 Azure Cosmos DB，並切換為使用專用閘道連接，您可能會發現某些要求的延遲可能稍微增加。 使用閘道模式需要將要求傳送至閘道 (在此情況下為專用閘道)，然後適當地路由至後端。 直接模式如同其名，可讓用戶端直接與後端通訊，免除額外的躍點。 使用專用閘道的要求沒有任何延遲 SLA。

如果您的應用程式先前使用直接模式，則只有在下列情況下，整合式快取的延遲優點才會明顯：

  • 大型項目 (> 16 KB) 的點讀取延遲
  • 高 RU 或複雜查詢

如果您的應用程式先前使用閘道模式搭配標準閘道，則在幾乎所有情況下，整合式快取將可降低延遲。

Azure Cosmos DB 可用性 SLA 是否會延伸到專用閘道和整合式快取？

針對需要高可用性且要由 Azure Cosmos DB 可用性 SLA 涵蓋的案例，您應該佈建至少 3 個專用閘道節點。 例如，若生產環境中需要一個專用閘道節點，您應該佈建兩個額外的專用閘道節點，考量到可能的停機、中斷或升級。 若只佈建一個專用閘道節點，則您將在這些案例中暫時失去可用性。 此外，請確保您的專用閘道有足夠的節點，可為您的工作負載提供服務。

整合式快取目前僅適用於 NoSQL 的 API。 您是否還計劃針對其他 API 發行？

將整合快取擴充到 NoSQL API 之外是長期藍圖上規劃的，但超出了整合快取的初始範圍。

整合式快取支援什麼一致性？

整合式快取同時支援工作階段和最終一致性。 您也可以設定選用的 MaxIntegratedCacheStaleness，其會對快取的資料放置上限。

下一步