Compartilhar via

Limites de consulta

  • Artigo

O Kusto é um mecanismo de consulta ad hoc que hospeda grandes conjuntos de dados e tenta satisfazer consultas mantendo todos os dados relevantes na memória. Há um risco inerente de que as consultas monopolizem os recursos de serviço sem limites. O Kusto oferece várias proteções internas na forma de limites de consulta padrão. Se estiver pensando em remover esses limites, primeiro determine se realmente obterá qualquer vantagem fazendo isso.

Limite na simultaneidade da solicitação

A simultaneidade de solicitações é um limite que um cluster impõe em várias solicitações em execução ao mesmo tempo.

  • O valor padrão do limite depende do cluster de SKU em que está sendo executado e é calculado como: Cores-Per-Node x 10.
    • Por exemplo, para um cluster configurado no SKU D14v2, em que cada computador tem 16 vCores, o limite padrão é 16 cores x10 = 160.
  • O valor padrão pode ser alterado configurando a política de limite de taxa de solicitação do grupo de carga de trabalho default.
    • O número real de solicitações que podem ser executadas simultaneamente em um cluster depende de vários fatores. Os fatores mais dominantes são SKU do cluster, recursos disponíveis do cluster e padrões de uso. A política pode ser configurada com base nos testes de carga executados em padrões de uso semelhantes à produção.

Para obter mais informações, confira Otimizar para alta simultaneidade com Azure Data Explorer.

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

O truncamento de resultado é um limite definido por padrão no conjunto de resultados retornado pela consulta. O Azure Data Explorer limita o número de registros retornados ao cliente a 500 mil e o tamanho geral dos dados para esses registros em 64 MB. Quando um desses limites é excedido, a consulta falha com uma "falha de consulta parcial". Exceder o tamanho geral dos dados vai gerar uma exceção com a 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 registros falhará, 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).'

Há várias estratégias para lidar com esse 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 exclui com project-away as colunas de dados que não são necessárias.
  • Reduza o tamanho do conjunto de resultados alternando o processamento de pós-consulta, como agregações, para a própria consulta. A estratégia é útil em cenários em que a saída da consulta é alimentada para outro sistema de processamento e, em seguida, faz outras agregações.
  • Alterne de consultas para o uso de exportação de dados quando você desejar exportar grandes conjuntos de dados do serviço.
  • Instrua o serviço a suprimir esse limite de consulta usando instruções set listadas abaixo ou sinalizadores em propriedades de solicitação do cliente.

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

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 é possível ter um controle mais refinado sobre o truncamento de resultados definindo o valor de truncationmaxsize (tamanho máximo de dados em bytes; o padrão é 64 MB) e truncationmaxrecords (número máximo de registros, o padrão é 500 mil). Por exemplo, a consulta a seguir define que o truncamento de resultados ocorre em 1.105 registros ou 1 MB, o que for excedido.

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

A remoção do limite de truncamento de resultados significa que você pretende mover dados em massa do Azure Data Explorer.

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 a agregação usando o Azure Data Explorer.

O Azure Data Explorer oferece várias bibliotecas de cliente que podem 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 do .NET Framework (Microsoft.Azure.Kusto.Data) e defina a propriedade streaming da cadeia de conexão como true ou use a chamada ExecuteQueryV2Async() que sempre transmite resultados. Para obter um exemplo de como usar ExecuteQueryV2Async(), consulte o aplicativo HelloKustoV2 .

O aplicativo de exemplo de ingestão de streaming no C# também pode ser útil.

O truncamento de resultados é aplicado por padrão, não apenas ao fluxo de resultados retornado ao cliente. Ele também é aplicado por padrão a qualquer subconsulta que um cluster emite para outro cluster em uma consulta entre clusters, com efeitos semelhantes.

Como definir propriedades de truncamento de vários resultados

A regra a seguir se aplica ao uso de instruções set e/ou à especificação de sinalizadores nas propriedades de solicitação do cliente.

  • Se notruncation for definido e truncationmaxsize, truncationmaxrecords ou query_take_max_records também for definido, notruncation será ignorado.
  • Se truncationmaxsize, truncationmaxrecords e/ou query_take_max_records forem definidos várias vezes, será aplicado o menor valor a cada propriedade.

Limite de memória consumida por operadores de consulta (E_RUNAWAY_QUERY)

O Kusto limita a memória que cada operador de consulta pode consumir para proteger contra consultas "fugitivas". Esse limite pode ser atingido por alguns operadores de consulta, como join e summarize, que operam mantendo dados significativos na memória. Por padrão, o limite é de 5 GB (por nó de cluster) e pode ser aumentado definindo a opção de solicitação maxmemoryconsumptionperiterator:

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

Quando esse limite é atingido, uma falha de consulta parcial é emitida com uma mensagem que inclui o texto E_RUNAWAY_QUERY.

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

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

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

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

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

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

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

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

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

Um limite adicional que pode disparar uma E_RUNAWAY_QUERY falha de consulta parcial é um limite no tamanho máximo acumulado de cadeias de caracteres mantidas por um único operador. Esse limite não pode ser substituído pela opção de solicitação acima:

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

Quando esse limite é excedido, provavelmente o operador de consulta relevante é um join, summarizeou make-series. Para contornar o limite, é necessário modificar a consulta para usar a estratégia de consulta aleatória . (Isso também provavelmente melhorará o desempenho da consulta.)

Em todos os casos de , uma opção adicional (além de E_RUNAWAY_QUERYaumentar o limite definindo a opção de solicitação e alterando a consulta para usar uma estratégia de ordem aleatória) é alternar para amostragem. As duas consultas abaixo mostram como fazer a amostragem. A primeira consulta é uma amostragem estatística, que usa um gerador de número aleatório. A segunda consulta é a amostragem determinística, feita pelo hash de algumas colunas do conjunto de dados, geralmente alguma ID.

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

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

Limite de memória por nó

A memória máxima por consulta por nó é outro limite usado para proteger contra consultas "descontroladas". 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 prevalecerá.

Se a consulta usar operadores summarize, join ou make-series, você poderá usar a estratégia de consulta de ordem aleatória para reduzir a pressão de memória em um determinado computador.

Tempo limite de execução

O tempo limite do servidor é um tempo limite do lado do serviço que é aplicado a todas as solicitações. O tempo limite na execução de solicitações (consultas e comandos de gerenciamento) é imposto em vários pontos no 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. Esse valor pode ser aumentado se necessário (limitado em uma hora).

  • Várias ferramentas de cliente dão suporte à alteração do tempo limite como parte de suas configurações globais ou por conexão. Por exemplo, no Kusto. Explorer, use Opções de Ferramentas>* >Tempo limite do servidor de consultade conexões>.
  • Programaticamente, os SDKs dão suporte à definição do tempo limite por toda a servertimeout propriedade. 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.

Observações sobre tempos limite

  • No lado do cliente, o tempo limite é aplicado desde a solicitação que está sendo criada até a hora em que a resposta começa a chegar ao cliente. O tempo necessário para ler o conteúdo de volta no cliente não é tratado como parte do tempo limite. Ele depende de quão rápido o chamador efetua pull dos dados no 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. Essa diferença serve 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.

Observação

Confira definir limites de tempo limite para um guia passo a passo sobre como definir tempos limite na interface do usuário da Web do Azure Data Explorer, Kusto.Explorer, Kusto.Cli, Power BI e ao usar um SDK.

Limite de uso de recursos de CPU da consulta

O Azure Data Explorer permite executar consultas e usar o máximo de recursos de CPU que o cluster tem. Ele tenta fazer um round-robin justo entre consultas, se houver mais de uma em execução. Esse método produz o melhor desempenho para funções definidas por consulta. Em outras ocasiões, talvez seja interessante limitar os recursos de CPU usados para uma consulta específica. Se você executar um "trabalho em segundo plano", por exemplo, o sistema poderá tolerar latências mais altas para dar alta prioridade a consultas embutidas simultâneas.

O Kusto dá suporte à 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 assumem como padrão o valor máximo (100), mas podem ser reduzidos para uma consulta específica para algum outro valor.

A primeira, query_fanout_threads_percent, controla o fator fanout para o uso do thread. Quando essa propriedade for definida 100%, o cluster atribuirá todas as CPUs em cada nó. Por exemplo, 16 CPUs em um cluster implantado em nós do Azure D14. Quando essa propriedade for definida como 50%, metade das CPUs será usada e assim por diante. Os números são arredondados para uma CPU inteira, portanto, é seguro definir o valor da propriedade como 0.

O segundo, query_fanout_nodes_percent, controla quantos nós de consulta no cluster usar por operação de distribuição de subconsulta. Ele funciona de maneira semelhante.

Se query_fanout_nodes_percent ou query_fanout_threads_percent for definido várias vezes, por exemplo, nas propriedades da solicitação do cliente e usando uma instrução set, o menor valor de cada propriedade prevalecerá.

Limite de 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 exceder um limite interno, a consulta será considerada muito complexa para o processamento e falhará com um código de erro. A falha indica que a árvore de operadores relacionais excedeu os limites.

Os seguintes exemplos mostram padrões comuns de consulta que podem fazer com que ela exceda o limite e falhe:

  • uma longa lista de operadores binários que são encadeados. Por exemplo:
T 
| where Column == "value1" or 
        Column == "value2" or 
        .... or
        Column == "valueN"

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

T 
| where Column in ("value1", "value2".... "valueN")
  • uma consulta que tem um operador union executando uma análise de esquema muito grande, especialmente que a variante de union padrão é retornar o esquema de union "externo" (ou seja, essa saída incluirá todas as colunas da tabela subjacente).

A sugestão, nesse caso, é analisar a consulta e reduzir as colunas que estão sendo usadas por ela.

Conteúdo relacionado