Ограничения на запросы

Переключение служб с помощью раскрывающегося списка версий . Дополнительные сведения о навигации.
Область применения: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

Kusto — это нерегламентированный обработчик запросов, в котором размещаются большие наборы данных и пытается удовлетворить запросы, удерживая все соответствующие данные в памяти. Существует внутренний риск, который запрашивает монополизацию ресурсов службы без ограничений. Kusto предоставляет несколько встроенных возможностей защиты от таких рисков в виде ограничений запросов по умолчанию. Если вы хотите снять такие ограничения, сначала определите, даст ли вам это какие-либо фактические преимущества.

Ограничение на параллелизм запросов

Параллелизм запросов — это ограничение на несколько запросов, выполняемых одновременно.

• Значение ограничения по умолчанию зависит от номера SKU, в котором выполняется база данных, и вычисляется следующим образом: Cores-Per-Node x 10
  • Например, для базы данных, настроенной на SKU D14v2, где каждый компьютер имеет 16 виртуальных ядер, ограничение по умолчанию равно 16 cores x10 = 160.
• Значение по умолчанию можно изменить, настроив политику ограничения скорости запроса группы рабочей нагрузки default .
  • Различные факторы влияют на фактическое количество запросов, которые могут выполняться одновременно в базе данных. Наиболее основными факторами являются SKU базы данных, доступные ресурсы базы данных и шаблоны использования. Настройте политику на основе нагрузочных тестов, выполняемых в рабочих шаблонах использования.

Ограничение на размер результирующего набора (усечение результата)

Усечение результатов — это ограничение по умолчанию для результируемого набора, возвращаемого запросом. Kusto ограничивает число записей, возвращаемых клиенту, до 500 000, а общий объем данных для таких записей — до 64 МБ. При превышении какого-либо из этих ограничений запрос завершается с частичным сбоем выполнения. Превышение общего размера данных приводит к возникновению исключения со следующим сообщением:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

Превышение количества записей завершается сбоем с исключением, которое говорит:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Для устранения этой ошибки можно использовать несколько стратегий.

• Уменьшите размер результирующего набора, изменив запрос, чтобы он возвращал только интересующие вас данные. Эта стратегия полезна, если изначальный запрос с ошибкой охватывает слишком широкий спектр данных, например не отбрасывает ненужные столбцы данных.
• Уменьшите размер результирующего набора, реализовав в самом запросе последующую обработку, например агрегирование. Эта стратегия полезна в сценариях, когда выходные данные запроса передаются в другую систему обработки, а затем эта система выполняет другие агрегаты.
• Чтобы экспортировать крупные наборы данных из службы, используйте функцию экспорта данных вместо запросов.
• Укажите службе подавление этого ограничения запроса с помощью set инструкций, перечисленных в следующем разделе или флагах в свойствах запроса клиента.

Вы можете использовать следующие методы для уменьшения размера результирующего набора, создаваемого запросом:

• Используйте оператор суммирования для группировки и статистической обработки аналогичных записей в выходных данных запроса. Кроме того, вы можете потенциально получать выборку из некоторых столбцов с помощью статистической функции take_any.
• Оператор take позволяет получать выборку из выходных данных запроса.
• Функция substring обрезает широкие столбцы с произвольным текстом.
• Оператор project удаляет не интересующие вас столбцы из результирующего набора.

Вы можете отключить усечение результатов с помощью параметра запроса notruncation. Но мы все равно рекомендуем использовать ограничения в каком-либо виде.

Например:

set notruncation;
MyTable | take 1000000

Кроме того, можно более подробно контролировать усечение результатов, установив значение truncationmaxsize (максимальный размер данных в байтах, по умолчанию — 64 МБ) и truncationmaxrecords (максимальное количество записей, по умолчанию — 500 000). Например, следующие наборы запросов усечены для усечения результатов в 1 105 записей или 1 МБ, в зависимости от превышения.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Отмена ограничения с усечением результатов приведет к тому, что из Kusto будут передаваться все данные.

Вы можете отменить это ограничение, если вы хотите экспортировать данные (с помощью команды .export) или выполнить дальнейшее агрегирование. Во втором случае мы рекомендуем для агрегирования использовать Kusto.

Kusto предоставляет множество клиентских библиотек, которые могут обрабатывать "бесконечно большие" результаты путем потоковой передачи их вызывающему объекту. Используйте одну из таких библиотек и настройте ее для потоковой передачи. Например, используйте клиент .NET Framework (Microsoft.Azure.Kusto.Data) и задайте для свойства потоковой передачи в строке подключения значение true или используйте вызов ExecuteQueryV2Async(), который всегда выполняет потоковую передачу результатов. Пример использования ExecuteQueryV2Async()см. в приложении HelloKustoV2 .

Вы также можете найти пример приема потоковой передачи C#, полезный для приложения.

Усечение результатов применяется по умолчанию, а не только к потоку результатов, возвращаемого клиенту.

Установка нескольких свойств усечения результатов

Следующие правила применяются при использовании set инструкций или указании флагов в свойствах запроса клиента.

• Если задано, но также задано notruncationtruncationmaxsizeзначение или truncationmaxrecordsquery_take_max_recordsслужба игнорируетсяnotruncation.
• Если задано truncationmaxsizeзначение ( truncationmaxrecordsили query_take_max_records несколько раз), служба использует меньшее значение для каждого свойства.

Ограничение объема памяти, потребляемой операторами запросов

Можно настроить максимальное потребление памяти на итератор , чтобы управлять объемом памяти, используемой каждым оператором запроса на узел. Некоторые операторы запросов, такие как join и summarize, содержат значительные данные в памяти. Увеличив значение по умолчанию параметра maxmemoryconsumptionperiteratorзапроса, можно выполнять запросы, требующие больше памяти для каждого оператора.

Максимальное поддерживаемое значение для этого параметра запроса — 32 212 254 720 (30 ГБ). Если задать maxmemoryconsumptionperiterator несколько раз, например как в свойствах запроса клиента, так и с помощью set инструкции, применяется меньшее значение.

Когда запрос достигает заданного ограничения памяти для каждого оператора, отображается частичное сообщение об ошибке запроса и включает текст E_RUNAWAY_QUERY.

Например:

The ClusterBy operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

Например, этот запрос задает максимальное потребление памяти на итератор до 15 ГБ:

set maxmemoryconsumptionperiterator=16106127360;
MyTable | summarize count() by Use

Еще одним ограничением, которое может вызвать частичный сбой запроса, является максимальный накопленный E_RUNAWAY_QUERY размер строк, удерживаемых одним оператором. Описанный ранее параметр запроса не может переопределить это ограничение.

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Если это ограничение превышено, скорее всего, соответствующий оператор запроса имеет значение join, summarizeили make-series.

Чтобы обойти ограничение, измените запрос, чтобы использовать стратегию перетасовки запросов . Это изменение также может повысить производительность запроса.

Во всех случаях E_RUNAWAY_QUERYдругой вариант (помимо увеличения ограничения путем установки параметра запроса и изменения запроса на использование стратегии перетасовки) заключается в переключении на выборку. Выборка уменьшает объем данных, обработанных запросом, и поэтому снижает нагрузку на память для операторов запросов.

Эти два запроса показывают, как выполнить выборку. Первый запрос выполняет статистическую выборку, используя генератор случайных чисел. Второй запрос — детерминированная выборка, выполненная путем хэширования некоторых столбцов из набора данных, как правило, некоторых идентификаторов.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

Дополнительные сведения об использовании таких механизмов, как hint.shufflekey и для summarizejoinобоих, см. в рекомендациях по запросам языка запросов Kusto.

Ограничение на объем памяти для узла

Максимальное количество памяти на каждый узел — это еще одно ограничение, которое защищает от выполнения запросов. Параметр запроса max_memory_consumption_per_query_per_node задает верхнюю границу по объему памяти, которую может использовать один узел для определенного запроса.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Если задать max_memory_consumption_per_query_per_node несколько раз, например как в свойствах запроса клиента, так и set в инструкции, применяется меньшее значение.

Если в запросе используются операторы summarize, join или make-series, вы можете использовать стратегию смешения запросов, чтобы уменьшить нагрузку на память на отдельном компьютере.

Ограничение на время ожидания выполнения

Время ожидания сервера — это время ожидания на стороне службы, которое служба применяется ко всем запросам. Kusto применяет время ожидания при выполнении запросов (запросов и команд управления) в нескольких точках:

• в клиентской библиотеке (если она используется);
• на конечной точке службы, которая принимает запрос;
• в подсистеме службы, которая обрабатывает запрос.

По умолчанию время ожидания составляет четыре минуты для запросов и 10 минут для команд управления. При необходимости это значение можно увеличить до одного часа.

• Различные клиентские средства поддерживают изменение времени ожидания в рамках глобальных параметров или параметров подключения. Например, в Kusto.Explorer используйте время ожиданияподключения к>серверу запросовпараметров>инструментов>.
• Программным образом пакеты SDK поддерживают настройку времени ожидания через servertimeout свойство. Например, в пакете SDK для .NET задайте это свойство через свойство запроса клиента, задав значение типа System.TimeSpan.

Заметки о времени ожидания

• На стороне клиента временем ожидания считается время с момента создания запроса до момента получения ответа на клиенте. Время на считывание полезных данных на клиенте не учитывается во времени ожидания. Оно зависит от того, как быстро вызывающая сторона получает данные из потока.
• Кроме того, на стороне клиента фактическое значение времени ожидания будет немного превышать значение времени ожидания сервера, запрашиваемое пользователем. Такая разница позволяет компенсировать задержку в сети.
• Чтобы автоматически использовать максимально разрешенное время ожидания для запросов, задайте для свойства клиентского запроса norequesttimeout значение true.

Ограничение на использование запросом ресурсов ЦП

Kusto выполняет запросы и использует все доступные ресурсы ЦП, имеющиеся в базе данных. Он пытается выполнить справедливый циклический перебор между запросами, если выполняется несколько запросов. Этот метод обеспечивает лучшую производительность для определяемых запросом функций. В других случаях может потребоваться ограничить ресурсы ЦП, используемые для конкретного запроса. Если вы запускаете фоновое задание, например, система может терпеть более высокую задержку, чтобы дать одновременные встроенные запросы с высоким приоритетом.

Kusto поддерживает указание двух свойств запроса при выполнении запроса. query_fanout_threads_percent и query_fanout_nodes_percent. Оба свойства являются целыми числами, которые по умолчанию имеют максимальное значение (100), но их можно уменьшить для определенного запроса.

Первое свойство , query_fanout_threads_percent, управляет коэффициентом вентилятора для использования потоков. Если для этого свойства задано значение 100%, запрос использует все ЦП на каждом узле. Например, 16 ЦП, развернутых на узлах Azure D14. Если задать для этого свойства значение 50%, запрос использует половину ЦП и т. д. Числа округляются до целых, поэтому для ЦП свойству можно присвоить значение 0.

Второе свойство , query_fanout_nodes_percent, управляет количеством узлов запроса для использования для каждой операции распределения вложенных запросов. Она действует аналогичным образом.

Если вы задаете query_fanout_nodes_percent или query_fanout_threads_percent несколько раз, например, в свойствах запроса клиента и с помощью set инструкции, применяется меньшее значение для каждого свойства.

Ограничение на сложность запросов

Во время выполнения запроса его текст преобразуется в дерево операторов отношения, представляющих весь запрос. Если глубина дерева превышает внутреннее пороговое значение, запрос слишком сложный для обработки и завершается ошибкой с кодом ошибки. Сбой указывает на то, что для дерева операторов отношения превышены ограничения.

Превышена сложность запроса

Запрос слишком сложный для компиляции подсистемы. Эта сложность обычно возникает, когда построение плана запросов потребляет слишком много ресурсов. Наиболее вероятные причины:

• Крупные объединения во многих таблицах, например использование union * в большой базе данных.
• Глубоко вложенные запросы.
• Многие уровни let операторов, которые ссылаются друг на друга.

Размер или сложность плана запроса превышает установленные ограничения

Запрос создает план запроса, который слишком велик для обработки. Наиболее вероятные причины:

• Левая сторона вещания создает слишком много данных.
• Результаты, возвращаемые слишком toscalar() большими.
• Результаты внутри in() выражения слишком большие. Например, где вложенный in (subquery) запрос возвращает слишком много значений.

В следующих примерах показаны распространенные шаблоны запросов, которые могут привести к превышению этих ограничений и сбою.

• Длинный список двоичных операторов, которые объединяются в цепочку. Например:

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

Для этого конкретного случая переопределите запрос с помощью in() оператора.

T
| where Column in ("value1", "value2".... "valueN")

• Запрос, использующий оператор объединения и выполняющий слишком широкий анализ схемы. Эта проблема возникает, так как вкус объединения по умолчанию возвращает "внешнюю" схему объединения. Эта схема означает, что выходные данные включают все столбцы базовой таблицы.

Просмотрите запрос и уменьшите количество столбцов, которые использует запрос.

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

• Рекомендации по запросам