Share via

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

  • Статья

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

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

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

См. также