共用方式為

快取原則 （經常性快取和冷快取）

  • 發行項

Azure 數據總管會使用多層式數據快取系統，以確保快速查詢效能。 數據會儲存在可靠的記憶體中，例如 Azure Blob 儲存體，但部分數據會快取在處理節點、SSD 或甚至 RAM 中，以加快存取速度。

即時智慧會使用多層式數據快取系統來確保查詢效能快速。 數據會儲存在可靠的記憶體中，例如 OneLake，但部分數據會快取在處理節點、SSD 或甚至 RAM 中，以加快存取速度。

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

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

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

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

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

提示

您的叢集是針對具有中繼結果集的臨機操作查詢所設計，其符合叢集的總 RAM。 對於大型作業，例如 map-reduce，將中繼結果儲存在永續性記憶體中會很有用。 若要這樣做，請建立 連續匯出 作業。 這項功能可讓您使用 HDInsight 或 Azure Databricks 等服務來執行長時間執行的批次查詢。

套用快取原則的方式

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

注意

您可以使用擷取屬性 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 天的數據上執行查詢。

相關內容