Database Autonomy Service (DAS) détecte automatiquement les requêtes lentes et les instructions SQL inefficaces, diagnostique leurs causes racines et applique des correctifs sans intervention manuelle. Ce service réduit la latence des requêtes et diminue la consommation de ressources en réécrivant les instructions SQL et en ajustant l'utilisation des index.
Pourquoi l'optimisation SQL manuelle atteint ses limites
Les administrateurs de base de données (DBA) et les développeurs font face à un problème croissant : les charges de travail SQL ne sont pas statiques. Les itérations métier, les changements dans la distribution des données, l'apparition de points chauds et les mises à niveau des versions de base de données modifient constamment les profils de performance. Suivre le rythme exige un temps et des effectifs disproportionnés.
L'optimisation manuelle présente deux faiblesses structurelles liées à deux moments clés :
T1 — lorsqu'une exception de performance est détectée et que l'optimisation commence
T2 — lorsque le correctif est appliqué et que l'instance revient à la normale
Dans les flux de travail traditionnels, T1 arrive tardivement, souvent après que le problème a dégradé l'expérience utilisateur pendant une période prolongée. L'écart entre T1 et T2 dépend entièrement de l'effort manuel, durant lequel le risque de défaillance s'accumule. À mesure que les volumes de données augmentent, ce modèle s'effondre : ajouter du personnel ne résout pas le problème.
La mise en place d'une optimisation SQL automatisée capable de boucler cette boucle est difficile selon six dimensions :
| Dimension | Défi |
|---|---|
| Précision | Détecter les bonnes exceptions au bon moment, sans bruit |
| Diagnostic | Générer des suggestions d'optimisation exploitables et hautement fiables |
| Sécurité | Garantir que les modifications en ligne ne déstabilisent pas la production |
| Exhaustivité | Suivre les résultats de l'optimisation sur plusieurs dimensions en temps réel |
| Coordination | Coordonner la limitation du débit SQL (throttling) et l'optimisation SQL pour traiter à la fois les symptômes et les causes racines |
| Échelle | Prendre en charge l'optimisation automatique sur des centaines de milliers à des millions de serveurs |
Fonctionnement
L'optimisation SQL automatique de DAS fonctionne comme une boucle fermée en cinq étapes. Chaque étape alimente la suivante, éliminant les lacunes laissées par les processus manuels.
Étape 1 : Détection
DAS surveille en continu les charges de travail pour trois types de problèmes : les nouvelles instructions SQL provoquant des requêtes lentes, les instructions SQL dont les performances se sont dégradées et les instructions SQL constamment inefficaces. La détection se déclenche dans trois conditions :
Analyse planifiée — les requêtes lentes sont analysées hors ligne selon une cadence régulière durant la fenêtre de maintenance
Dégradation en temps réel — l'algorithme de détection d'exceptions de charge de travail identifie les baisses de performance au fur et à mesure qu'elles se produisent ; pour les incidents complexes, la limitation automatique du débit SQL et l'optimisation SQL automatique s'activent conjointement
Changements de charge de travail — lorsque le SQL métier est publié ou retiré, DAS détecte que le volume de données ou la distribution des requêtes a dépassé ce que les index existants peuvent gérer
Étape 2 : Diagnostic
Les instructions SQL problématiques sont envoyées au moteur de diagnostic, qui utilise un modèle basé sur les coûts, la même approche que celle utilisée par les optimiseurs de base de données, pour évaluer chaque correctif possible. Les suggestions incluent la création d'index optimaux, la réécriture d'instructions SQL et la recommandation de moteurs. Chaque suggestion est notée selon son coût d'exécution, produisant un résultat quantitatif classé plutôt qu'une estimation heuristique.
La fonctionnalité de diagnostic et d'optimisation SQL est utilisée en production au sein du groupe Alibaba depuis des années, diagnostiquant environ 50 000 instructions SQL par jour à travers les applications métier du groupe. Le taux de réussite du diagnostic reste supérieur à 98 %, et le taux de recommandation pour les requêtes lentes dépasse 75 %.
Étape 3 : Planification
DAS évalue automatiquement le risque de chaque suggestion, génère un plan de déploiement canari et planifie les tâches d'optimisation en fonction de la charge de travail actuelle et du profil de l'instance. Aucune planification manuelle n'est requise.
Étape 4 : Application
Les modifications sont déployées durant la fenêtre de maintenance. Pour les scénarios de sharding avec de grands volumes de données, le plan de déploiement canari applique les modifications par lots. Pendant l'exécution, DAS surveille le délai de réplication entre les instances primaire et secondaire. Si le délai dépasse le seuil configuré, les tâches de modification d'index sont immédiatement suspendues, avec une seule tâche de modification exécutée par instance à tout moment.
Étape 5 : Vérification et validation
Une fois les modifications appliquées, le moteur de décision démarre une tâche de suivi couvrant à la fois les instructions SQL optimisées et les modèles SQL associés. Il utilise un modèle d'arbre de décision pour comparer les métriques de performance avant et après l'optimisation, en suivant les instructions SQL complètes et celles provoquant des requêtes lentes.
Le cycle de suivi par défaut est de 24 heures. Si les performances se dégradent à un moment donné, les modifications sont automatiquement annulées (rollback). Si aucune annulation ne se produit dans les 24 heures, l'optimisation est marquée comme réussie et les bénéfices réels de l'optimisation sont calculés.
Coordination pilotée par les événements à travers la boucle
Le centre d'événements DAS relie ces étapes entre elles. Les événements d'exception, provenant du système d'alerte, de la détection en temps réel, de l'analyse hors ligne ou de la surveillance de la charge de travail, convergent tous vers le centre d'événements. Après le diagnostic, DAS génère un nouvel événement d'optimisation et le renvoie au centre d'événements pour piloter l'étape suivante.
L'optimisation SQL automatique de DAS constitue une boucle fermée pilotée par les données. La figure précédente illustre l'ensemble du processus de manière simplifiée.
Lorsque vous activez le service d'autonomie dans le centre d'autonomie DAS, vous pouvez choisir si les suggestions d'optimisation sont appliquées automatiquement ou si elles nécessitent votre approbation avant de procéder.
Sécurité des modifications
Les modifications automatisées sur les bases de données de production comportent des risques inhérents. DAS y remédie grâce à trois couches de protection :
Vérifications préalables aux modifications
Les modifications ne sont effectuées que lorsque toutes les métriques suivantes restent dans des plages sûres :
Délai de réplication entre les instances primaire et secondaire
Charge de travail de la base de données
Utilisation de l'espace tablespace
Les modifications sont restreintes à la fenêtre de maintenance configurée, éloignant ainsi les interventions des périodes de trafic de pointe.
Déploiement canari
Pour les scénarios de sharding impliquant de grands volumes de données, DAS génère automatiquement un plan de déploiement canari qui applique les modifications par lots plutôt que d'un seul coup. Pendant l'exécution, DAS surveille continuellement le délai de réplication. Si le délai dépasse le seuil configuré, toutes les tâches de modification d'index pour cette instance sont immédiatement suspendues. Une seule tâche de modification s'exécute par instance à tout moment.
Annulation automatique (Rollback)
Après chaque modification, le moteur de décision suit les performances des instructions SQL optimisées et des modèles SQL associés à l'aide d'un modèle d'arbre de décision. Il compare les métriques avant et après l'optimisation pour les instructions SQL complètes et celles provoquant des requêtes lentes. Si les performances se dégradent à un moment donné durant la fenêtre de suivi de 24 heures, les modifications sont automatiquement annulées, sans intervention manuelle requise.
Moteurs de base de données pris en charge
L'optimisation SQL automatique prend en charge les moteurs de base de données suivants : ApsaraDB RDS for MySQL, PolarDB for MySQL et ApsaraDB RDS for PostgreSQL.