Limites de consulta

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

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

de simultaneidade de solicitações é um limite imposto a várias solicitações em execução 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.
• 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 banco de dados depende de vários fatores. 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. A política pode ser configurada com base em testes de carga realizados em padrões de uso semelhantes aos da produção.

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

de truncamento de resultados é um limite definido por padrão no conjunto de resultados retornado 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 geral dos dados 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).'

Existem várias estratégias para lidar com 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. 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 usar de exportação de dados quando quiser exportar grandes conjuntos de dados do serviço.
• Instrua o serviço a suprimir esse limite de consulta usando set instruções listadas abaixo ou sinalizadores em propriedades de solicitação de cliente.

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

• Use o operador resumir grupo e agregue registros 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 é possível ter um controle mais refinado sobre o truncamento de resultados definindo o valor de truncationmaxsize (tamanho máximo de dados em bytes, padrão para 64 MB) e truncationmaxrecords (número máximo de registros, padrão para 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.

Kusto fornece um número de 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 .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.

Você também pode achar o aplicativo de exemplo de ingestão de streaming C# ú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 Eventhouse emite para outro Eventhouse em uma consulta entre Eventhouse, com efeitos semelhantes.

Definindo propriedades de truncamento de vários resultados

O seguinte se aplica ao usar instruções set e/ou ao especificar sinalizadores em propriedades de solicitação de cliente.

• Se notruncation estiver definido e qualquer um dos truncationmaxsize, truncationmaxrecordsou query_take_max_records também estiver definido - notruncation será ignorado.
• Se truncationmaxsize, truncationmaxrecords e/ou query_take_max_records forem definidas várias vezes - aplica-se o menor valor para cada propriedade.

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

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ó) e pode ser aumentado definindo a opção de solicitação maxmemoryconsumptionperiterator:

set maxmemoryconsumptionperiterator=16106127360;
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 será aplicado.

O valor máximo suportado para esta opção de solicitação é 32212254720 (30 GB).

Um limite adicional que pode acionar uma falha de consulta parcial E_RUNAWAY_QUERY é um limite no tamanho máximo acumulado de cadeias de caracteres mantidas por um único operador. Este 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, muito provavelmente o operador de consulta relevante é um join, summarizeou make-series. Para contornar o limite, deve-se modificar a consulta para usar a consulta shuffle estratégia. (É provável que isso também melhore 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. As duas consultas abaixo 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 | ...

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 limite

• 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. Em outras ocasiões, você pode querer limitar os recursos da 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 à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 essa propriedade for definida 100%, todas as CPUs serão atribuídas em cada nó. Por exemplo, 16 CPUs implantadas em nós do Azure D14. Quando essa propriedade é definida como 50%, metade das CPUs será usada e assim por diante. 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 exceder um limite interno, a consulta será considerada muito complexa para processamento e falhará 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 de união que está executando uma análise de esquema muito ampla, especialmente que o sabor padrão de união é retornar o esquema de união "externa" (o que significa – essa saída incluirá 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