O desempenho de consultas no AnalyticDB for MySQL depende de seis fatores: especificações do cluster, quantidade de nós, distribuição de dados, volume de dados, concorrência de consultas e complexidade das consultas. Compreender o funcionamento de cada fator ajuda a escolher o tamanho adequado do cluster, projetar esquemas de dados compatíveis com execução paralela e identificar a causa raiz de consultas lentas.
Como o AnalyticDB for MySQL executa consultas
O AnalyticDB for MySQL utiliza uma arquitetura de processamento de dados distribuído. Ao receber uma consulta, o mecanismo a divide em estágios e os executa em paralelo em vários nós. Cada nó processa sua parcela dos dados na memória. Qualquer elemento que interrompa a distribuição equilibrada do trabalho ou sature um recurso compartilhado degrada o desempenho geral.
Especificações do cluster
Cada especificação de cluster define uma combinação fixa de núcleos de CPU, tamanho de memória e mídia de armazenamento. Esses atributos determinam o teto de processamento por nó para diferentes tipos de carga de trabalho:
Consultas com muitos JOINs ou agregações pesadas: têm limitação de CPU e memória. Uma especificação com mais núcleos de CPU e maior capacidade de memória reduz o tempo de processamento dessas cargas de trabalho.
Consultas intensivas em varredura de dados ou agregações simples: têm limitação de E/S de disco. Uma especificação com mídia de armazenamento mais rápida melhora o throughput dessas cargas de trabalho.
Selecione uma especificação correspondente ao seu padrão predominante de consultas. Para ver as opções disponíveis, consulte Especificações.
Quantidade de nós
Mais nós proporcionam maior capacidade de processamento paralelo. Como o AnalyticDB for MySQL divide cada consulta em estágios executados simultaneamente em diferentes nós, adicionar nós aumenta o volume total de trabalho que o cluster consegue concluir por unidade de tempo.
Dimensione o cluster com base no volume de consultas e nos requisitos de latência. Para obter orientações, consulte Crie um cluster.
Distribuição de dados
A eficácia da execução paralela depende diretamente da distribuição dos dados. Quando os dados estão uniformemente distribuídos pelos nós de armazenamento, todos concluem suas subtarefas aproximadamente ao mesmo tempo. Se os dados estiverem concentrados em um subconjunto de nós, esses nós se tornam gargalos: as subtarefas demoram significativamente mais e travam toda a consulta.
Distribua os dados da forma mais uniforme possível entre os nós de armazenamento para maximizar a eficiência do paralelismo.
Volume de dados
O AnalyticDB for MySQL processa os dados da consulta na memória, em vez de gravar resultados intermediários em disco. Quando a quantidade de dados envolvida em uma consulta é grande, ela retém recursos de memória e CPU por um período prolongado. Isso reduz a capacidade do cluster de lidar com outras consultas simultaneamente.
Tabelas grandes também pressionam a E/S do disco. A filtragem por índices e a leitura de linhas detalhadas geram competição entre consultas concorrentes pela largura de banda de armazenamento, o que desacelera todas as consultas afetadas.
Concorrência de consultas
O cluster só consegue lidar com um número limitado de consultas simultâneas, conforme permitido pelos recursos de seus nós. Quando a quantidade de consultas concorrentes excede esse limite, as consultas excedentes entram em fila no backend e aguardam a liberação de recursos. Quanto mais congestionada a fila, maior a latência individual de cada consulta.
As especificações e o tamanho do cluster determinam o limite de concorrência.
Complexidade das consultas
Consultas complexas exigem desproporcionalmente mais recursos do cluster:
Condições de filtro amplas: Se um filtro não eliminar a maioria das linhas logo no início, o mecanismo lerá grandes volumes de dados brutos dos nós de armazenamento antes de aplicar a condição.
Múltiplos JOINs: Cada JOIN pode exigir a movimentação de dados entre nós pela rede. Cadeias de JOINs multiplicam o número de transferências e aumentam o risco de congestionamento de rede.
Grande número de colunas no GROUP BY: Utilizar muitas colunas em uma cláusula GROUP BY consome grandes quantidades de memória para manter o estado da agregação. Esse consumo compete com a memória necessária para outros estágios da consulta.