Práticas recomendadas para consultas Linguagem de Consulta Kusto

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

Resumindo

Ação	Usar	Não usar	Observações
Reduzir a quantidade de dados que estão sendo consultados	Use mecanismos como o where operador para reduzir a quantidade de dados que estão sendo processados.		Veja abaixo maneiras eficientes de reduzir a quantidade de dados que estão sendo processados.
Evite usar referências qualificadas redundantes	Ao referenciar entidades locais, use o nome não qualificado.		Veja abaixo para obter mais informações sobre o assunto.
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 unix, como unixtime_milliseconds_todatetime(). Em vez disso, use políticas de atualização para converter o tempo de unix no tipo de dados durante a datetime ingestão.
Operações de cadeia de caracteres	Use 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	Se você pode usar has/has_cs e não usar contains/contains_cs, é ainda melhor.
Pesquisar texto	Examinar 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.		Dessa forma, você pagará 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"	Dessa forma, você filtra a maioria dos registros e faz a análise JSON somente do 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 a mais de 1 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 associados em conjuntos de dados desconhecidos pode gerar GBs de resultados a serem retornados ao cliente, resultando em uma resposta lenta e um cluster 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 do operador summarize estiver com alta cardinalidade.		Alta cardinalidade é, idealmente, acima de 1 milhão.
operador join	Selecione a tabela com menos linhas para ser a primeira (mais à esquerda na consulta).
	Use in em vez da semi join esquerda para filtragem por uma única coluna.
Unir entre clusters	Entre clusters, execute a consulta no lado "direito" da união, onde a maioria dos dados está localizada.
Unir quando o lado esquerdo for pequeno e o lado direito for grande	Use hint.strategy=broadcast		Small refere-se a até 100 MB de dados.
Junção quando o lado direito é pequeno e o lado esquerdo é grande	Usar o operador de pesquisa em vez do join operador		Se o lado direito da pesquisa for maior que várias dezenas de MBs, a consulta falhará.
Unir quando os dois lados são muito grandes	Usar 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 parse	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 reduzirão o conjunto de dados materializado e ainda manterão 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. Preferir usar a materialized_view() função somente para consultar a 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 precisa processar. Quanto menos dados forem processados, mais rápido será a consulta (e menos recursos consumirá). Portanto, a melhor prática mais importante é estruturar a consulta de forma a reduzir a quantidade de dados que estão sendo processados.

Observação

Na discussão abaixo, é importante ter em mente o conceito de seletividade de filtro. Seletividade é qual porcentagem dos registros são filtrados ao filtrar por algum predicado. Um predicado altamente seletivo significa que apenas alguns registros permanecem após a aplicação do predicado, reduzindo a quantidade de dados que precisam ser processados efetivamente.

Em ordem de importância:

• Somente 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 de um ponto de exibição de desempenho referenciar apenas um punhado de tabelas, em vez de usar um curinga (*) para referenciar 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 por escopo de acordo com a política de cache (o parâmetro DataScope ).

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

• Ao usar o where operador de consulta, um uso criterioso da ordem dos predicados (em um único operador ou com vários operadores consecutivos, não importa qual) pode ter um efeito significativo no desempenho da consulta, conforme explicado abaixo.

• Aplique predicados de fragmento inteiro primeiro. Isso significa que predicados que usam a função extent_id() devem ser aplicados primeiro, assim como predicados que usam a função extent_tags() e predicados que são muito seletivos sobre as partições de dados da tabela (se definidas).

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

• Em seguida, aplique predicados que atuam sobre string colunas e dynamic , especialmente esses predicados que se aplicam no nível do termo. Os predicados devem ser ordenados pela seletividade (por exemplo, pesquisar uma ID de usuário quando há milhões de usuários é muito seletivo e geralmente é 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 fim, para consultas que verificam os dados de uma coluna de tabela (por exemplo, para predicados como 'contém "@!@!" que não têm termos e não se beneficiam da indexação), ordene os predicados de modo que os que examinam colunas com menos dados sejam os primeiros. Isso reduz a necessidade de descompactar e examinar colunas grandes.

Evite usar referências qualificadas redundantes

Entidades como tabelas e exibições materializadas são referenciadas 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("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. Referenciar entidades de banco de dados no escopo é sempre pelo menos tão rápido e, em alguns casos, muito mais rápido, em seguida, entidades que pertencem a outros bancos de dados (especialmente quando esses bancos de dados estão em um cluster diferente).) Evitar nomes qualificados ajuda o leitor a fazer a coisa certa.

Observação

Isso não quer dizer que nomes qualificados sejam ruins para o desempenho. Na verdade, o 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-circuito" da consulta para que ela não seja considerada como uma consulta entre clusters. No entanto, recomendamos não confiar nisso quando não for necessário, pelos motivos especificados acima.