Les performances des requêtes dans AnalyticDB for MySQL dépendent de six facteurs : les spécifications du cluster, le nombre de nœuds, la distribution des données, le volume de données, la concurrence des requêtes et leur complexité. Comprendre l'impact de chaque facteur vous aide à choisir la taille de cluster appropriée, à concevoir des schémas de données favorisant l'exécution parallèle et à identifier la cause première des lenteurs.
Comment AnalyticDB for MySQL exécute les requêtes
AnalyticDB for MySQL utilise une architecture de traitement distribué des données. Lorsqu'une requête arrive, le moteur la décompose en étapes et exécute ces étapes en parallèle sur plusieurs nœuds. Chaque nœud traite sa part de données en mémoire. Tout élément qui perturbe la répartition équilibrée de la charge ou sature une ressource partagée dégrade les performances globales.
Spécifications du cluster
Chaque spécification de cluster définit une combinaison fixe de cœurs CPU, de taille de mémoire et de support de stockage. Ces attributs déterminent le plafond de traitement par nœud pour différents types de charges de travail :
Les requêtes intensives en JOIN ou en agrégations sont limitées par le CPU et la mémoire. Une spécification avec plus de cœurs CPU et une mémoire plus importante réduit le temps de traitement pour ces charges de travail.
Les requêtes intensives en balayage de données ou les agrégations simples sont limitées par les E/S disque. Une spécification avec des supports de stockage plus rapides améliore le débit pour ces charges de travail.
Sélectionnez une spécification qui correspond à votre profil de requêtes dominant. Pour les options disponibles, consultez la section Spécifications.
Nombre de nœuds
Plus de nœuds offrent une plus grande capacité de traitement parallèle. Étant donné qu'AnalyticDB for MySQL divise chaque requête en étapes qui s'exécutent simultanément sur différents nœuds, l'ajout de nœuds augmente la quantité totale de travail que le cluster peut effectuer par unité de temps.
Dimensionnez votre cluster en fonction du volume de requêtes et des exigences de latence. Pour obtenir des conseils, consultez la rubrique Créer un cluster.
Distribution des données
L'efficacité de l'exécution parallèle dépend directement de la distribution des données. Lorsque les données sont réparties uniformément entre les nœuds de stockage, tous les nœuds finalisent leurs sous-tâches approximativement au même moment. En revanche, si les données sont concentrées sur un sous-ensemble de nœuds, ceux-ci deviennent des goulets d'étranglement : leurs sous-tâches prennent beaucoup plus de temps, ce qui bloque l'ensemble de la requête.
Veillez à distribuer vos données aussi uniformément que possible entre les nœuds de stockage afin de maximiser l'efficacité du parallélisme.
Volume de données
AnalyticDB for MySQL traite les données de requête en mémoire plutôt que d'écrire les résultats intermédiaires sur le disque. Lorsqu'une requête porte sur un grand volume de données, elle conserve les ressources mémoire et CPU pendant une période prolongée, réduisant ainsi la capacité du cluster à gérer d'autres requêtes simultanément.
Les tables volumineuses exercent également une pression sur les E/S disque : le filtrage par index et la lecture détaillée des lignes génèrent une concurrence entre les requêtes simultanées pour la bande passante de stockage, ralentissant toutes les requêtes concernées.
Concurrence des requêtes
Le cluster ne peut gérer qu'un nombre limité de requêtes simultanées, défini par les ressources disponibles sur ses nœuds. Lorsque le nombre de requêtes concurrentes dépasse cette limite, les requêtes excédentaires sont mises en file d'attente dans le backend en attendant la libération de ressources. Plus la file d'attente est encombrée, plus la latence individuelle des requêtes augmente.
La limite de concurrence est déterminée à la fois par les spécifications du cluster et par sa taille.
Complexité des requêtes
Les requêtes complexes sollicitent de manière disproportionnée les ressources du cluster :
Conditions de filtrage larges : si un filtre ne permet pas d'éliminer rapidement la majorité des lignes, le moteur doit lire de grandes quantités de données brutes depuis les nœuds de stockage avant d'appliquer la condition.
Multiples JOIN : chaque opération JOIN peut nécessiter un brassage (shuffling) des données entre les nœuds via le réseau. Les chaînes de JOIN multiplient le nombre de transferts, augmentant ainsi le risque de congestion réseau.
Nombre élevé de colonnes GROUP BY : l'utilisation d'un grand nombre de colonnes dans une clause GROUP BY mobilise d'importantes ressources mémoire pour maintenir l'état d'agrégation, entrant en concurrence avec la mémoire nécessaire aux autres étapes de la requête.