Ajustar workloads de gravação - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Ajustar workloads de gravação

A implementação do balanceamento de carga e a liberação da instância de gravação ajudarão sua workload de gravação a apresentar uma melhor performance durante os picos mais altos. Para obter uma melhor performance de gravação em alta simultaneidade, siga estas etapas adicionais.

Mover a integridade referencial para a camada de aplicação

Embora as verificações de integridade referencial sejam importantes, com o hiperajuste de escala elas podem ser prejudiciais à sua workload. Para cada gravação, verificações extras devem ser realizadas antes que a gravação em si seja executada, o que resulta em baixa performance. Se a aplicação exigir verificações rigorosas de integridade, integre-as na camada de aplicação para evitar que elas restrinjam suas gravações.

Evite usar chaves primárias pesadas

Mantenha suas chaves primárias leves. O mecanismo de armazenamento InnoDB anexa a chave primária a todos os outros índices criados por você em sua tabela. Quando sua chave primária é grande, o tamanho do índice é afetado. O armazenamento e a recuperação de páginas de dados diminuirão se a chave primária for muito grande. Um exemplo comum é o uso de identificadores universalmente exclusivos como chaves primárias. Essa não é uma boa abordagem se seu objetivo é performance em um ambiente com hiperajuste de escala.

Usar troca de partições para carregar dados em tabelas particionadas

Se você estiver gravando grandes conjuntos de dados em tabelas particionadas, a combinação entre LOAD DATA FROM S3 e a troca de partições pode melhorar a performance porque a tabela principal não está sendo acessada para as inserções. A troca de partições envolve uma linguagem de definição de dados (DDL) e coloca um bloqueio de metadados em sua tabela. Certifique-se de que isso seja feito quando houver poucas ou nenhuma consulta em execução na tabela para que a DDL de troca de partições possa implementar o bloqueio de metadados sem esperas. A troca em si leva apenas milissegundos para ser concluída.

Remover índices não utilizados

O InnoDB otimiza seus planos de consulta com base no crescimento dos dados, e é uma boa ideia verificar se há índices não utilizados em seu banco de dados e removê-los. Os índices não utilizados consomem E/S quando a aplicação grava dados em uma tabela. Verifique a lista de índices não utilizados e certifique-se de que eles não sejam índices usados em situações raras, como relatórios trimestrais. Além disso, observe que alguns índices são usados para impor exclusividade ou ordenação e também devem ser considerados.

Garanta que as versões antigas da linha sejam limpas com eficiência

Na implementação do InnoDB do controle de simultaneidade multiversão (MVCC), quando um registro é modificado, a versão atual (antiga) dos dados que estão sendo modificados é registrada pela primeira vez como desfazer registro em um log de desfazer. Um valor crescente do comprimento da lista de histórico (HLL) indica que os segmentos de coleta de resíduos do InnoDB (segmentos de limpeza) não estão acompanhando a workload de gravação ou que a limpeza está bloqueada por uma consulta ou transação de longa duração. Quando a coleta de resíduos é bloqueada ou atrasada, o banco de dados pode desenvolver um atraso substancial na limpeza que pode afetar negativamente a performance da consulta. Você pode usar as recomendações a seguir para otimizar o processo de limpeza.

  • Mantenha as transações pequenas.

  • Para consultas de leitura, use o nível de isolamento READ COMMITTED.

  • Aumente o número de threads de limpeza (innodb_purge_threads e innodb_purge_batch_size). Observe que o ajuste desses parâmetros requer uma reinicialização.

  • Monitore o HLL regularmente e resolva quaisquer problemas de workload que impeçam o progresso da coleta de resíduos.

Certifique-se de que o registro em log não cause contenção adicional

O log geral de consultas registra as conexões e desconexões do cliente, bem como todas as declarações recebidas pelo servidor na ordem em que foram recebidas. Quando ativado, o registro em log é síncrono, o que pode levar a uma penalidade substancial de performance em um sistema ocupado. A menos que seja necessário, recomendamos desativar o log geral.

O log de consultas lentas registra instruções que demoraram mais do que o número de segundos long_query_time para executar com a configuração padrão de 10 segundos. Quando a configuração é definida como 0, todas as instruções são registradas de forma síncrona, o que pode levar a uma penalidade de performance em bancos de dados com muita atividade.