O Database Autonomy Service (DAS) detecta automaticamente consultas lentas e instruções SQL ineficientes, diagnostica as causas raiz e aplica correções sem intervenção manual. O serviço reduz a latência das consultas e o consumo de recursos ao reescrever instruções SQL e ajustar o uso de índices.
Por que a otimização manual de SQL falha
Administradores de banco de dados (DBAs) e desenvolvedores enfrentam um problema cumulativo: as cargas de trabalho SQL não são estáticas. Iterações de negócios, mudanças na distribuição de dados, alterações em pontos de acesso e atualizações de versão do banco de dados remodelam constantemente os perfis de desempenho. Acompanhar esse ritmo exige tempo e profissionais em quantidade desproporcional.
A otimização manual apresenta duas fraquezas estruturais ligadas a dois momentos distintos:
T1 — momento em que se detecta uma exceção de desempenho e a otimização tem início
T2 — momento em que se aplica a correção e a instância retorna à normalidade
Nos fluxos de trabalho tradicionais, o T1 ocorre tardiamente, muitas vezes após o problema degradar a experiência do usuário por um longo período. O intervalo entre T1 e T2 depende inteiramente do esforço manual, fase durante a qual o risco de falha se acumula. À medida que os volumes de dados crescem, esse modelo entra em colapso: adicionar mais pessoas não resolve o problema.
Implementar uma otimização automatizada de SQL que feche esse ciclo é complexo em seis dimensões:
|
Dimensão |
Desafio |
|
Precisão |
Detectar as exceções corretas no momento certo, sem ruídos |
|
Diagnóstico |
Gerar sugestões de otimização acionáveis e com alto nível de confiança |
|
Segurança |
Garantir que alterações online não desestabilizem o ambiente de produção |
|
Abrangência |
Rastrear os resultados da otimização em múltiplas dimensões em tempo real |
|
Integração |
Coordenar limitação e otimização de SQL para tratar tanto os sintomas quanto as causas raiz |
|
Escala |
Suportar otimização automática em centenas de milhares ou até milhões de servidores |
Como funciona
A otimização automática de SQL do DAS opera como um ciclo fechado de cinco estágios. Cada etapa alimenta a seguinte e elimina as lacunas dos processos manuais.
Estágio 1: Detecção
O DAS monitora continuamente as cargas de trabalho em busca de três tipos de problemas: novas instruções SQL que causam consultas lentas, instruções SQL com desempenho deteriorado e instruções SQL consistentemente ineficientes. A detecção é acionada sob três condições:
Análise agendada — análise offline de consultas lentas seguindo uma cadência regular dentro da janela de O&M
Deterioração em tempo real — o algoritmo de detecção de exceções de carga de trabalho identifica quedas de desempenho conforme elas ocorrem; para incidentes complexos, a limitação automática de SQL e a otimização automática de SQL são ativadas simultaneamente
Alterações na carga de trabalho — quando instruções SQL de negócios são publicadas ou removidas, o DAS detecta se o volume de dados ou a distribuição de consultas mudou além da capacidade dos índices existentes
Estágio 2: Diagnóstico
O mecanismo de diagnóstico recebe as instruções SQL problemáticas e utiliza um modelo baseado em custo — a mesma abordagem dos otimizadores de banco de dados — para avaliar todas as correções possíveis. As sugestões incluem criação de índices ideais, reescrita de instruções SQL e recomendação de mecanismos. Cada sugestão recebe uma pontuação baseada no custo de execução, gerando um resultado quantitativo e classificado, em vez de um palpite heurístico.
O recurso de diagnóstico e otimização de SQL está em produção no Alibaba Group há anos e diagnostica aproximadamente 50.000 instruções SQL por dia nas aplicações de negócios do grupo. A taxa de sucesso nos diagnósticos manteve-se acima de 98%, e a taxa de recomendação para consultas lentas acima de 75%.
Estágio 3: Planejamento
O DAS avalia automaticamente o risco de cada sugestão, gera um plano de liberação canário e agenda tarefas de otimização com base na carga de trabalho atual e no perfil da instância. Não é necessário agendamento manual.
Estágio 4: Aplicação
As alterações são liberadas dentro da janela de O&M. Para cenários de sharding com grandes volumes de dados, o plano de liberação canário aplica as mudanças em lotes. Durante a execução, o DAS monitora o atraso de replicação entre as instâncias primária e secundária. Se o atraso ultrapassar o limiar configurado, as tarefas de alteração de índice são suspensas imediatamente, permitindo apenas uma tarefa de alteração por instância a qualquer momento.
Estágio 5: Verificação e confirmação
Após as alterações entrarem em vigor, o mecanismo de decisão inicia uma tarefa de rastreamento que abrange tanto as instruções SQL otimizadas quanto os modelos SQL relacionados. Ele usa um modelo de árvore de decisão para comparar métricas de desempenho antes e depois da otimização, acompanhando instruções SQL completas e aquelas que causam consultas lentas.
O ciclo padrão de rastreamento é de 24 horas. Se o desempenho se deteriorar em qualquer momento, as alterações são revertidas automaticamente. Caso nenhuma reversão ocorra dentro de 24 horas, a otimização é marcada como bem-sucedida e os benefícios reais são calculados.
Coordenação orientada a eventos em todo o ciclo
O Event Center do DAS integra esses estágios. Eventos de exceção — provenientes do sistema de alertas, detecção em tempo real, análise offline ou monitoramento de carga de trabalho — fluem para o Event Center. Após o diagnóstico, o DAS gera um novo evento de otimização e o encaminha de volta ao Event Center para impulsionar o próximo estágio.
A otimização automática de SQL do DAS é um ciclo fechado orientado por dados. A figura anterior ilustra todo o processo de forma simplificada.
Ao ativar o serviço de autonomia no centro de autonomia do DAS, escolha se as sugestões de otimização serão aplicadas automaticamente ou se exigirão aprovação antes de prosseguir.
Segurança das alterações
Alterações automatizadas em bancos de dados de produção carregam riscos inerentes. O DAS mitiga esses riscos por meio de três camadas de proteção:
Verificações pré-alteração
As alterações só prosseguem quando todas as métricas abaixo estiverem dentro de faixas seguras:
Atraso de replicação entre instâncias primária e secundária
Carga de trabalho do banco de dados
Uso do tablespace
As modificações ficam restritas à janela de O&M configurada, evitando execução durante períodos de pico de tráfego.
Liberação canário
Em cenários de sharding com grandes volumes de dados, o DAS gera automaticamente um plano de liberação canário que aplica as alterações em lotes, em vez de todas de uma vez. Durante a execução, o DAS monitora continuamente o atraso de replicação. Se o atraso exceder o limiar configurado, todas as tarefas de alteração de índice daquela instância são suspensas imediatamente. Apenas uma tarefa de alteração é executada por instância a qualquer momento.
Reversão automática
Após cada alteração, o mecanismo de decisão rastreia o desempenho das instruções SQL otimizadas e dos modelos SQL relacionados usando um modelo de árvore de decisão. Ele compara métricas antes e depois da otimização, abrangendo instruções SQL completas e consultas lentas. Se o desempenho se deteriorar em qualquer ponto durante a janela de rastreamento de 24 horas, as alterações são revertidas automaticamente, sem necessidade de intervenção manual.
Mecanismos de banco de dados compatíveis
A otimização automática de SQL é compatível com os seguintes mecanismos de banco de dados: ApsaraDB RDS for MySQL, PolarDB for MySQL e ApsaraDB RDS for PostgreSQL.