Database Autonomy Service (DAS) detecta automáticamente consultas lentas y sentencias SQL ineficientes, diagnostica sus causas raíz y aplica correcciones sin intervención manual. Este servicio reduce la latencia de las consultas y el consumo de recursos al reescribir sentencias SQL y ajustar el uso de índices.
Por qué falla la optimización manual de SQL
Los administradores de bases de datos (DBA) y los desarrolladores enfrentan un problema acumulativo: las cargas de trabajo de SQL no son estáticas. La iteración del negocio, los cambios en la distribución de datos, las variaciones en los puntos de acceso y las actualizaciones de versión de la base de datos modifican constantemente los perfiles de rendimiento. Mantenerse al día requiere una cantidad desproporcionada de tiempo y personal.
La optimización manual presenta dos debilidades estructurales vinculadas a dos momentos clave:
T1: momento en que se detecta una excepción de rendimiento y comienza la optimización.
T2: momento en que se aplica la corrección y la instancia vuelve a la normalidad.
En los flujos de trabajo tradicionales, T1 llega tarde, a menudo después de que el problema ha degradado la experiencia del usuario durante un periodo prolongado. El intervalo entre T1 y T2 depende por completo del esfuerzo manual, lapso durante el cual se acumula el riesgo de fallos. A medida que crecen los volúmenes de datos, este modelo colapsa: agregar más personal no resuelve el problema.
Desarrollar una optimización automática de SQL que cierre este ciclo resulta difícil en seis dimensiones:
|
Dimensión |
Desafío |
|
Precisión |
Detectar las excepciones correctas en el momento adecuado, sin generar ruido. |
|
Diagnóstico |
Generar sugerencias de optimización viables y con alto nivel de confianza. |
|
Seguridad |
Garantizar que los cambios en línea no desestabilicen el entorno de producción. |
|
Integralidad |
Rastrear los resultados de la optimización en varias dimensiones y en tiempo real. |
|
Vinculación |
Coordinar la limitación y la optimización de SQL para abordar tanto los síntomas como las causas raíz. |
|
Escala |
Admitir la optimización automática en cientos de miles o incluso millones de servidores. |
Cómo funciona
La optimización automática de SQL de DAS opera como un ciclo cerrado de cinco etapas. Cada etapa alimenta a la siguiente y elimina las brechas que dejan los procesos manuales.
Etapa 1: Detección
DAS monitorea continuamente las cargas de trabajo en busca de tres tipos de problemas: nuevas sentencias SQL que causan consultas lentas, sentencias SQL cuyo rendimiento se ha deteriorado y sentencias SQL consistentemente ineficientes. La detección se activa bajo tres condiciones:
Análisis programado: las consultas lentas se analizan sin conexión dentro de una ventana de O&M periódica.
Deterioro en tiempo real: el algoritmo de detección de excepciones de carga de trabajo identifica caídas de rendimiento conforme ocurren. En incidentes complejos, la limitación automática de SQL y la optimización automática de SQL se activan de forma conjunta.
Cambios en la carga de trabajo: cuando se publica o retira SQL del negocio, DAS detecta si el volumen de datos o la distribución de consultas han cambiado más allá de lo que los índices existentes pueden manejar.
Etapa 2: Diagnóstico
Las sentencias SQL problemáticas se envían al motor de diagnóstico, el cual utiliza un modelo basado en costos —el mismo enfoque que emplean los optimizadores de bases de datos— para evaluar cada posible solución. Las sugerencias incluyen la creación de índices óptimos, la reescritura de sentencias SQL y la recomendación de motores. Cada sugerencia recibe una puntuación según su costo de ejecución, lo que produce un resultado cuantitativo y jerarquizado en lugar de una estimación heurística.
La función de diagnóstico y optimización de SQL ha operado en producción dentro de Alibaba Group durante años y diagnostica aproximadamente 50,000 sentencias SQL al día en las aplicaciones de negocio del grupo. La tasa de éxito en el diagnóstico se ha mantenido por encima del 98 %, y la tasa de recomendación para consultas lentas supera el 75 %.
Etapa 3: Planificación
DAS evalúa automáticamente el riesgo de cada sugerencia, genera un plan de publicación canaria y programa las tareas de optimización con base en la carga de trabajo actual y el perfil de la instancia. No se requiere programación manual.
Etapa 4: Aplicación
Los cambios se publican dentro de la ventana de O&M. En escenarios de sharding con grandes volúmenes de datos, el plan de publicación canaria aplica los cambios por lotes. Durante la ejecución, DAS monitorea el retraso de replicación entre las instancias primaria y secundaria. Si el retraso supera el umbral configurado, las tareas de cambio de índice se suspenden de inmediato y solo se permite ejecutar una tarea de cambio por instancia a la vez.
Etapa 5: Verificación y confirmación
Una vez que los cambios surten efecto, el motor de decisiones inicia una tarea de seguimiento que abarca tanto las sentencias SQL optimizadas como las plantillas SQL relacionadas. Utiliza un modelo de árbol de decisiones para comparar las métricas de rendimiento antes y después de la optimización, e incluye el rastreo de sentencias SQL completas y de aquellas que provocan consultas lentas.
El ciclo de seguimiento predeterminado es de 24 horas. Si el rendimiento se deteriora en cualquier momento, los cambios se revierten automáticamente. Si no ocurre ninguna reversión dentro de las 24 horas, la optimización se marca como exitosa y se calculan los beneficios reales obtenidos.
Coordinación basada en eventos a lo largo del ciclo
El Centro de eventos de DAS integra estas etapas. Los eventos de excepción —provenientes del sistema de alertas, la detección en tiempo real, el análisis sin conexión o el monitoreo de carga de trabajo— fluyen hacia el Centro de eventos. Tras el diagnóstico, DAS genera un nuevo evento de optimización y lo enruta de vuelta al Centro de eventos para impulsar la siguiente etapa.
La optimización automática de SQL de DAS constituye un ciclo cerrado impulsado por datos. La figura anterior ilustra todo el proceso de manera simplificada.
Cuando habilite el servicio de autonomía en el centro de autonomía de DAS, puede elegir si las sugerencias de optimización se aplican automáticamente o si requieren su aprobación antes de proceder.
Seguridad de los cambios
Los cambios automatizados en bases de datos de producción conllevan riesgos inherentes. DAS mitiga esta situación mediante tres capas de salvaguardas:
Verificaciones previas al cambio
Los cambios solo proceden cuando todas las métricas a continuación se encuentran dentro de rangos seguros:
Retraso de replicación entre instancias primaria y secundaria.
Carga de trabajo de la base de datos.
Uso del espacio de tablas.
Los cambios se restringen a la ventana de O&M configurada para evitar modificaciones durante los periodos de mayor tráfico.
Publicación canaria
En escenarios de sharding con grandes volúmenes de datos, DAS genera automáticamente un plan de publicación canaria que aplica los cambios por lotes en lugar de hacerlo simultáneamente. Durante la ejecución, DAS monitorea el retraso de replicación de forma continua. Si el retraso supera el umbral configurado, todas las tareas de cambio de índice para esa instancia se suspenden de inmediato. Solo se ejecuta una tarea de cambio por instancia a la vez.
Reversión automática
Después de cada cambio, el motor de decisiones rastrea el rendimiento de las sentencias SQL optimizadas y de las plantillas SQL relacionadas mediante un modelo de árbol de decisiones. Compara las métricas antes y después de la optimización tanto en sentencias SQL completas como en consultas lentas. Si el rendimiento se deteriora en cualquier momento durante la ventana de seguimiento de 24 horas, los cambios se revierten automáticamente sin necesidad de intervención manual.
Motores de base de datos compatibles
La optimización automática de SQL es compatible con los siguientes motores de base de datos: ApsaraDB RDS for MySQL, PolarDB for MySQL y ApsaraDB RDS for PostgreSQL.