快取原則 (經常性存取和非經常性存取快取)

適用於： ✅Microsoft網狀架構✅Azure 數據總管

為了確保快速查詢效能，會使用多層式數據快取系統。 數據會儲存在可靠的記憶體中，但部分數據會在處理節點、SSD 或甚至 RAM 上快取，以更快速地存取。

快取原則可讓您選擇應該快取的數據。 您可以設定經常性數據快取和冷數據快取來區分經常性數據快取和冷數據快取。 經常性存取數據會保留在本機 SSD 記憶體中，以獲得更快的查詢效能，而冷數據則儲存在可靠的記憶體中，較便宜但存取速度較慢。

快取會針對經常性數據使用 95% 的本機 SSD 磁碟。 如果空間不足，則最新的數據會優先保留在快取中。 其餘 5% 用於未分類為經常性的數據。 此設計可確保載入大量冷數據的查詢不會從快取收回經常性存取數據。

快取所有擷取的數據時，會達到最佳的查詢效能。 不過，某些數據可能不保證在經常性快取中保留的費用。 例如，不常存取的舊記錄檔記錄可能會被視為較不重要。 在這種情況下，小組通常會選擇較低的查詢效能來支付費用，讓數據保持暖和。

使用管理命令來改變資料庫、數據表或具體化檢視層級的快取原則。

注意

如需耗用量率的相關信息，請參閱 Eventhouse 和 KQL 資料庫耗用量。

套用快取原則的方式

擷取數據時，系統會追蹤擷取的日期和時間，以及所建立的範圍。 範圍擷取日期和時間值（或最大值，如果從多個預先存在的範圍建立範圍），則用來評估快取原則。

注意

您可以使用擷取屬性 creationTime來指定擷取日期和時間的值。 這樣做時，請確定 Lookback 數據表之有效 Extents 合併原則 中的 屬性與您為 creationTime設定的值一致。

根據預設，有效原則為 null，這表示所有數據都會被視為 經常性存取。 null數據表層級的原則表示原則繼承自資料庫。 非null 數據表層級原則會覆寫資料庫層級原則。

將查詢範圍界定為經常性快取

執行查詢時，您可以將範圍限制為只在經常性快取中查詢數據。

注意

數據範圍僅適用於支援快取原則的實體，例如數據表和具體化檢視。 其他實體會忽略它，例如數據列存放區中的外部數據表和數據。

有數個查詢可能性：

• 將稱為 query_datascope 的用戶端要求屬性新增至查詢。 可能的值： default、 all和 hotcache。
• set在查詢文字中使用語句：set query_datascope='...'。 可能的值與用戶端要求屬性的值相同。
• 在 datascope=... 查詢主體中的數據表參考之後立即新增文字。 可能的值是 all 和 hotcache。

值 default 表示使用預設設定，以判斷查詢應該涵蓋所有數據。

如果不同方法之間有差異，則 set 優先於用戶端要求屬性。 指定數據表參考的值優先於兩者。

例如，在下列查詢中，所有數據表參考只會使用熱快取數據，但範圍限定於所有數據之 「T」 的第二個參考除外：

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

快取原則與保留原則

快取原則與 保留原則無關：

• 快取原則會定義如何設定資源的優先順序。 針對重要資料的查詢會加快速度。
• 保留原則會定義資料表/資料庫中可查詢資料的範圍（特別是 ）。 SoftDeletePeriod

根據預期的查詢模式，設定此原則以達到成本和效能之間的最佳平衡。

範例：

• SoftDeletePeriod = 56d
• hot cache policy = 28d

在此範例中，最後 28 天的數據會儲存在 SSD 上，而額外的 28 天數據會儲存在 Azure Blob 記憶體中。 您可以在整整 56 天的數據上執行查詢。

相關內容