Práticas recomendadas para consultas da Linguagem de Consulta Kusto

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

Veja várias melhores práticas que você pode seguir para fazer com que sua consulta seja executada mais rapidamente.

Em suma

Ação	Usar	Não usar	Observações
Reduza 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 datetime tipo de dados.	Não use o long tipo de dados.	Em consultas, não use funções de conversão de tempo do Unix, como unixtime_milliseconds_todatetime(). Em vez disso, use políticas de atualização para converter o tempo do Unix no tipo de dados durante a datetime ingestão.
operadoresString	Usar o operador has.	Não use contains	Ao procurar tokens completos, has funciona melhor pois não procura substrings.
Operadores que diferenciam maiúsculas de minúsculas	Use ==.	Não use =~.	Use operadores que diferenciam maiúsculas de minúsculas quando possível.
	Use in.	Não use in~.
	Use contains_cs.	Não use contains.	O uso has/has_cs é preferível a .contains/contains_cs
Pesquisar texto	Procure em uma coluna específica.	Não use *.	* faz uma pesquisa de texto completa 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.		Com este método, você paga apenas uma vez pela extração da coluna.
Pesquisar por pares chave/valor raros em objetos dinâmicos	Use 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 faz apenas a análise JSON no restante.
instrução 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(), confira materialize(). Para obter mais informações, consulte Otimizar consultas que usam expressões nomeadas.
Aplicar conversões de tipo em mais de um bilhão de registros	Reformate a consulta a fim de reduzir a quantidade de dados inseridos na conversão.	Não converta grandes quantidades de dados se puder evitar.
Novas consultas	Use limit [small number] ou count no final.		A execução de consultas não associadas 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 letras maiúsculas e minúsculas	Use Col =~ "lowercasestring".	Não use tolower(Col) == "lowercasestring".
Comparar dados que já estão em letras minúsculas (ou maiúsculas)	Col == "lowercasestring" (ou Col == "UPPERCASESTRING").	Evite usar comparações que não diferenciam letras maiúsculas e minúsculas.
Filtragem em colunas	Filtre em uma coluna da tabela.	Não filtre em uma coluna calculada.
	Use T | where predicate(*Expression*).	Não use T | extend _value = *Expression* | where predicate(_value)
operador summarize	Use hint.shufflekey =<key> quando o group by keys summarize operador tiver alta cardinalidade.		A alta cardinalidade é idealmente superior a um milhão.
Operador de Junção	Selecione a tabela com o menor número de linhas como a primeira (mais à esquerda na consulta).
	Use in em vez de semi join esquerda para filtrar por uma única coluna.
Junção 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 for pequeno e o lado direito for grande	Use hint.strategy=broadcast.		Pequeno refere-se a até 100 megabytes (MB) de dados.
Junte-se quando o lado direito for pequeno e o lado esquerdo for grande	Usar 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 forem muito grandes	Use hint.shufflekey=<key>.		Use quando a chave de união tiver alta cardinalidade.
Extrair valores na coluna com cadeias de caracteres que compartilham o mesmo formato ou padrão	Use o operador de análise.	Não use várias instruções extract().	Por exemplo, valores como "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
função extract()	Use quando as cadeias de caracteres analisadas não seguirem o mesmo formato ou padrão.		Extraia os valores necessários usando um REGEX.
função materialize()	Envie por push 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 apenas colunas obrigatórias do projeto. Para obter mais informações, consulte Otimizar consultas que usam expressões nomeadas.
Usar exibições materializadas	Use exibições materializadas para armazenar agregações comumente usadas. Prefira usar a função para consultar somente a materialized_view() peça materializada.		materialized_view('MV')

Reduza 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 consumirá). Portanto, a prática recomendada mais importante é estruturar a consulta de forma a reduzir 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 filtro. Seletividade é qual porcentagem dos registros é filtrada 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.

Em ordem de importância:

• Somente referenciar tabelas cujos dados são necessários para a consulta. Por exemplo, ao usar o operador com referências de tabela curinga union , é 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 os 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 armazenamento em 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, se você usa um único where operador ou vários operadores consecutivos where , pode ter um efeito significativo no desempenho da consulta.

• Aplique os predicados de fragmento inteiro primeiro. Isso significa que os predicados que usam a função extent_id() e a função extent_tags() devem ser aplicados primeiro. Além disso, quando você tem predicados seletivos que restringem os dados a partições específicas, eles devem ser aplicados primeiro.

• Em seguida, aplique predicados que atuam sobre datetime colunas de tabela. O Kusto inclui um índice eficiente nessas colunas, muitas vezes eliminando completamente fragmentos de dados inteiros sem a necessidade de acessar esses fragmentos.

• Em seguida, aplique predicados que atuam sobre string colunas e dynamic , especialmente os predicados que se aplicam no nível do termo. Ordene os predicados pela seletividade. Por exemplo, pesquisar 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 forma que aqueles que verificam colunas com menos dados sejam os primeiros. Isso reduz a necessidade de descompactar e escanear 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 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).

É 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 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 pertencente ao banco de dados no escopo. No entanto, não recomendamos confiar nisso quando não for necessário.