Compartilhar via

Otimizar para alta simultaneidade com Azure Data Explorer

  • Artigo

Aplicativos altamente simultâneos são necessários em cenários com uma grande base de usuários, em que o aplicativo lida simultaneamente com muitas solicitações com baixa latência e alta taxa de transferência.

Os casos de uso incluem painéis de alerta e monitoramento em larga escala. Os exemplos incluem produtos e serviços da Microsoft, como o Azure Monitor, o Azure Time Series Insights e o Playfab. Todos esses serviços usam o Azure Data Explorer para atender a cargas de trabalho de alta simultaneidade. O Azure Data Explorer é um serviço de análise de Big Data rápido e totalmente gerenciado para análise em tempo real de grandes volumes de streaming de dados de aplicativos, sites, dispositivos IoT e muito mais.

Observação

O número real de consultas que podem ser executadas simultaneamente em um cluster depende de fatores como o SKU do cluster, os volumes de dados, a complexidade de consulta e os padrões de uso.

Para configurar aplicativos de alta simultaneidade, projete a arquitetura de back-end da seguinte forma:

Este artigo apresenta recomendações para cada um dos assuntos anteriores que você pode implementar para obter alta simultaneidade de forma econômica e otimizada. Esses recursos podem ser utilizados sozinhos ou combinados.

Otimizar dados

Para alta simultaneidade, as consultas devem consumir a menor quantidade possível de recursos da CPU. Você pode usar qualquer um dos seguintes métodos, ou todos eles:

Usar práticas recomendadas de design de esquema de tabela

Use as seguintes sugestões de design de esquema de tabela para minimizar os recursos de CPU usados:

  • As colunas de ID devem ser definidas como tipos de dados de cadeia de caracteres, independentemente de os valores serem numéricos. A indexação para colunas de cadeia de caracteres é mais sofisticada do que para colunas numéricas e fornece melhor desempenho de filtragem.
  • Combine de forma otimizada o tipo de dados da coluna e os dados reais armazenados nelas. Por exemplo, não armazene valores datetime em uma coluna de cadeia de caracteres.
  • Evite uma tabela grande esparsa com muitas colunas, e use colunas dinâmicas para armazenar propriedades esparsas.
  • Armazene as propriedades usadas com frequência em sua própria coluna com um tipo de dados não dinâmico.
  • Desnormalize os dados para evitar junções que exijam recursos relativamente grandes da CPU.

Dados de partição

Os dados são armazenados na forma de extensão (fragmentos de dados) e, por padrão, são particionados por tempo de ingestão. Você pode usar a política de particionamento para reparticionar as extensão com base em uma única coluna de cadeia de caracteres ou de datetime em um processo em segundo plano. O particionamento pode fornecer melhorias significativas de desempenho quando a maioria das consultas usar chaves de partição para filtrar, agregar ou ambos.

Observação

O próprio processo de particionamento usa recursos de CPU. No entanto, a redução da CPU durante o tempo de consulta deve superar a CPU usada para o particionamento.

Pré-agregar seus dados com exibições materializadas

Pré-agregue seus dados para reduzir significativamente os recursos da CPU durante o tempo de consulta. Os cenários de exemplo incluem o resumo dos pontos de dados em um número reduzido de compartimentos de tempo, a manutenção do registro mais recente de um determinado registro ou a eliminação da duplicação do conjuntos de dados. Use as exibições materializadas para uma exibição agregada fácil de configurar em tabelas de origem. Esse recurso simplifica o esforço de criar e manter essas exibições agregadas.

Observação

O processo de agregação em segundo plano usa recursos de CPU. No entanto, a redução da CPU durante o tempo de consulta deve superar o consumo de CPU para a agregação.

Configurar as políticas de cache

Configure a política de cache para que as consultas sejam executadas em dados armazenados no armazenamento frequente, também conhecido como cache de disco. Execute apenas cenários limitados e cuidadosamente projetados nas tabelas de armazenamento frio ou externo.

Definir um padrão de arquitetura de líder-seguidor

O banco de dados seguidor é um recurso que segue um banco de dados ou um conjunto de tabelas em um banco de dados de outro cluster localizado na mesma região. Esse recurso é exposto por meio do Azure Data Share, das APIs do Azure Resource Manager e por um conjunto de comandos do cluster.

Use o padrão líder-seguidor para definir recursos de computação para diferentes cargas de trabalho. Por exemplo, configurar um cluster para ingestões, um cluster para consultar ou atender a painéis ou aplicativos, e um cluster que atenda às cargas de trabalho de ciência de dados. Cada carga de trabalho, nesse caso, terá recursos de computação dedicados que podem ser dimensionados de forma independente, e configurações de cache e segurança diferentes. Todos os clusters usam os mesmos dados, com o líder escrevendo os dados e os seguidores usando-os em um modo somente leitura.

Observação

Os bancos de dados seguidores têm um atraso em relação ao líder, geralmente de alguns segundos. Se sua solução exigir os dados mais recentes sem latência, essa solução poderá ser útil. Use uma exibição no cluster do seguidor que una os dados do líder e do seguidor, e consulte os dados mais recentes do líder e o restante dos dados do seguidor.

Para melhorar o desempenho de consultas no cluster do seguidor, você pode habilitar a configuração de extensão de pré-busca. Use essa configuração com cuidado, pois isso pode afetar a atualidade dos dados no banco de dados dos seguidores.

Otimizar consultas

Use os métodos a seguir para otimizar suas consultas para alta simultaneidade.

Siga as práticas recomendadas de consulta para que suas consultas sejam o mais eficientes possível.

Usar um cache de resultados de consulta

Quando mais de um usuário carrega o mesmo painel em momentos próximos, o painel para o segundo usuário e para os usuários seguidores podem ser atendidos pelo cache. Essa configuração fornece alto desempenho com quase nenhum uso de CPU. Use o recurso de cache de resultados da consulta e envie a configuração de cache de resultados da consulta, juntamente com a consulta, usando a instrução set.

O Grafana contém uma definição de configuração para o cache de resultados da consulta no nível da fonte de dados, portanto, todos os painéis usam essa configuração por padrão e não precisam modificar a consulta.

Configurar a consistência da consulta

O modo de coerência de consulta padrão é forte. Nesse modo, um nó de administrador gerencia metadados e ingestão para o cluster, bem como planejamento de consulta e delegação da execução para outros nós.

Em aplicativos de alta simultaneidade, o gerenciamento de consultas pode fazer com que o uso da CPU do nó de administrador seja alto, enquanto outros nós estão menos ocupados. Isso pode causar um gargalo no qual não é possível aumentar o número de consultas simultâneas. No entanto, isso pode não estar aparente no relatório de CPU do cluster (portal do Azure > {your_cluster} > Métricas > Métrica de CPU), que mostra o uso médio da CPU do cluster.

Nesse cenário, é recomendável usar o modo de coerência fraca. Nesse modo, mais nós podem gerenciar consultas, o que possibilita escalar horizontalmente o número de consultas simultâneas. Os nós nesse modo atualizam periodicamente a cópia de metadados e dados recém-ingeridos, o que leva a uma latência de normalmente menos de um minuto à medida que os dados são sincronizados. No entanto, essa latência curta é preferível à situação de gargalo que pode surgir ao usar o modo de coerência forte.

Você pode definir o modo de consistência em uma política de consistência de consulta de grupo de carga de trabalho, nas propriedades de solicitação do cliente ou na configuração da fonte de dados do Grafana.

Definir as políticas do cluster

O número de solicitações simultâneas é limitado por padrão e controlado pela política de limite de taxa de solicitação para que o cluster não fique sobrecarregado. Você pode ajustar essa política para situações de alta simultaneidade. Essa política deve ser ajustada somente após testes rigorosos, preferencialmente em padrões de uso e conjuntos de dados semelhantes aos de produção. O teste garante que o cluster possa sustentar o valor modificado. Esse limite pode ser configurado com base nas necessidades do aplicativo.

Monitorar os clusters do Azure Data Explorer

Monitorar a integridade dos recursos do cluster ajuda você a criar um plano de otimização usando os recursos sugeridos nas seções anteriores. O Azure Monitor para Azure Data Explorer fornece uma exibição abrangente do desempenho, das operações, do uso e das falhas do cluster. Obter insights sobre o desempenho das consultas, consultas simultâneas, consultas limitadas e várias outras métricas selecionando a guia Insights (versão prévia) na seção Monitoramento do cluster do Azure Data Explorer no portal do Azure.

Para obter informações sobre o monitoramento de clusters, consulte Azure Monitor para Azure Data Explorer. Para obter informações sobre as métricas individuais, consulte Métricas do Azure Data Explorer.