Consultas entre clusters e entre bancos de dados

  • Artigo

As consultas são executadas com um banco de dados específico designado como o banco de dados no contexto. Esse banco de dados atua como o padrão para verificação de permissões. Se uma entidade for referenciada em uma consulta sem especificar o cluster ou o banco de dados, ela será resolvida nesse banco de dados.

Este artigo explica como executar consultas que envolvem entidades localizadas fora do banco de dados de contexto atual.

Pré-requisitos

Identificar o cluster e o banco de dados no contexto

A tabela a seguir explica como identificar o banco de dados no contexto por ambiente de consulta.

Ambiente Banco de dados no contexto
Kusto Explorer O banco de dados padrão é o selecionado no painel de conexões e o cluster atual é o cluster que contém esse banco de dados.
Interface do usuário da Web do Azure Data Explorer O banco de dados padrão é o selecionado no painel de conexão e o cluster atual é o cluster que contém esse banco de dados.
Bibliotecas de clientes O banco de dados e o Data Source cluster padrão são especificados pelas propriedades e Initial Catalog das cadeias de conexão do Kusto.

Executar consultas entre clusters ou entre bancos de dados

Para acessar entidades fora do banco de dados no contexto, use as funções cluster() e database() para qualificar o nome da entidade.

Para uma tabela em um banco de dados diferente dentro do mesmo cluster:

database("<DatabaseName>").<TableName>

Para uma tabela em um cluster remoto:

cluster("<ClusterName>").database("<DatabaseName>").<TableName>

Observação

Para executar uma consulta, você deve ter permissão de visualizador para o banco de dados padrão e para todos os outros bancos de dados referenciados na consulta. Para obter mais informações, consulte Controle de acesso baseado em função do Kusto.

Dica

O número de registros retornados de uma consulta é limitado por padrão, mesmo que não haja nenhum uso específico do take operador. Para aumentar o limite, use a opção de solicitação do cliente notruncation . Para saber mais, confira Limites de consulta.

Nomes qualificados e o operador de união

Quando um nome qualificado aparece como um operando do operador union, os curingas podem ser usados para especificar várias tabelas e vários bancos de dados. Curingas não são permitidos em nomes de cluster.

union withsource=TableName *, database("OtherDb*").*Table, cluster("OtherCluster").database("*").*

Observação

O nome do banco de dados padrão também é uma possível correspondência, portanto database("*") , especifica todas as tabelas de todos os bancos de dados, incluindo o padrão.

Nomes qualificados e instruções de acesso restritas

Nomes ou padrões qualificados também podem ser incluídos na instrução restrict access . Curingas em nomes de cluster não são permitidos.

A consulta a seguir restringe o acesso à consulta às seguintes entidades:

  • Qualquer nome de entidade começando com meu... no banco de dados padrão.
  • Qualquer tabela em todos os bancos de dados chamada MyOther... do cluster atual.
  • Qualquer tabela em todos os bancos de dados chamada my2... no cluster OtherCluster.kusto.windows.net.
restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

Manipular alterações de esquema de entidades remotas

Para processar uma consulta entre clusters, o cluster que executa a interpretação de consulta inicial precisa ter o esquema das entidades referenciadas em clusters remotos. Para obter essas informações, um comando é enviado para recuperar os esquemas, que são armazenados em um cache.

No caso de uma alteração de esquema no cluster remoto, um esquema armazenado em cache pode ficar desatualizado. Isso pode levar a efeitos indesejados, incluindo cenários em que colunas novas ou excluídas causam um Partial query failure. Para resolver esses problemas, atualize manualmente o esquema com o comando .clear cache remote-schema .

Funções e exibições

Funções e exibições (persistentes e criadas embutidas) podem referenciar tabelas entre limites de banco de dados e cluster. O código a seguir é válido.

let MyView = Table1 join database("OtherDb").Table2 on Key | join cluster("OtherCluster").database("SomeDb").Table3 on Key;
MyView | where ...

Funções persistentes e exibições podem ser acessadas de outro banco de dados no mesmo cluster.

Por exemplo, digamos que você crie a seguinte função tabular (exibição) em um banco de dados OtherDb:

.create function MyView(v:string) { Table1 | where Column1 has v ...  }

Em seguida, você cria a seguinte função escalar em um banco de dados OtherDb:

.create function MyCalc(a:double, b:double, c:double) { (a + b) / c }

No banco de dados padrão, essas entidades podem ser referenciadas da seguinte maneira:

database("OtherDb").MyView("exception") | extend CalCol=database("OtherDb").MyCalc(Col1, Col2, Col3) | take 10

Limitações de chamadas de função entre clusters

Funções tabulares ou exibições podem ser referenciadas entre clusters. As seguintes limitações se aplicam:

  • As funções remotas devem retornar o esquema tabular. As funções escalares só podem ser acessadas no mesmo cluster.
  • As funções remotas podem aceitar apenas argumentos escalares. As funções que obtêm um ou mais argumentos de tabela só podem ser acessadas no mesmo cluster.
  • O esquema de resultado das funções remotas deve ser corrigido (conhecido com antecedência sem executar partes da consulta). Isso impede o uso de constructos de consulta, como o pivot plug-in. (Observe que alguns plug-ins, como o bag_unpack plug-in, dão suporte a uma maneira de indicar o esquema de resultado estaticamente e, nesse formulário, ele pode ser usado em chamadas de função entre clusters.)
  • Por motivos de desempenho, o esquema de entidades remotas é armazenado em cache pelo cluster de chamada após a chamada inicial. Portanto, as alterações feitas na entidade remota podem resultar em uma incompatibilidade com as informações de esquema armazenadas em cache, potencialmente levando a falhas de consulta. Para obter mais informações, consulte Consultas entre clusters e alterações de esquema.

Exemplos

A chamada entre clusters a seguir é válida.

cluster("OtherCluster").database("SomeDb").MyView("exception") | count

A consulta a seguir chama uma função MyCalcescalar remota . Essa chamada viola a regra nº 1, portanto, não é válida.

MyTable | extend CalCol=cluster("OtherCluster").database("OtherDb").MyCalc(Col1, Col2, Col3) | take 10

A consulta a seguir chama a função MyCalc remota e fornece um parâmetro tabular. Essa chamada viola a regra nº 2, portanto, não é válida.

cluster("OtherCluster").database("OtherDb").MyCalc(datatable(x:string, y:string)["x","y"] )

A consulta a seguir chama a função SomeTable remota que tem uma saída de esquema variável com base no parâmetro tablename. Essa chamada viola a regra nº 3, portanto, ela não é válida.

Função tabular no OtherDb.

.create function SomeTable(tablename:string) { table(tablename)  }

No banco de dados padrão.

cluster("OtherCluster").database("OtherDb").SomeTable("MyTable")

A consulta a seguir chama a função GetDataPivot remota que tem uma saída de esquema variável com base no plug-in de dados (pivot() tem saída dinâmica). Essa chamada viola a regra nº 3, portanto, ela não é válida.

Função tabular no OtherDb.

.create function GetDataPivot() { T | evaluate pivot(PivotColumn) }

Função tabular no banco de dados padrão.

cluster("OtherCluster").database("OtherDb").GetDataPivot()

Conteúdo relacionado