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á.

Distribuir a carga

Melhorar os tempos de resposta e aumentar os recursos disponíveis para fluxos de trabalho críticos pode exigir a eliminação de cargas externas. Muitas das soluções abordadas nesta seção são decisões que envolvem algum comprometimento. Elas têm consequências para a aplicação e devem ser cuidadosamente consideradas. Considere usar essas soluções nas seguintes situações:

Essas alterações incluem:

Antes de realizar essas ações, avalie-as no contexto de metas e riscos comerciais de longo prazo.

Separar workloads de leitura e gravação

Uma técnica comum ao executar aplicações baseados em MySQL é transferir as operações de leitura da instância do banco de dados de gravação (principal) para uma ou mais réplicas do banco de dados somente de leitura. Ao descarregar as leituras, é possível reduzir a carga geral na instância do banco de dados principal e abrir espaço para gravações. Certifique-se de direcionar somente leituras que não dependam da read-after-writeconsistência imediata das réplicas. Uma abordagem mais eficiente é mover todo o tráfego de leitura para a réplica e planejar a repetição read-after-write em caso de atraso na replicação. Há workloads de leitura independentes que podem ser descarregadas, como serviços de relatórios. Outras leituras exigirão alterações no nível da aplicação, onde o contexto do motivo pelo qual a leitura foi emitida é bem conhecido.

Uma abordagem alternativa é implementar uma solução de proxy de banco de dados como intermediária entre a aplicação e o banco de dados, o que pode fornecer a função de divisão de leitura e gravação e roteamento de consultas, sem o reconhecimento da aplicação. ProxySQL, MariaDB, ScaleArc MaxScale e Heimdall Data são algumas das soluções de proxy compatíveis com MySQL disponíveis. Esses produtos oferecem vários recursos adicionais, como armazenamento em cache ou multiplexação de conexões. Quando você está enfrentando um aumento repentino no tráfego e implementando uma nova tecnologia em sua pilha de aplicativos, recomendamos começar com a funcionalidade básica para dividir read/write consultas e testar o comportamento e o desempenho antes de usar recursos adicionais que possam ter efeitos colaterais indesejados.

Arquivar ou limpar dados mais antigos

Outra técnica para melhorar a performance do banco de dados é transferir dados históricos para outra tabela, banco de dados ou Amazon Simple Storage Service (Amazon S3). Muitos bancos de dados retêm todos os dados em linha durante todo o histórico da aplicação. Em circunstâncias normais, em uma aplicação típica voltada para o usuário, isso fornece aos usuários a capacidade de ver todos os seus pedidos históricos. Quando a demanda aumenta repentinamente, muitos usuários ativos na aplicação provavelmente são novos ou estão focados em fazer um novo pedido. Se os dados históricos residem online em uma única tabela contendo bilhões de linhas, isso aumenta. A tabela provavelmente também possui índices grandes. Tanto os dados quanto os índices da tabela são armazenados em uma estrutura de árvore. Ter mais entradas em uma tabela requer mais níveis na árvore, o que requer mais I/O operações para acessar as linhas. Isso aumenta o tempo de acesso para encontrar registros individuais. Mais importante ainda, faz com que grandes partes desnecessárias do índice residam no cache da página do banco de dados (pool de buffer do InnoDB).

Arquivar dados antigos em uma tabela separada, em um banco de dados separado ou no Amazon S3 pode reduzir o tempo de acesso dos usuários finais, liberar cache precioso e melhorar a performance geral da aplicação. O arquivamento de dados antigos antes do evento (por exemplo, retendo somente 30 ou 90 dias) limita o tamanho das tabelas e dos índices em tabelas críticas. Essa alteração exige que a aplicação seja modificada para consultar os dados mais antigos de um local secundário somente para o pequeno subconjunto de usuários que solicitam explicitamente a visualização dos dados históricos.

Adiar processos de ETL não críticos

As extrações do sistema de banco de dados principal para processos de ETL podem apresentar risco de estabilidade para workloads altamente transacionais e simultâneas durante condições de hiperajuste de escala. Os processos de ETL são conhecidos pelas seguintes características:

Processos de ETL que são variáveis ou imprevisíveis (por exemplo, consultas como INSERT INTO ... SELECT FROM ...;)) aumentam a variabilidade geral na carga e na contenção, aumentando o risco de estabilidade.

Sempre que possível, adie ou reduza a frequência com que os processos de ETL são executados, especialmente se eles não estiverem fornecendo funções críticas. Para processos críticos de ETL, modifique-os para que operem em unidades de trabalho limitadas, como o processamento de lotes de números fixos de linhas (por exemplo, usando cláusulas LIMIT), usar transações separadas ou extrair quantidades menores de dados por um longo período de tempo para reduzir as demandas de pico de recursos da instância de banco de dados.

Desativar os recursos menos essenciais da aplicação

A degradação suave da experiência do usuário ou a remoção de recursos não essenciais ao lidar com um aumento de solicitações conserva os recursos do banco de dados para funções críticas. Isso pode exigir uma pequena mudança na experiência do cliente, mas um fluxo diferente é melhor do que o site se tornar inativo. Talvez a personalização na primeira página do site, que sempre faz uma chamada ao banco de dados, possa ser temporariamente desativada. Ou você pode parar de apresentar ofertas personalizadas para clientes recorrentes enquanto seleciona produtos. A desativação temporária dos recursos pode permitir que a página seja armazenada em cache ou entregue sem exigir acesso ao banco de dados.

Outros exemplos incluem um front-end com um mecanismo de pesquisa que verifica as alterações de dados que exigem uma chamada ao banco de dados. Reduzir a frequência da pesquisa resultará imediatamente em menos chamadas ao banco de dados. As interfaces de usuário que exigem paginação ou oferecem aos usuários a opção de recuperar conjuntos de resultados ordenados mais distantes do resultado principal exigem chamadas ao banco de dados cada vez mais caras. Limite o número de páginas em um conjunto de resultados para proteger o banco de dados das chamadas de banco de dados mais caras. Use sinalizadores de recurso na camada de aplicação para permitir que a equipe de operações desative ou reduza os recursos à medida que a carga da aplicação ou do banco de dados aumenta.