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

查询结果缓存

  • 项目

Kusto 提供了查询结果缓存。 发出查询时，你可以选择获取缓存的结果。 如果查询结果可以由缓存返回，你可以体验到更好的查询性能和更低的资源消耗。 然而，实现此性能的代价是结果有一些“过时”。

使用缓存

将 query_results_cache_max_age 选项设置为查询的一部分可使用查询结果缓存。 你可以在查询文本中设置此选项，也可以将其作为客户端请求属性进行设置。 例如：

set query_results_cache_max_age = time(5m);
GithubEvent
| where CreatedAt > ago(180d)
| summarize arg_max(CreatedAt, Type) by Id

选项值为一个 timespan，它指示结果缓存的最长时间（从查询开始时间算起）。 超过所设置的时间跨度之后，缓存条目会过时，不会再次使用。 将值设置为 0 等效于不设置此选项。

查询之间的兼容性

相同的查询

查询结果缓存仅为被认为与前一个缓存查询“相同”的查询返回结果。 如果满足以下所有条件，则将两个查询视为相同的查询：

不兼容的查询

如果满足以下任一条件，则不会缓存查询结果：

不存在有效的缓存条目

如果找不到满足时间约束的缓存结果，或者缓存中不存在来自“完全相同”查询的缓存结果，则会执行该查询，并会在满足以下条件时缓存其结果：

  • 查询执行成功完成，并且
  • 查询结果大小未超过 16 MB。

缓存中的结果

服务如何指示查询结果是从缓存中提供的？ 当响应查询时，Kusto 会发送另一个 ExtendedProperties 响应表，其中包括 Key 列和 Value 列。 缓存的查询结果会为该表追加另一个行：

  • 该行的 Key 列将包含字符串 ServerCache
  • 该行的 Value 列将包含具有两个字段的属性包：
    • OriginalClientRequestId - 指定原始请求的 ClientRequestId。
    • OriginalStartedOn - 指定原始请求的执行开始时间。

分布

群集节点不共享缓存。 每个节点的专用存储中都有一个专用缓存。 如果在不同节点上有两个完全相同的查询，则在这两个节点上都会执行并缓存查询。 如果使用弱一致性，则可能会发生此过程。 通过将查询一致性设置为 affinitizedweakconsistency，可以在同一个查询头上拥有相同的弱一致性查询，从而提高缓存命中率。

管理

支持以下管理和可观测性命令：

  • 显示查询结果缓存：返回与查询结果缓存相关的统计信息。
  • 清除查询结果缓存：清除查询结果缓存。
  • 刷新查询缓存条目：可以使用 query_results_cache_force_refresh (OptionQueryResultsCacheForceRefresh) 客户端请求属性刷新特定的查询缓存条目。 如果设置为 true，此命令将在存在现有缓存时强制刷新查询结果缓存。 此进程在要求查询结果可供查询的方案中很有用。 此属性必须与“query_results_cache_max_age”结合使用，并通过 ClientRequestProperties 对象发送。 该属性不能是“set”语句的一部分。

容量

缓存容量目前固定为每个群集节点 1 GB。 逐出策略是 LRU。

分片级别查询结果缓存

当完全相同的查询快速连续多次运行时，查询结果缓存有效，并且可以容忍返回稍旧的数据。 但是，某些方案（如实时仪表板）需要最新的结果。

例如，每 10 秒运行一次且范围为过去 1 小时的查询可受益于在存储（分片）级别缓存中间查询结果。

使用 Query results cache 时，会自动启用分片级别查询结果缓存。 因为它与 Query results cache 共享相同的缓存，因此应用相同的容量和逐出策略。

语法

setquery_results_cache_per_shard; 查询

注意

可以在查询文本中设置此选项，也可以将其作为客户端请求属性进行设置。

详细了解语法约定。

示例

set query_results_cache_per_shard;
GithubEvent
| where CreatedAt > ago(180d)
| summarize arg_max(CreatedAt, Type) by Id