Como arquitetar uma solução multilocatário com Azure Data Explorer

O conceito de multilocação no Azure Data Explorer refere-se ao atendimento de diferentes locatários e ao armazenamento de seus dados em um único cluster.

Importante

Uma solução multilocatário também pode ser arquitetada na carga de trabalho Real-Time Intelligence da Microsoft Fabric, usando bancos de dados KQL dentro de um Eventhouse.

Um locatário pode representar um cliente, um grupo de usuários ou qualquer classificação de usuários em que os dados precisam ser segregados ao longo dos limites dos locatários. Você também pode ter um cenário multilocatário de vários níveis, como vários aplicativos que têm vários locatários. Este artigo não aborda esse cenário, mas princípios semelhantes se aplicam.

Um fator importante é a maneira como os usuários finais acessam seus dados de locatário. Quando os usuários finais acessam o Azure Data Explorer diretamente, o controle de acesso deve ser configurado no Azure Data Explorer para limitar a visualização do usuário aos seus próprios dados. Quando um aplicativo proxy acessa seus dados no Azure Data Explorer, o aplicativo pode fazer o isolamento.

Este artigo descreve algumas arquiteturas de implantação e fornece características para cada uma. Você pode usar as características para ajudá-lo a decidir qual arquitetura funciona melhor para sua solução.

Vizinho barulhento

Em geral, compartilhar um cluster entre muitos locatários, independentemente da arquitetura usada, significa que diferentes locatários compartilham os recursos do cluster. Isso pode levar ao antipadrão do vizinho ruidoso.

Por exemplo, se um locatário executar muitas consultas ou ingestões com uso intensivo de computação, outros locatários provavelmente serão afetados pela falta de recursos. Isso pode ser atenuado usando grupos de carga de trabalho. Você também pode usar políticas para controlar o cache e o armazenamento geral.

Visão geral das arquiteturas

As próximas seções exploram as arquiteturas de implantação em detalhes. Esta seção contrasta as arquiteturas para facilitar a tomada de decisões.

Architecture	Strengths
Um locatário por banco de dados	- Isolamento dos inquilinos: sem necessidade de proxy - Pode ter políticas diferentes, como políticas de retenção, por locatário - Flexibilidade na evolução do esquema por locatário - Remoção fácil e rápida de dados de locatários
Uma tabela para muitos inquilinos	- Consolidação de dados eficiente e gerenciamento de extensões - Evolução simplificada do esquema - Mais adequado para visualizações materializadas - Ideal para particionamento
Um locatário por tabela em um único banco de dados	Não recomendado

Arquitetura: Um locatário por banco de dados

Esta é uma arquitetura popular e simples. Cada locatário obtém seu próprio banco de dados. Cada banco de dados tem o mesmo esquema.

As características desta arquitetura são:

• Provisionamento de um novo locatário: requer a criação de um novo banco de dados e a implantação de entidades de esquema nele.

• Removendo um locatário: requer a exclusão do banco de dados. A exclusão de um banco de dados pode ser feita em poucos segundos. Consome recursos pequenos e constantes que não são lineares com o volume de dados do locatário.

• Atualizações de esquemas de banco de dados: cada cliente pode ser atualizado independentemente em momentos diferentes. Os aplicativos que acessam os bancos de dados devem estar cientes da versão de cada banco de dados com o qual interagem.

• Políticas de retenção e cache: cada locatário pode ter suas próprias políticas exclusivas, que permitem fornecer políticas personalizadas de retenção e cache para seus clientes.

• Limite de segurança por locatário:

  • Para aplicativo multilocatário (proxy): configure seu aplicativo para endereçar o banco de dados relevante. Use a restrição de acesso em consultas para proibir consultas entre bancos de dados.
  • Para usuários com acesso direto, os usuários podem receber acesso no nível do banco de dados. Dar aos usuários acesso direto ao banco de dados cria uma dependência para os detalhes da implementação, dificultando a alteração da implementação. Portanto, é altamente recomendável usar a abordagem de proxy para acessar o banco de dados.

• Agregação de dados de vários locatários em escala: use o operador union para agregar dados entre bancos de dados. No entanto, esse método pode se tornar complicado à medida que o número de inquilinos aumenta. Embora a agregação de dados de vários locatários possa ser uma meta de design da perspectiva do locatário, pode ser interessante para o proprietário da solução agregar dados de todos os locatários para coletar estatísticas.

• Fragmentação de extensões: cada locatário ingerindo alguns registros por tabela de banco de dados leva à criação de pequenas extensões que precisam ser mescladas posteriormente. Isso resulta em um custo mais alto para o gerenciamento de extensões. Portanto, é altamente recomendável usar ingestão de streaming, como Hubs de Eventos ou Event Grid ingestion. Para usar a ingestão de dados por streaming, você deve assegurar-se de que ela esteja habilitada no cluster e na tabela.

• Visões materializadas e política de particionamento. À medida que o número de locatários aumenta, é importante lembrar que há limites para o número de views materializadas e políticas de partição que um cluster pode executar de forma eficiente.

• Conexões de dados da Grade de Eventos e dos Hubs de Eventos: essas conexões de dados são criadas por banco de dados. Portanto, essa arquitetura requer por locatário uma conexão de dados e uma instância da Grade de Eventos ou dos Hubs de Eventos, adicionando complexidade ao gerenciamento. Considere usar o roteamento de eventos para Hubs de Eventos e Grade de Eventos.

Arquitetura: uma tabela para muitos locatários

Essa arquitetura é mais agressiva em sua consolidação, utilizando um único banco de dados para todos os locatários. Cada tabela no banco de dados tem uma coluna ID do locatário, ou equivalente, que permite filtrar os dados de um único locatário. Você pode particionar tabelas por locatário para melhorar o desempenho da consulta, já que a maioria das consultas provavelmente será filtrada por locatário. Sempre que possível, você deve considerar a partição com outra coluna usando uma chave de partição composta . Por exemplo, você pode criar uma chave de partição composta concatenando o ID do locatário e os valores de outras colunas.

As características desta arquitetura são:

• Provisionamento de um novo locatário: o provisionamento de um novo locatário não requer nenhuma criação de banco de dados ou ajuste de esquema. A nova ID do locatário é usada em novos registros.

• Removendo um locatário: requer uma exclusão reversível ou limpeza dos dados do locatário. Você pode agrupar várias limpezas em lote, por exemplo, no final da semana para limitar o impacto no consumo de recursos.

• Atualizações de esquemas de banco de dados: o esquema de todos os locatários é atualizado ao mesmo tempo. Como todos os locatários compartilham a tabela, a alteração dos esquemas de tabela altera todos os locatários de uma só vez.

• Políticas de retenção e cache: as políticas são as mesmas para todos os locatários, pois todos compartilham a mesma tabela.

• Limite de segurança por locatário:

  • Para aplicativo multilocatário (proxy): Use a Instrução Restrict
  • Para usuários com acesso direto: use a Política de Segurança em Nível de Linha e familiarize-se com suas limitações. Dar aos usuários acesso direto ao banco de dados cria uma dependência para os detalhes da implementação, dificultando a alteração da implementação. Portanto, é altamente recomendável usar a abordagem de proxy para acessar o banco de dados.

• Agregação de dados de vários locatários em escala: os usuários com permissões de acesso suficientes podem executar uma consulta de agregação padrão nos dados de vários locatários.

• Fragmentação de extensões: como todos os inquilinos ingerem dados na mesma tabela, os dados geralmente podem ser consolidados e ingeridos com eficiência em uma ou algumas extensões.

• Visões materializadas e política de particionamento: elas podem ser usadas em tabelas de multilocação. Você pode melhorar o desempenho particionando na coluna ID do Locatário ou equivalente. Para obter mais informações, consulte Cenários para políticas de partição.

• Conexões de dados da Grade de Eventos e dos Hubs de Eventos: você consolidou conexões de dados, pois os dados de todos os locatários acabam em uma tabela.

Arquitetura: um locatário por tabela em um único banco de dados

Essa arquitetura é uma combinação das arquiteturas anteriores, em que os dados de todos os locatários acabam em um único banco de dados, mas em tabelas separadas. Essa arquitetura não consegue capturar todas as vantagens das outras arquiteturas.

Embora os dados de cada locatário sejam segregados, todos eles residem no mesmo contexto de segurança do mesmo banco de dados. Como a arquitetura de vários bancos de dados, essa arquitetura pode levar à fragmentação de extensão. O nome da tabela é diferente para cada locatário e, portanto, as consultas devem ser personalizadas para cada locatário.

Conteúdo relacionado

• grupos de carga de trabalho
• Controle de acesso baseado em função
• Segurança em Nível de Linha
• Instrução Restrict
• Política de particionamento