Partilhar via

Práticas recomendadas para consultas Kusto Query Language

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

Aqui estão várias práticas recomendadas a serem seguidas para tornar sua consulta mais rápida.

Em resumo

Ação Utilização Não utilize Observações
Reduzir a quantidade de dados consultados Use mecanismos como o where operador para reduzir a quantidade de dados que estão sendo processados. Para obter mais informações sobre maneiras eficientes de reduzir a quantidade de dados que estão sendo processados, consulte Reduzir a quantidade de dados que estão sendo processados.
Evite usar referências qualificadas redundantes Ao fazer referência a entidades locais, use o nome não qualificado. Para obter mais informações, consulte Evitar o uso de referências qualificadas redundantes.
datetime colunas Use o tipo de datetime dados. Não use o long tipo de dados. Em consultas, não use funções de conversão de tempo Unix, como unixtime_milliseconds_todatetime(). Em vez disso, use políticas de atualização para converter o tempo do Unix para o tipo de dados durante a datetime ingestão.
Operadores de cadeia de caracteres Utilizar o operador has. Não utilize contains Ao procurar tokens completos, has funciona melhor, já que não procura substrings.
Operadores que diferenciam maiúsculas de minúsculas Utilize ==. Não use =~. Use operadores que diferenciam maiúsculas de minúsculas sempre que possível.
Utilize in. Não use in~.
Utilize contains_cs. Não use contains. Prefere-se usar has/has_cs a .contains/contains_cs
Pesquisa de texto Procure em uma coluna específica. Não use *. * faz uma pesquisa de texto completo em todas as colunas.
Extrair campos de objetos dinâmicos em milhões de linhas Materialize sua coluna no momento da ingestão se a maioria das consultas extrair campos de objetos dinâmicos em milhões de linhas, usando uma política de atualização. Com este método, você paga apenas uma vez pela extração da coluna.
Pesquisa de chaves/valores raros em objetos dinâmicos Utilize MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value". Não use MyTable | where DynamicColumn.SomeKey == "Rare value". Com esse método, você filtra a maioria dos registros e só faz a análise JSON no restante.
let com um valor que você usa mais de uma vez Use a função materialize(). Para obter mais informações sobre como usar materialize()o , consulte materialize(). Para obter mais informações, consulte Otimizar consultas que usam expressões nomeadas.
Aplique conversões de tipo em mais de um bilhão de registros Remodele sua consulta para reduzir a quantidade de dados inseridos na conversão. Não converta grandes quantidades de dados se isso puder ser evitado.
Novas consultas Use limit [small number] ou count no final. A execução de consultas não acopladas em conjuntos de dados desconhecidos pode gerar um retorno de gigabytes de resultados, resultando em uma resposta lenta e um ambiente ocupado.
Comparações que não diferenciam maiúsculas de minúsculas Utilize Col =~ "lowercasestring". Não use tolower(Col) == "lowercasestring".
Comparar dados já em minúsculas (ou maiúsculas) Col == "lowercasestring" (ou Col == "UPPERCASESTRING"). Evite usar comparações que não diferenciam maiúsculas de minúsculas.
Filtragem em colunas Filtrar em uma coluna de tabela. Não filtre em uma coluna calculada.
Utilize T | where predicate(*Expression*) Não utilize T | extend _value = *Expression* | where predicate(_value)
Operador de resumo Use o hint.shufflekey=<key> quando o group by keys do summarize operador tiver alta cardinalidade. Alta cardinalidade é idealmente mais de um milhão.
Junte-se ao operador Selecione a tabela com menos linhas como a primeira (mais à esquerda na consulta).
Use in em vez de semi join esquerda para filtrar por uma única coluna.
Junte-se entre clusters Execute a consulta no lado "direito" da junção em ambientes remotos, como clusters ou Eventhouses, onde a maioria dos dados está localizada.
Junte-se quando o lado esquerdo é pequeno e o lado direito é grande Use hint.strategy=broadcast. Pequeno refere-se a até 100 megabytes (MB) de dados.
Junte-se quando o lado direito é pequeno e o lado esquerdo é grande Use o operador de pesquisa em vez do join operador Se o lado direito da pesquisa for maior que várias dezenas de MB, a consulta falhará.
Junte-se quando ambos os lados são muito grandes Use hint.shufflekey=<key>. Use quando a chave de junção tiver alta cardinalidade.
Extrair valores em coluna com cadeias de caracteres que compartilham o mesmo formato ou padrão Use o operador de análise. Não use várias extract() declarações. Por exemplo, valores como "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
função extract() Use quando as cadeias de caracteres analisadas não seguem todas o mesmo formato ou padrão. Extraia os valores necessários usando um REGEX.
função materialize() Empurre todos os operadores possíveis que reduzem o conjunto de dados materializado e ainda mantêm a semântica da consulta. Por exemplo, filtros ou projetar apenas colunas necessárias. Para obter mais informações, consulte Otimizar consultas que usam expressões nomeadas.
Use visualizações materializadas Use exibições materializadas para armazenar agregações comumente usadas. Prefira usar a função para consultar apenas a materialized_view() parte materializada. materialized_view('MV')

Reduzir a quantidade de dados que estão sendo processados

O desempenho de uma consulta depende diretamente da quantidade de dados que ela precisa processar. Quanto menos dados forem processados, mais rápida será a consulta (e menos recursos ela consome). Portanto, a prática recomendada mais importante é estruturar a consulta de tal forma que reduza a quantidade de dados que estão sendo processados.

Observação

Na discussão a seguir, é importante ter em mente o conceito de seletividade de filtros. Seletividade é a porcentagem dos registros que são filtrados ao filtrar por algum predicado. Um predicado altamente seletivo significa que apenas um punhado de registros permanece após a aplicação do predicado, reduzindo a quantidade de dados que precisam ser processados de forma eficaz.

Por ordem de importância:

  • Apenas tabelas de referência cujos dados são necessários para a consulta. Por exemplo, ao usar o union operador com referências de tabela curinga, é melhor, do ponto de vista do desempenho, fazer referência apenas a algumas tabelas, em vez de usar um curinga (*) para fazer referência a todas as tabelas e, em seguida, filtrar dados usando um predicado no nome da tabela de origem.

  • Aproveite o escopo de dados de uma tabela se a consulta for relevante apenas para um escopo específico. A função table() fornece uma maneira eficiente de eliminar dados, definindo-os de acordo com a política de cache (o parâmetro DataScope ).

  • Aplique o operador de consulta imediatamente após as where referências de tabela.

  • Ao usar o where operador de consulta, a ordem na qual você coloca os predicados, quer você use um único where operador ou vários operadores consecutivos where , pode ter um efeito significativo no desempenho da consulta, Em muitos casos, o otimizador de consulta organizará automaticamente os predicados em uma ordem eficiente. No entanto, isso nem sempre é garantido — então, quando isso não acontece, você deve ordenar manualmente os predicados de acordo com as diretrizes nos próximos pontos.

  • Aplique predicados que atuam sobre as colunas da datetime tabela primeiro. Kusto inclui um índice eficiente em tais colunas, muitas vezes eliminando completamente fragmentos de dados inteiros sem a necessidade de acessar esses fragmentos.

  • Em seguida, aplique predicados que atuam sobre string e dynamic colunas, especialmente tais predicados que se aplicam no nível do termo. Ordenar os predicados pela seletividade. Por exemplo, a pesquisa por um ID de usuário quando há milhões de usuários é altamente seletiva e geralmente envolve uma pesquisa de termos, para a qual o índice é muito eficiente.

  • Em seguida, aplique predicados que são seletivos e são baseados em colunas numéricas.

  • Por último, para consultas que verificam os dados de uma coluna de tabela (por exemplo, para predicados como contains"@!@!", que não têm termos e não se beneficiam da indexação), ordene os predicados de modo que aqueles que examinam colunas com menos dados sejam os primeiros. Isso reduz a necessidade de descomprimir e digitalizar colunas grandes.

Evite usar referências qualificadas redundantes

Entidades de referência, como tabelas e exibições materializadas por nome.

Por exemplo, a tabela T pode ser referenciada como simplesmente T (o nome não qualificado ), ou usando um qualificador de banco de dados (por exemplo, database("DB").T quando a tabela está em um banco de dados chamado DB), ou usando um nome totalmente qualificado (por exemplo, cluster("<serviceURL>").database("DB").T).

Por exemplo, a tabela T pode ser referenciada como simplesmente T (o nome não qualificado ), ou usando um qualificador de banco de dados (por exemplo, database("DB").T quando a tabela está em um banco de dados chamado DB), ou usando um nome totalmente qualificado (por exemplo, cluster("X.Y.kusto.windows.net").database("DB").T).

É uma prática recomendada evitar o uso de qualificações de nome quando elas são redundantes, pelos seguintes motivos:

  1. Nomes não qualificados são mais fáceis de identificar (para um leitor humano) como pertencentes ao banco de dados no escopo.

  2. A referência a entidades de banco de dados no escopo é sempre pelo menos tão rápida e, em alguns casos, muito mais rápida do que entidades que pertencem a outros bancos de dados.

Isso é especialmente verdadeiro quando esses bancos de dados estão em um cluster diferente.

Isso é especialmente verdadeiro quando esses bancos de dados estão em uma Eventhouse diferente.

Evitar nomes qualificados ajuda o leitor a fazer a coisa certa.

Observação

Isso não significa que nomes qualificados sejam ruins para o desempenho. Na verdade, Kusto é capaz na maioria dos casos de identificar quando um nome totalmente qualificado faz referência a uma entidade que pertence ao banco de dados no escopo e "curto-circuitar" a consulta para que ela não seja considerada como uma consulta entre clusters. No entanto, não recomendamos confiar nisso quando não for necessário.

Observação

Isso não significa que nomes qualificados sejam ruins para o desempenho. Na verdade, Kusto é capaz na maioria dos casos de identificar quando um nome totalmente qualificado faz referência a uma entidade pertencente ao banco de dados no escopo. No entanto, não recomendamos confiar nisso quando não for necessário.

  • Last updated on