Limites de consulta

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

Kusto é um motor de consultas ad hoc que aloja grandes conjuntos de dados e tenta satisfazer consultas mantendo todos os dados relevantes na memória. Existe um risco inerente de que as consultas monopolizem os recursos do serviço sem limites. Kusto fornece várias proteções internas na forma de limites de consulta padrão. Se você está pensando em remover esses limites, primeiro determine se realmente ganha algum valor ao fazer isso.

Limite de simultaneidade de solicitação

A concorrência de pedidos é um limite para vários pedidos a serem executados ao mesmo tempo.

• O valor padrão do limite depende da SKU em que o banco de dados está sendo executado e é calculado como: Cores-Per-Node x 10.
  • Por exemplo, para um banco de dados configurado em D14v2 SKU, onde cada máquina tem 16 vCores, o limite padrão é 16 cores x10 = 160.
• Pode alterar o valor padrão configurando a política de limite de taxa de pedidos do default grupo de carga de trabalho.
  • Vários fatores afetam o número real de pedidos que podem ser executados em simultâneo numa base de dados. Os fatores mais dominantes são a SKU do banco de dados, os recursos disponíveis do banco de dados e os padrões de uso. Configure a política com base em testes de carga realizados em padrões de utilização semelhantes aos de produção.

Limite no tamanho do conjunto de resultados (truncamento de resultados)

O truncamento de resultados é um limite padrão no conjunto de resultados devolvido pela consulta. Kusto limita o número de registros retornados ao cliente a 500.000e o tamanho geral dos dados desses registros a 64 MB. Quando um desses limites é excedido, a consulta falha com uma "falha de consulta parcial". Exceder o tamanho total dos dados gera uma exceção com a seguinte mensagem:

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).'

Exceder o número de registos falha, com uma exceção que diz:

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).'

Pode usar várias estratégias para resolver este erro.

• Reduza o tamanho do conjunto de resultados modificando a consulta para retornar apenas dados interessantes. Essa estratégia é útil quando a consulta inicial com falha é muito "ampla". Por exemplo, a consulta não projeta colunas de dados que não são necessárias.
• Reduza o tamanho do conjunto de resultados deslocando o processamento pós-consulta, como agregações, para a própria consulta. Esta estratégia é útil em cenários onde o resultado da consulta é enviado a outro sistema de processamento, e esse sistema depois faz outras agregações.
• Alterne de consultas para usar de exportação de dados quando quiser exportar grandes conjuntos de dados do serviço.
• Instrua o serviço a suprimir este limite de consulta utilizando as set instruções listadas na secção seguinte ou os flags nas propriedades do pedido do cliente.

Os métodos para reduzir o tamanho do conjunto de resultados produzido pela consulta incluem:

• Use o operador summarize para agrupar e agregar sobre registos semelhantes na saída da consulta. Potencialmente faça uma amostra de algumas colunas usando a função de agregação take_any.
• Use um operador take para obter uma amostra da saída da consulta.
• Use a função substring para cortar colunas de texto livre amplas.
• Use o operador de projeto para soltar qualquer coluna desinteressante do conjunto de resultados.

Você pode desabilitar o truncamento de resultados usando a opção de solicitação notruncation. Recomendamos que alguma forma de limitação ainda seja implementada.

Por exemplo:

set notruncation;
MyTable | take 1000000

Também pode ter um controlo mais refinado sobre o truncamento dos resultados, definindo o valor de truncationmaxsize (tamanho máximo dos dados em bytes, padrão para 64 MB) e truncationmaxrecords (número máximo de registos, por defeito 500.000). Por exemplo, a consulta a seguir define o truncamento de resultados para acontecer em 1.105 registros ou 1 MB, o que for excedido.

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

Remover o limite de truncamento de resultados significa que você pretende mover dados em massa para fora do Kusto.

Você pode remover o limite de truncamento de resultados para fins de exportação usando o comando .export ou para agregação posterior. Se você escolher a agregação posterior, considere agregar usando Kusto.

O Kusto disponibiliza muitas bibliotecas clientes que conseguem lidar com resultados "infinitamente grandes" transmitindo-os para o chamador. Use uma dessas bibliotecas e configure-a para o modo de streaming. Por exemplo, use o cliente .NET Framework (Microsoft.Azure.Kusto.Data) e defina a propriedade de streaming da cadeia de conexão como trueou use a chamada ExecuteQueryV2Async() que sempre transmite resultados. Para obter um exemplo de como usar ExecuteQueryV2Async(), consulte o HelloKustoV2 aplicativo.

Também podes achar útil a aplicação de exemplo de ingestão de streaming em C#.

O truncamento de resultados é aplicado por padrão, não apenas ao fluxo de resultados retornado ao cliente.

Definindo propriedades de truncamento de vários resultados

As seguintes regras aplicam-se quando utiliza set instruções ou especifica flags nas propriedades de pedidos do cliente.

• Se definir notruncation mas também definir truncationmaxsize, truncationmaxrecords, ou query_take_max_records, o serviço ignora notruncation.
• Se definir truncationmaxsize, truncationmaxrecords, ou query_take_max_records mais do que uma vez, o serviço usa o valor mais baixo para cada propriedade.

Limite de memória consumida pelos operadores de consulta

O consumo máximo de memória por iterador pode ser configurado para controlar a quantidade de memória que cada operador de consulta consome, por nó. Alguns operadores de consulta, como join e summarize, armazenam dados significativos em memória. Ao aumentar o padrão da opção maxmemoryconsumptionperiteratorde pedido , pode executar consultas que requerem mais memória por operador.

O valor máximo suportado para esta opção de solicitação é 32212254720 (30 GB). Se definir maxmemoryconsumptionperiterator várias vezes, por exemplo tanto nas propriedades de pedido do cliente como usando uma set instrução, aplica-se o valor mais baixo.

Quando a consulta atinge o limite de memória configurada por operador, uma mensagem de falha parcial da consulta exibe e inclui o texto E_RUNAWAY_QUERY.

Por exemplo:

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).

Por exemplo, esta consulta define o consumo máximo de memória por iterador para 15 GB:

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

Outro limite que pode desencadear uma E_RUNAWAY_QUERY falha parcial de consulta é o tamanho máximo acumulado das strings mantidas por um único operador. A opção de pedido acima não pode ultrapassar este limite.

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

Quando esse limite é excedido, muito provavelmente o operador de consulta relevante é um join, summarizeou make-series.

Para contornar o limite, modifique a consulta para usar a estratégia de consulta de embaralhamento . Esta alteração também deverá melhorar o desempenho da consulta.

Em todos os casos de E_RUNAWAY_QUERY, uma opção adicional (além de aumentar o limite definindo a opção de solicitação e alterando a consulta para usar uma estratégia de shuffle) é mudar para amostragem. A amostragem reduz a quantidade de dados processados pela consulta e, por isso, diminui a pressão de memória sobre os operadores da consulta.

Estas duas perguntas mostram como fazer a amostragem. A primeira consulta é uma amostragem estatística, usando um gerador de números aleatórios. A segunda consulta é a amostragem determinística, feita por hash de alguma coluna do conjunto de dados, geralmente algum ID.

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

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

Para mais informações sobre o uso de mecanismos como hint.shufflekey para ambos summarize , joinveja Melhores práticas para consultas em Linguagem de Consultas Kusto.

Limite de memória por nó

Memória máxima por consulta por de nó é outro limite usado para proteger contra consultas "fugitivas". Esse limite, representado pela opção de solicitação max_memory_consumption_per_query_per_node, define um limite superior na quantidade de memória que pode ser usada em um único nó para uma consulta específica.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Se max_memory_consumption_per_query_per_node for definido várias vezes, por exemplo, nas propriedades de solicitação do cliente e usando uma instrução set, o valor mais baixo será aplicado.

Se a consulta usar operadores summarize, joinou make-series, você poderá usar a estratégia de de consulta aleatória para reduzir a pressão de memória em uma única máquina.

Limitar o tempo limite de execução

de tempo limite do servidor é um tempo limite do lado do serviço que é aplicado a todas as solicitações. O tempo limite em execução de solicitações (consultas e comandos de gerenciamento) é imposto em vários pontos do Kusto:

• biblioteca de cliente (se usada)
• Ponto de extremidade de serviço que aceita a solicitação
• mecanismo de serviço que processa a solicitação

Por padrão, o tempo limite é definido como quatro minutos para consultas e 10 minutos para comandos de gerenciamento. Este valor pode ser aumentado, se necessário (limitado a uma hora).

• Várias ferramentas de cliente suportam a alteração do tempo limite como parte de suas configurações globais ou por conexão. Por exemplo, em Kusto.Explorer, use Ferramentas>Opções* >Conexões>Tempo Limite do Servidor de Consulta.
• Programaticamente, os SDKs suportam a definição do tempo limite através da propriedade servertimeout. Por exemplo, no SDK do .NET, isso é feito por meio de uma propriedade de solicitação de cliente , definindo um valor do tipo System.TimeSpan.

Notas sobre tempos mortos

• No lado do cliente, o tempo limite é aplicado desde a solicitação que está sendo criada até o momento em que a resposta começa a chegar ao cliente. O tempo necessário para ler a carga útil de volta no cliente não é tratado como parte do tempo limite. Depende da rapidez com que o chamador extrai os dados do fluxo.
• Também no lado do cliente, o valor de tempo limite real usado é ligeiramente maior do que o valor de tempo limite do servidor solicitado pelo usuário. Esta diferença, é para permitir latências de rede.
• Para usar automaticamente o tempo limite máximo de solicitação permitido, defina a propriedade de solicitação do cliente norequesttimeout como true.

Limite no uso de recursos da CPU de consulta

Kusto permite que você execute consultas e use todos os recursos de CPU disponíveis que o banco de dados tem. Ele tenta fazer um round-robin justo entre consultas se mais de uma estiver em execução. Esse método produz o melhor desempenho para funções definidas por consulta. Noutras ocasiões, pode querer limitar os recursos da CPU usados para uma determinada consulta. Se você executar um "trabalho em segundo plano", por exemplo, o sistema poderá tolerar latências mais altas para dar alta prioridade às consultas embutidas simultâneas.

O Kusto suporta a especificação de duas propriedades de solicitação ao executar uma consulta. As propriedades são query_fanout_threads_percent e query_fanout_nodes_percent. Ambas as propriedades são inteiros que usam como padrão o valor máximo (100), mas podem ser reduzidos para uma consulta específica para algum outro valor.

O primeiro, query_fanout_threads_percent, controla o fator de fanout para uso de threads. Quando esta propriedade está definida 100%, todas as CPUs são atribuídas a cada nó. Por exemplo, 16 CPUs implantadas em nós do Azure D14. Quando esta propriedade é definida para 50%, então metade dos CPUs é usada, e assim sucessivamente. Os números são arredondados para uma CPU inteira, por isso é seguro definir o valor da propriedade como 0.

O segundo, query_fanout_nodes_percent, controla quantos nós de consulta usar por operação de distribuição de subconsulta. Funciona de forma semelhante.

Se query_fanout_nodes_percent ou query_fanout_threads_percent forem definidas várias vezes, por exemplo, em ambas as propriedades de solicitação do cliente e usando uma instrução set - o valor mais baixo para cada propriedade se aplica.

Limite da complexidade da consulta

Durante a execução da consulta, o texto da consulta é transformado em uma árvore de operadores relacionais que representam a consulta. Se a profundidade da árvore ultrapassar um limiar interno, a consulta é considerada demasiado complexa para processamento e falha com um código de erro. A falha indica que a árvore de operadores relacionais excede seus limites.

Os exemplos a seguir mostram padrões de consulta comuns que podem fazer com que a consulta exceda esse limite e falhe:

• uma longa lista de operadores binários que estão encadeados. Por exemplo:

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

Para este caso específico, reescreva a consulta usando o operador in().

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

• Uma consulta que tem um operador union que está a executar uma análise de esquema demasiado ampla, especialmente que a versão padrão da union é devolver o esquema union "externo" (ou seja, essa saída inclui todas as colunas da tabela subjacente).

A sugestão, neste caso, é rever a consulta e reduzir as colunas que estão sendo usadas pela consulta.

Conteúdo relacionado

• de práticas recomendadas de consulta