Diagnóstico de armazenamento - AnalyticDB: Central de Documentação do Alibaba Cloud

O diagnóstico de armazenamento ajuda a identificar distorção de dados, chaves de partição subotimizadas, excesso de índices e outros problemas de configuração de tabelas no cluster AnalyticDB for MySQL. Na página Storage Diagnostics, avalie a adequação das chaves de partição, chaves de distribuição e tabelas replicadas. Identifique também oportunidades para separação de dados quentes e frios e receba sugestões de otimização de índices. Ao aplicar essas sugestões, você otimiza o schema do banco de dados, reduz os custos do cluster e melhora a eficiência.

Observações importantes

A otimização de tabelas quentes e frias e o diagnóstico de índices têm suporte apenas em clusters que executam a versão 3.1.4 ou posterior do Milvus.
As sugestões de otimização para tabelas quentes e frias e o diagnóstico de índices baseiam-se em uma análise histórica de dados e padrões de consulta. Essas sugestões permanecem eficazes enquanto os padrões de dados e consultas forem estáveis. Caso esses padrões mudem significativamente, a eficácia das sugestões diminui. Antes de usar esse recurso, avalie se deve aplicar as sugestões com base na sua carga de trabalho atual.

Diagnóstico de tabelas

Diagnóstico de distorção de dados

Ao criar uma tabela, use DISTRIBUTED BY HASH para especificar uma chave de distribuição. Após definir a chave de distribuição, o AnalyticDB for MySQL calcula um hash dos valores da chave de distribuição e distribui as linhas entre diferentes shards. A distribuição desigual de dados entre os nós de armazenamento causa distorção de espaço em disco, o que pode preencher discos prematuramente e bloquear gravações de dados.

Critérios de diagnóstico

O AnalyticDB for MySQL diagnostica a distorção de dados em tabelas com mais de 10.000 linhas. O método de cálculo é o seguinte:

Exclua o maior shard e calcule o tamanho médio do shard.
Se algum shard for maior que average shard size × threshold ou menor que average shard size / threshold, a tabela será considerada distorcida. O limiar padrão é 3, e o intervalo válido é [0, 10000000000]. Para ajustar o limiar, execute o seguinte comando: SET ADB_CONFIG RC_DATA_SKEW_THRESHOLD=Value;.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Clique na aba Table Diagnostics para visualizar os detalhes na seção Table Skew Diagnostics.

Storage Node Disk Usage

Use o gráfico para verificar o uso de disco entre os nós de armazenamento e identificar distorções de espaço em disco. Se houver distorção, otimize as tabelas listadas em Top 10 Skewed Tables. Mesmo que o espaço em disco pareça equilibrado, mas tabelas distorcidas apareçam em Top 10 Skewed Tables, otimize-as para evitar a degradação do desempenho de consulta do cluster.

Top 10 Skewed Tables

Esta seção lista tabelas com distorção de dados, classificadas por volume total de dados em ordem decrescente. Para visualizar a contagem de linhas por shard e avaliar a gravidade da distorção, clique em View Skew Details na coluna Actions.

Métodos de otimização

Resolva esse problema usando um dos seguintes métodos:

Expanda a capacidade de armazenamento.
- Clusters da Enterprise Edition exigem dimensionamento de recursos reservados. Para mais informações, consulte Dimensionar um cluster Enterprise Edition.
- Clusters da Basic Edition exigem dimensionamento de recursos de computação. Para mais informações, consulte Dimensionar um cluster Basic Edition.
- Clusters da Data Lakehouse Edition exigem dimensionamento de recursos de armazenamento reservados. Para mais informações, consulte Dimensionamento da Data Lakehouse Edition.
- Clusters da Data Warehouse Edition (elastic mode) exigem dimensionamento de unidades de E/S elásticas. Para mais informações, consulte Dimensionar um cluster Data Warehouse Edition (elastic mode).
- Clusters da Data Warehouse Edition (reserved mode) exigem dimensionamento de grupos de nós. Para mais informações, consulte Dimensionar um cluster Data Warehouse Edition (reserved mode).
Exclua índices ou partições ociosos para reduzir o uso de armazenamento. Para mais informações, consulte Diagnóstico de índices.
Recrie a tabela e migre os dados. Para mais informações, consulte CREATE TABLE.

Otimização de tabelas quentes e frias

O AnalyticDB for MySQL analisa a frequência de acesso às tabelas para identificar aquelas raramente acessadas e fornecer sugestões de otimização. Aplique essas sugestões para ajustar a política de separação de dados quentes e frios das suas tabelas. Para mais informações sobre a separação de dados quentes e frios, consulte Separação de dados quentes e frios.

Critérios de diagnóstico

O AnalyticDB for MySQL fornece sugestões de otimização para tabelas que não foram acessadas nos últimos 15 dias e possuem uma taxa de acesso inferior a 1%.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Na aba Table Diagnostics, clique em Hot and Cold Table Optimization.
Na aba Available Optimization Suggestions, clique em Disable para ativar o recurso de otimização de tabelas quentes e frias. Se esse recurso já estiver ativado para o cluster atual, ignore esta etapa.

Clique nas abas Available Optimization Suggestions e Applied Optimization Suggestions para visualizar as sugestões disponíveis e aplicadas.

Parâmetro	Descrição
Suggestion ID	ID da sugestão de otimização.
SQL	Alterações na tabela e na definição exigidas pela sugestão.
Optimization Type	Otimização de tabelas quentes e frias.
Optimization Suggestion	Recomendação detalhada para o tipo de otimização.
Expected Optimization Benefits	Benefício esperado após aplicar a sugestão. Nota Os benefícios esperados são estimativas baseadas em estatísticas históricas, não valores precisos em tempo real. Use-os apenas como referência.
Actions	Aplique a sugestão atual usando Apply. Nota Após clicar em Apply, o AnalyticDB for MySQL altera a política de armazenamento da tabela para COLD. Para alterá-la para MIXED ou HOT, execute manualmente uma instrução ALTER. Para detalhes, consulte ALTER TABLE. Clique em Apply para adotar a sugestão de otimização. Após clicar em Apply, o cluster correspondente executa a alteração SQL e a sugestão aparece na aba Applied Optimization Suggestions. Apply tem o mesmo efeito que executar o SQL em um cliente. Esta ação não pode ser desfeita. Use-a com cuidado. Após a emissão do SQL, a tabela deve concluir uma operação Build para que a alteração tenha efeito. O sistema de banco de dados aciona o Build automaticamente com base em regras internas. Até ser acionado, o status da sugestão permanece "running". Após o acionamento, ele muda para "completed".

Diagnóstico de tabelas replicadas

Ao criar uma tabela no AnalyticDB for MySQL, especifique a distribuição broadcast usando DISTRIBUTED BY BROADCAST. A tabela é então criada como uma tabela replicada, que armazena uma cópia idêntica de seus dados em cada shard. Se sua carga de trabalho de consulta envolver junções de alta concorrência entre tabelas grandes e pequenas, como juntar uma tabela de fatos grande com uma tabela de dimensões pequena, crie a tabela menor como uma tabela replicada. Isso reduz a transmissão de dados pela rede interna do cluster e melhora a concorrência de consultas. No entanto, tabelas replicadas têm baixo desempenho de gravação e consomem muito espaço de armazenamento, o que pode impactar negativamente o desempenho geral de gravação do cluster AnalyticDB for MySQL.

Critérios de diagnóstico

Uma tabela replicada é considerada ineficiente se contiver mais de 20.000 linhas.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Na aba Table Diagnostics, clique em Replicated Table Diagnostics.

Métodos de otimização

Crie uma tabela padrão e migre os dados. Para mais informações, consulte CREATE TABLE.

Diagnóstico de partições

Diagnóstico de tabelas particionadas

Se você não definir corretamente o campo de partição ao criar uma tabela particionada, os seguintes problemas podem ocorrer:

Partições excessivamente grandes, como partições anuais onde os dados de cada ano residem em uma única partição, resultam em um pequeno número de partições com volumes massivos de dados. Se uma tarefa Build for executada em tal partição, ela consumirá recursos excessivos, como CPU do nó de armazenamento e E/S de disco, afetando a estabilidade do cluster.
Partições excessivamente pequenas, como partições horárias onde os dados de cada hora residem em uma única partição, resultam em muitas partições contendo dados mínimos. O cluster precisa armazenar em cache metadados extensos de partição, o que consome uma quantidade significativa de memória. As consultas também precisam verificar muitas partições, o que degrada o desempenho da consulta.

Qual é o tamanho razoável de uma partição?

O tamanho da partição é medido pelo número de linhas¹ e escala proporcionalmente com o número de shards². Se um cluster tiver N shards, um tamanho de partição razoável é uma contagem de linhas entre [1 milhão × N] e [5 milhões × N].

Por exemplo, se um cluster tiver 64 shards, uma contagem razoável de linhas por partição varia de 64 milhões a 320 milhões.

Nota

¹Para consultar a contagem de linhas da partição, execute o seguinte comando: SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;
²Para consultar a contagem de shards, execute o seguinte comando: SELECT COUNT(1) FROM information_schema.kepler_meta_shards;

Diagnosticar se o campo de partição é adequado

Critérios de diagnóstico

Um campo de partição é considerado inadequado se 10% ou mais das partições em uma tabela tiverem um tamanho inadequado.

Por exemplo, se uma tabela tiver 100 partições e 10 ou mais delas tiverem um tamanho inadequado, o campo de partição será sinalizado como inadequado.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Clique na aba Partition Diagnostics para visualizar as tabelas particionadas inadequadas e seus nomes de partição específicos na seção Partitioned Table Diagnostics.

Como ajustar o tamanho da partição para o intervalo adequado

Se a ferramenta de diagnóstico de partições identificar partições inadequadas, use os seguintes métodos para ajustá-las.

Se a contagem de linhas de uma partição estiver abaixo do limite inferior do intervalo adequado, a partição é muito pequena. Nesse caso, aumente a granularidade da partição. Por exemplo, se um cluster tiver 64 shards, o intervalo adequado é de 64 milhões a 320 milhões de linhas. Se uma partição tiver menos de 64 milhões de linhas, altere o particionamento de diário para mensal.
Se o número de linhas em uma partição exceder o limite superior recomendado, a partição é considerada muito grande e você deve reduzir sua granularidade. Por exemplo, se você tiver 64 shards, o número recomendado de linhas por partição é entre 64 milhões e 320 milhões. Se uma partição contiver mais de 320 milhões de linhas, recomendamos alterar o particionamento de mensal para diário.

Para mais informações sobre como alterar a granularidade da partição, consulte ALTER TABLE.
Se a contagem total de linhas de uma tabela estiver abaixo do limite inferior do intervalo adequado e não houver expectativa de crescimento para dentro do intervalo, crie uma tabela não particionada e migre os dados da tabela particionada.

Diagnóstico de tabelas não particionadas

Se você omitir a cláusula PARTITION BY ao criar uma tabela, ela será criada como uma tabela não particionada. Operações DML, como INSERT, UPDATE e DELETE, em tabelas não particionadas frequentemente acionam tarefas Build de tabela completa. Se a tabela contiver uma quantidade excessiva de dados, essas tarefas Build consumirão muito espaço temporário em disco, aumentando o uso do disco no nó e podendo causar bloqueios de disco. Tarefas Build em tabelas grandes também consomem recursos substanciais de E/S de disco e CPU, o que degrada o desempenho geral do cluster.

Critérios de diagnóstico

Uma tabela não particionada é considerada ineficiente se contiver mais de 1 bilhão de linhas.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Clique na aba Partition Diagnostics para visualizar as informações de Non-partitioned Table Diagnostics.

Métodos de otimização

Crie uma tabela particionada e migre os dados da tabela não particionada. Para mais informações, consulte CREATE TABLE.

Diagnóstico de índices

O AnalyticDB for MySQL analisa o uso de índices e fornece automaticamente sugestões de otimização para índices que não foram usados por um longo período. Aplique essas sugestões para excluir índices ociosos e reduzir custos de armazenamento.

Diagnóstico de índices ociosos

Critérios de diagnóstico

Um índice é considerado ocioso se não tiver sido usado nos últimos 15 dias e sua taxa de uso for inferior a 1%.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Clique na aba Index Diagnostics para visualizar detalhes de Indexes to Remove.
Na aba Available Optimization Suggestions, clique em Enable para ativar o diagnóstico de índices. Ignore esta etapa se o recurso já estiver ativado.

Clique nas abas Available Optimization Suggestions e Applied Optimization Suggestions para visualizar as sugestões disponíveis e aplicadas.

Parâmetro	Descrição
Suggestion ID	ID da sugestão de otimização.
SQL	Alterações na tabela e na definição exigidas pela sugestão.
Optimization Type	Otimização de índice.
Optimization Suggestion	Recomendação detalhada para o tipo de otimização.
Expected Optimization Benefits	Benefício esperado após aplicar a sugestão. Nota Os benefícios esperados são estimativas baseadas em estatísticas históricas, não valores precisos em tempo real. Use-os apenas como referência.
Actions	Aplique a sugestão atual usando Apply. Nota Após excluir um índice, as consultas que filtram por essa coluna levarão mais tempo. Apply indica que você concorda em adotar esta sugestão de otimização. Após clicar em Apply, o cluster correspondente executa alterações SQL e esta sugestão aparece na aba Applied Optimization Suggestions. Apply tem o mesmo efeito que executar o SQL em um cliente. Esta ação não pode ser desfeita. Use-a com cuidado. Após a emissão do SQL, a tabela deve concluir uma operação Build para que a alteração tenha efeito. O sistema de banco de dados aciona o Build automaticamente com base em regras internas. Até ser acionado, o status da sugestão permanece "running". Após o acionamento, ele muda para "completed".

Diagnóstico de novos índices

Critérios de diagnóstico

Este diagnóstico identifica campos que foram usados como filtros em consultas nos últimos 15 dias, mas não estão definidos como campos indexados.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha Storage Analysis > Storage Diagnostics.
Clique na aba Index Diagnostics para visualizar detalhes de Indexes to Create.
Na aba Available Optimization Suggestions, clique em Enable para ativar o diagnóstico de índices. Ignore esta etapa se o recurso já estiver ativado.

Clique nas abas Enable e Available Optimization Suggestions para visualizar as sugestões disponíveis e aplicadas.

Parâmetro	Descrição
Applied Optimization Suggestions	ID da sugestão de otimização.
Suggestion ID	Campo a ser adicionado como índice.
Index Fields	Instrução SQL para criar o índice.
SQL	Sugestão de criação de índice.
Optimization Type	Descreve a frequência com que o campo foi usado recentemente, indicando seu potencial como campo indexado. Aplique a sugestão atual usando Optimization Suggestion. Nota Após a criação dos Batch Create, a tabela deve concluir uma operação Build para que a alteração tenha efeito. O sistema de banco de dados aciona o Build automaticamente com base em regras internas. Até ser acionado, o status da sugestão permanece "running". Após o acionamento, ele muda para "completed".

Diagnóstico de índice de chave primária

Critérios de diagnóstico

Uma tabela é considerada com número excessivo de chaves primárias se tiver mais de três campos de chave primária e esses campos constituírem pelo menos metade de todos os campos da tabela.

Procedimento

Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Indexes to Create. Localize o cluster que deseja gerenciar e clique no ID do cluster.
No painel de navegação à esquerda, escolha .
Clique na aba Index Diagnostics para visualizar detalhes de Clusters.
Na aba Storage Analysis, clique em Enable para ativar o diagnóstico de índices. Ignore esta etapa se o recurso já estiver ativado.
Visualize as tabelas com número excessivo de chaves primárias. A tabela exibe as seguintes colunas: Storage Diagnostics, Index Diagnostics, Primary Key Diagnostics e Available Optimization Suggestions.

Perguntas frequentes

Por que o status da tarefa de otimização permanece "running" após clicar em Apply now para uma sugestão de otimização de tabela quente e fria?

Causa: Após clicar em Apply, o AnalyticDB for MySQL altera a política de armazenamento da tabela para COLD. Essa alteração exige uma operação Build para ter efeito. O recurso de otimização quente e fria não aciona imediatamente uma tarefa Build. O sistema aciona essa tarefa automaticamente em um momento posterior.

Solução: Aguarde o sistema acionar a tarefa Build automaticamente ou copie a instrução SQL que aciona a tarefa Build no console e execute-a manualmente. Após a execução da tarefa Build, verifique seu status executando o seguinte comando: SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10;.

APIs relacionadas

API	Descrição
DescribeExcessivePrimaryKeys	Visualize tabelas com chaves primárias excessivas em clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition.
DescribeTablePartitionDiagnose	Visualize diagnósticos de partição para clusters da Data Warehouse Edition.