Consultas entre clusters e várias bases de dados

  • Artigo

As consultas são executadas com uma base de dados específica designada como base de dados em contexto. Esta base de dados funciona como a predefinição para a verificação de permissões. Se uma entidade for referenciada numa consulta sem especificar o cluster ou a base de dados, esta será resolvida nesta base de dados.

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

Pré-requisitos

Identificar o cluster e a base de dados no contexto

A tabela seguinte explica como identificar a base de dados em contexto por ambiente de consulta.

Ambiente Base de dados em contexto
Kusto Explorer A base de dados predefinida é a selecionada no painel de ligações e o cluster atual é o cluster que contém essa base de dados.
IU da Web do Azure Data Explorer A base de dados predefinida é a selecionada no painel de ligação e o cluster atual é o cluster que contém essa base de dados.
Bibliotecas de cliente A base de dados e o Data Source cluster predefinidos são especificados pelas propriedades e Initial Catalog das cadeias de ligação do Kusto.

Executar consultas entre clusters ou várias bases de dados

Para aceder a entidades fora da base de dados em contexto, utilize as funções cluster() e database() para qualificar o nome da entidade.

Para uma tabela numa base de dados diferente no mesmo cluster:

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

Para uma tabela num cluster remoto:

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

Nota

Para executar uma consulta, tem de ter permissão de visualizador para a base de dados predefinida e para todas as outras bases de dados referenciadas na consulta. Para obter mais informações, veja Controlo de acesso baseado em funções do Kusto.

Dica

O número de registos devolvidos de uma consulta é limitado por predefinição, mesmo que não exista uma utilização específica do take operador. Para aumentar este limite, utilize a opção de pedido de notruncation cliente. Para obter mais informações, veja Limites de consulta.

Nomes qualificados e o operador sindical

Quando um nome qualificado aparece como um operando do operador união, os carateres universais podem ser utilizados para especificar várias tabelas e várias bases de dados. Os carateres universais não são permitidos em nomes de cluster.

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

Nota

O nome da base de dados predefinida também é uma correspondência potencial, pelo database("*") que especifica todas as tabelas de todas as bases de dados, incluindo a predefinição.

Nomes qualificados e instruções de acesso restritas

Os nomes ou padrões qualificados também podem ser incluídos na instrução de acesso restrito . Não são permitidos carateres universais em nomes de cluster.

A consulta seguinte restringe o acesso de consulta às seguintes entidades:

  • Qualquer nome de entidade que comece com o meu... na base de dados predefinida.
  • Qualquer tabela em todas as bases de dados denominada MyOther... do cluster atual.
  • Qualquer tabela em todas as bases de dados com o nome my2... no cluster OtherCluster.kusto.windows.net.
restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

Processar alterações de esquema de entidades remotas

Para processar uma consulta entre clusters, o cluster que executa a interpretação da consulta inicial tem de ter o esquema das entidades referenciado em clusters remotos. Para obter estas informações, é enviado um comando para obter os esquemas, que são depois armazenados numa cache.

No caso de uma alteração de esquema no cluster remoto, um esquema em cache pode ficar desatualizado. Isto pode levar a efeitos indesejáveis, incluindo cenários em que colunas novas ou eliminadas causam um Partial query failure. Para resolver estes problemas, atualize manualmente o esquema com o comando .clear cache remote-schema .

Funções e vistas

As funções e vistas (persistentes e criadas inline) podem referenciar tabelas entre os limites da base de dados e do cluster. O código seguinte é válido.

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

As funções e vistas persistentes podem ser acedidas a partir de outra base de dados no mesmo cluster.

Por exemplo, digamos que cria a seguinte função tabular (vista) numa base de dados OtherDb:

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

Em seguida, crie a seguinte função escalar numa base de dados OtherDb:

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

Na base de dados predefinida, estas entidades podem ser referenciadas da seguinte forma:

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

Limitações das chamadas entre funções de cluster

As funções tabulares ou as vistas podem ser referenciadas entre clusters. Aplicam-se as seguintes limitações:

  • As funções remotas têm de devolver o esquema tabular. As funções escalares só podem ser acedidas no mesmo cluster.
  • As funções remotas só podem aceitar argumentos escalares. As funções que obtêm um ou mais argumentos de tabela só podem ser acedidas no mesmo cluster.
  • O esquema de resultado das funções remotas tem de ser fixo (conhecido antecipadamente sem executar partes da consulta). Isto impede a utilização de construções de consulta, como o pivot plug-in. (Tenha em atenção que alguns plug-ins, como o bag_unpack plug-in, suportam uma forma de indicar o esquema de resultados estaticamente e, neste formato, podem ser utilizados em chamadas de funções entre clusters.)
  • Por motivos de desempenho, o esquema de entidades remotas é colocado em cache pelo cluster de chamadas após a chamada inicial. Por conseguinte, as alterações efetuadas à entidade remota podem resultar num erro de correspondência com as informações de esquema em cache, o que pode levar a falhas de consulta. Para obter mais informações, veja Consultas entre clusters e alterações de esquema.

Exemplos

A seguinte chamada entre clusters é válida.

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

A consulta seguinte chama uma função MyCalcescalar remota . Esta chamada viola a regra n.º 1, pelo que não é válida.

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

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

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

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

Função tabular em OtherDb.

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

Na base de dados predefinida.

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

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

Função tabular em OtherDb.

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

Função tabular na base de dados predefinida.

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

Conteúdo relacionado