缓存策略(热缓存和冷缓存)

适用于:✅Azure 数据资源管理器

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

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

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

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

使用管理命令更改群集数据库具体化视图级别的缓存策略。

提示

群集专为临时查询而设计,中间结果集适合群集的总 RAM。 对于 map-reduce 等大型作业,将中间结果存储在持久性存储中可能很有用。 为此,请创建连续导出作业。 此功能使你可以使用 HDInsight 或 Azure Databricks 等服务执行长时间运行的批处理查询。

如何应用缓存策略

引入数据时,系统将跟踪引入的日期和时间以及创建的盘区。 盘区的引入日期和时间值(如果盘区是从多个预先存在的盘区中构建的,则为最大值)用于计算缓存策略。

注意

可以使用引入属性 creationTime 来指定引入日期和时间的值。 这样做时,请确保表的有效盘区合并策略中的 Lookback 属性与你为 creationTime 设置的值一致。

默认情况下,有效策略为 null,这意味着所有数据都被视为热数据。 表级别的 null 策略意味着该策略将从数据库继承。 非 null 表级别的策略会重写数据库级别的策略。

将查询范围限定为热缓存

运行查询时,可以将范围限制为仅查询热缓存中的数据。

注意

数据范围设置仅适用于支持缓存策略的实体,例如表和具体化视图。 对于其他实体(例如外部表和行存储中的数据),它会被忽略。

以下为几种可能的查询:

  • 将名为 query_datascope 的客户端请求属性添加到查询中。 可能的值:defaultallhotcache
  • 在查询文本中使用 set 语句:set query_datascope='...'。 可能的值与客户端请求属性的值相同。
  • 在查询正文中紧跟表引用的后面添加 datascope=... 文本。 可能的值为 allhotcache

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 天的数据运行查询。