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

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

  • Статья

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

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

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

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

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

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

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

Совет

Кластер предназначен для нерегламентированных запросов с промежуточными результирующих наборами, которые соответствуют общему объему ОЗУ кластера. Для больших заданий, таких как 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

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

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