你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

缓存策略（热缓存和冷缓存）

适用于：✅Microsoft Fabric✅Azure 数据资源管理器

为了确保快速查询性能，使用了多层数据缓存系统。 数据存储在可靠的存储中，但部分缓存在处理节点、SSD 或甚至 RAM 中，以便提高访问速度。

通过缓存策略，可以选择应缓存哪些数据。 可以通过对热数据设置缓存策略来区分热数据缓存和冷数据缓存。 热数据保存在本地 SSD 存储中，以实现更快的查询性能，冷数据存储在可靠存储中，这更便宜，但访问速度较慢。

缓存将 95% 的本地 SSD 磁盘用于热数据。 如果空间不足，最新数据优先保存在缓存中。 其余 5% 用于未分类为热的数据。 此设计可确保加载大量冷数据的查询不会从缓存中逐出热数据。

当所有引入数据缓存后，可以获得最佳查询性能。 但是，某些数据可能不值得保留在热缓存中。 例如，不经常访问的旧日志记录可能被认为不太重要。 在这种情况下，团队通常会选择较低的查询性能，而不是付费以保持数据温暖。

使用管理命令在数据库、表或具体化视图级别更改缓存策略。

注意

有关消耗率的信息，请参阅 Eventhouse 和 KQL 数据库消耗。

如何应用缓存策略

引入数据时，系统将跟踪引入的日期和时间以及创建的盘区。 盘区的引入日期和时间值（或最大值（如果某个盘区是从多个预先存在的盘区生成的），用于评估缓存策略。

注意

可以使用引入属性 creationTime 来指定引入日期和时间的值。 这样做时，请确保表的有效盘区合并策略中的 Lookback 属性与你为 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 天的数据运行查询。

相关内容