Partilhar via

Otimizar para elevada simultaneidade com o Azure Data Explorer

  • Artigo

As aplicações altamente simultâneas são necessárias em cenários com uma grande base de utilizadores, em que a aplicação processa simultaneamente muitos pedidos com baixa latência e débito elevado.

Os casos de utilização incluem dashboards de monitorização e alertas em larga escala. Os exemplos incluem produtos e serviços Microsoft, como o Azure Monitor, Azure Time Series Insights e Playfab. Todos estes serviços utilizam o Azure Data Explorer para servir cargas de trabalho de elevada simultaneidade. O Azure Data Explorer é um serviço de análise de macrodados rápido e totalmente gerido para análises em tempo real em grandes volumes de transmissão de dados a partir de aplicações, sites, dispositivos IoT e muito mais.

Nota

O número real de consultas que podem ser executadas em simultâneo num cluster depende de fatores como o SKU do cluster, volumes de dados, complexidade de consultas e padrões de utilização.

Para configurar aplicações de elevada simultaneidade, crie a arquitetura de back-end da seguinte forma:

Este artigo apresenta recomendações para cada um dos assuntos anteriores que pode implementar para alcançar uma simultaneidade elevada de uma forma ideal e económica. Estas funcionalidades podem ser utilizadas individualmente ou em combinação.

Otimizar dados

Para uma elevada simultaneidade, as consultas devem consumir a quantidade menos possível de recursos da CPU. Pode utilizar qualquer um ou todos os seguintes métodos:

Utilizar as melhores práticas de conceção do esquema de tabela

Utilize as seguintes sugestões de estrutura de esquema de tabela para minimizar os recursos da CPU utilizados:

  • As colunas de ID devem ser definidas como tipos de dados de cadeia, independentemente de os valores serem numéricos. A indexação de colunas de cadeias é mais sofisticada do que para colunas numéricas e proporciona um melhor desempenho de filtragem.
  • Corresponda o tipo de dados da coluna de forma ideal aos dados reais armazenados nestas colunas. Por exemplo, não armazene valores datetime numa coluna de cadeia.
  • Evite uma grande tabela dispersa com muitas colunas e utilize colunas dinâmicas para armazenar propriedades dispersas.
  • Armazene propriedades utilizadas frequentemente na sua própria coluna com um tipo de dados não dinâmico.
  • Desnormalize dados para evitar associações que exigem recursos de CPU relativamente grandes.

Dados de partição

Os dados são armazenados sob a forma de extensões (partições horizontais de dados) e são particionados por tempo de ingestão por predefinição. Pode utilizar a política de criação de partições para criar novas partições com base numa única coluna de cadeia ou numa única coluna datetime num processo em segundo plano. A criação de partições pode proporcionar melhorias de desempenho significativas quando a maioria das consultas utiliza chaves de partição para filtrar, agregar ou ambas.

Nota

O próprio processo de criação de partições utiliza recursos da CPU. No entanto, a redução da CPU durante o tempo de consulta deve superar a CPU utilizada para a criação de partições.

Pré-agregar os seus dados com vistas materializadas

Pré-agregar os seus dados para reduzir significativamente os recursos da CPU durante o tempo de consulta. Os cenários de exemplo incluem resumir pontos de dados sobre um número reduzido de intervalos de tempo, manter o registo mais recente de um determinado registo ou desdulicar o conjunto de dados. Utilize vistas materializadas para uma vista agregada fácil de configurar em tabelas de origem. Esta funcionalidade simplifica o esforço de criar e manter estas vistas agregadas.

Nota

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

Configurar a política de colocação em cache

Configure a política de colocação em 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 concebidos nas tabelas de armazenamento a frio ou externas.

Definir um padrão de arquitetura de seguimento de coordenador

A base de dados de seguidores é uma funcionalidade que segue uma base de dados ou um conjunto de tabelas numa base de dados de outro cluster localizado na mesma região. Esta funcionalidade é exposta através do Azure Data Share, das APIs Resource Manager do Azure e de um conjunto de comandos de cluster.

Utilize o padrão de seguimento de coordenadores para definir recursos de computação para diferentes cargas de trabalho. Por exemplo, configure um cluster para ingestões, um cluster para consultar ou servir dashboards ou aplicações e um cluster que serve as cargas de trabalho de ciência de dados. Neste caso, cada carga de trabalho terá recursos de computação dedicados que podem ser dimensionados de forma independente e diferentes configurações de segurança e colocação em cache. Todos os clusters utilizam os mesmos dados, com o coordenador a escrever os dados e os seguidores a utilizá-lo num modo só de leitura.

Nota

As bases de dados de seguidores têm um atraso em função do caráter de preenchimento, normalmente de alguns segundos. Se a sua solução exigir os dados mais recentes sem latência, esta solução poderá ser útil. Utilize uma vista no cluster de seguidores que agrupa os dados do coordenador e do seguidor e consulta os dados mais recentes do coordenador e os restantes dados do seguidor.

Para melhorar o desempenho das consultas no cluster de seguidores, pode ativar a configuração de extensões de pré-bloqueio. Utilize esta configuração cuidadosamente, uma vez que pode afetar a atualização dos dados na base de dados do seguidor.

Otimizar consultas

Utilize os seguintes métodos para otimizar as consultas para elevada simultaneidade.

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

Utilizar uma cache de resultados de consulta

Quando mais do que um utilizador carrega o mesmo dashboard num momento semelhante, o dashboard para o segundo e os seguintes utilizadores podem ser servidos a partir da cache. Esta configuração fornece um elevado desempenho sem quase nenhuma utilização da CPU. Utilize a funcionalidade de cache de resultados da consulta e envie a configuração da cache de resultados da consulta com a consulta com a set instrução .

O Grafana contém uma definição de configuração para a cache de resultados da consulta ao nível da origem de dados, pelo que todos os dashboards utilizam esta definição por predefinição e não precisam de modificar a consulta.

Configurar a consistência das consultas

O modo de consistência de consulta predefinido é forte. Neste modo, um nó de administrador gere os metadados e a ingestão do cluster, bem como o planeamento de consultas e a delegação da execução a outros nós.

Em aplicações de elevada simultaneidade, a gestão de consultas pode fazer com que a utilização da CPU do nó de administração seja elevada, enquanto outros nós estão menos ocupados. Isto pode causar um estrangulamento em que o número de consultas simultâneas não pode aumentar. No entanto, isto pode não ser visível no relatório da CPU do cluster (portal do Azure > {your_cluster} > Métricas > da CPU) que mostra a utilização média da CPU para o cluster.

Para este cenário, recomendamos a utilização do modo de consistência fraca . Neste modo, mais nós são capazes de gerir consultas, o que permite dimensionar horizontalmente o número de consultas simultâneas. Os nós neste modo atualizam periodicamente a respetiva cópia de metadados e dados recentemente ingeridos, o que leva a uma latência de normalmente inferior a um minuto à medida que os dados são sincronizados. No entanto, esta latência curta é preferível à situação de estrangulamento que pode surgir ao utilizar o modo de consistência forte .

Pode definir o modo de consistência numa política de consistência de consulta do grupo de cargas de trabalho, nas propriedades do pedido do cliente ou na configuração da origem de dados do Grafana.

Definir políticas de cluster

O número de pedidos simultâneos é limitado por predefinição e controlado pela política de limite de taxa de pedidos para que o cluster não fique sobrecarregado. Pode ajustar esta política para situações de elevada simultaneidade. Esta política só deve ser ajustada após testes rigorosos, preferencialmente em padrões de utilização e conjuntos de dados semelhantes à produção. Os testes garantem que o cluster consegue manter o valor modificado. Este limite pode ser configurado com base nas necessidades da aplicação.

Monitorizar clusters do Azure Data Explorer

Monitorizar o estado de funcionamento dos recursos do cluster ajuda-o a criar um plano de otimização com as funcionalidades sugeridas nas secções anteriores. O Azure Monitor para o Azure Data Explorer fornece uma vista abrangente do desempenho, operações, utilização e falhas do cluster. Obtenha informações sobre o desempenho das consultas, consultas simultâneas, consultas limitadas e várias outras métricas ao selecionar o separador Informações (pré-visualização) na secção Monitorização do cluster do Azure Data Explorer no portal do Azure.

Para obter informações sobre a monitorização de clusters, veja Azure Monitor for Azure Data Explorer (Azure Monitor for Azure Data Explorer). Para obter informações sobre as métricas individuais, veja Métricas de Data Explorer do Azure.