Поделиться через

Политика кэширования (горячий и холодный кэш)

  • Статья

Область применения: ✅Microsoft Fabric✅Azure Data Explorer

Для обеспечения быстрой производительности запросов используется многоуровневая система кэша данных. Данные хранятся в надежном хранилище, но их части кэшируются на узлах обработки, SSD или даже в ОЗУ для быстрого доступа.

Политика кэширования позволяет выбрать, какие данные следует кэшировать. Вы можете различать кэш горячих данных и кэш холодных данных, задав политику кэширования для горячих данных. Горячие данные хранятся в локальном хранилище SSD для повышения производительности запросов, а холодные данные хранятся в надежном хранилище, что дешевле, но медленнее для доступа.

Кэш использует 95 % локального диска SSD для горячих данных. Если недостаточно места, последние данные будут храниться в кэше. Остальные 5 % используются для данных, которые не относятся к категории "горячий". Эта конструкция гарантирует, что запросы, загружающие большое количество холодных данных, не будут вытеснять горячие данные из кэша.

Лучшая производительность запросов достигается при кэшировании всех приемных данных. Однако некоторые данные могут не гарантировать затраты на хранение в горячем кэше. Например, редко доступ к старым записям журнала может считаться менее важным. В таких случаях команды часто выбирают более низкую производительность запросов за то, чтобы сохранить данные теплыми.

Используйте команды управления для изменения политики кэширования на уровне базы данных, таблицы или материализованного представления .

Примечание.

Сведения о частоте потребления см. в разделе "Eventhouse" и "Использование базы данных KQL".

Используйте команды управления для изменения политики кэширования на уровне кластера, базы данных, таблицы или материализованного представления.

Совет

Кластер предназначен для нерегламентированных запросов с промежуточными результирующих наборами, которые соответствуют общему объему ОЗУ кластера. Для больших заданий, таких как map-reduce, полезно хранить промежуточные результаты в постоянном хранилище. Для этого создайте задание непрерывного экспорта . Эта функция позволяет выполнять длительные пакетные запросы с помощью таких служб, как HDInsight или Azure Databricks.

Применение политики кэширования

При приеме данных система отслеживает дату и время приема, а также степень, созданную. Значение даты и времени приема экстентов (или максимальное значение, если экстент был создан из нескольких предустановленных экстентов), используется для оценки политики кэширования.

Примечание.

Можно указать значение для даты приема и времени с помощью свойства 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

В этом примере данные хранятся на SSD за последние 28 дней, а дополнительные 28 дней данных хранятся в хранилище BLOB-объектов Azure. Запросы можно выполнять в 56 дней данных.

Связанный контент