Optimiser les requêtes dans ApsaraDB for SelectDB - ApsaraDB for SelectDB

ApsaraDB for SelectDB s'appuie sur l'optimiseur Nereids et le moteur d'exécution Pipeline pour optimiser automatiquement les requêtes. Pour répondre aux exigences de haute performance, vous pouvez également optimiser manuellement vos requêtes en utilisant l'accélération par index, les requêtes ponctuelles à forte concurrence, les vues matérialisées ou l'optimisation des jointures.

Planification automatique de l'optimisation des requêtes

Dans SelectDB, l'optimiseur Nereids et le moteur d'exécution Pipeline constituent les technologies centrales de traitement des requêtes. Elles permettent une optimisation approfondie lors des phases d'analyse et d'exécution, améliorant ainsi considérablement les performances des requêtes complexes et l'utilisation des ressources. La figure suivante illustre comment ces technologies optimisent une instruction SQL dans SelectDB.

Le tableau suivant décrit les principales fonctionnalités de chaque technologie. Pour plus d'informations, consultez la documentation correspondante.

Technologie	Description de la fonctionnalité
Nereids	Prend en charge les requêtes complexes, telles que les sous-requêtes imbriquées sur plusieurs niveaux et les jointures multi-tables. Réduit le risque d'erreurs logiques dans les règles d'optimisation.
Moteur d'exécution Pipeline	Améliore le taux d'utilisation du CPU. Atténue la contention des ressources entre les requêtes volumineuses et légères.

Optimisation manuelle des requêtes

Si l'optimiseur Nereids et le moteur d'exécution Pipeline de SelectDB ne répondent pas à vos besoins, utilisez les statistiques pour analyser les données de requête et sélectionnez la stratégie appropriée pour optimiser vos requêtes.

Stratégie d'optimisation	Cas d'usage	Limites
Requêtes ponctuelles à forte concurrence	Optimisation des requêtes ponctuelles soumises à une forte concurrence. Remarque Une requête ponctuelle consiste à récupérer un petit volume de données répondant à des conditions spécifiques. Elle s'appuie généralement sur des clés primaires ou des colonnes à forte cardinalité.	L'activation du mode de stockage ligne consomme de l'espace de stockage supplémentaire. PreparedStatement prend uniquement en charge les requêtes ponctuelles basées sur la clé primaire.
Vue matérialisée synchrone	Optimisation des requêtes complexes, répétitives et coûteuses en temps de traitement.	Pour une table utilisant le modèle Unique Key, les vues matérialisées permettent de modifier l'ordre des colonnes, mais ne peuvent pas servir de fonctions d'agrégation. Par conséquent, il est impossible de créer des vues matérialisées sur ce type de table pour effectuer des opérations d'agrégation à granularité grossière. La création d'un nombre excessif de vues matérialisées dans une table affecte l'efficacité de l'importation des données. Pour plus d'informations, consultez la rubrique Vue matérialisée synchrone.
Accélération par index	Accélération des requêtes ou localisation rapide des données dans n'importe quel scénario.	Les limites dépendent du type d'index. Pour plus de détails, consultez la rubrique Accélération par index.
Bucket Shuffle Join	Optimisation des requêtes avec jointure.	La condition de jointure doit inclure la colonne de distribution de la table de gauche, et cette dernière ne doit utiliser les données que d'une seule partition durant l'exécution.
Colocation Join	Optimisation des requêtes avec jointure.	La condition de jointure doit contenir la colonne de distribution de la table de gauche, et les tables de gauche et de droite doivent appartenir au même Colocate Group.
Runtime filter	Optimisation des scénarios impliquant la jointure d'une grande table avec une petite table.	L'utilisation d'un Runtime filter impose que l'instruction JOIN respecte les conditions suivantes : La table de gauche est volumineuse et celle de droite est petite. La construction d'un Runtime filter engendre des coûts de calcul, notamment une surcharge mémoire. Le jeu de résultats de la jointure est de taille réduite. Un petit jeu de résultats indique que l'instruction JOIN a filtré la majeure partie des données de la table de gauche.
Déduplication précise avec BITMAP	Scénarios exigeant des résultats de déduplication exacts portant sur des millions d'enregistrements. Scénarios disposant de ressources de stockage suffisantes.	Contraintes liées aux types de données : Les entiers de type TINYINT, SMALLINT, INT et BIGINT peuvent être utilisés directement. Les valeurs non entières, telles que les chaînes de caractères, peuvent être utilisées après avoir été mappées à des entiers via un dictionnaire global. Cela accroît les coûts de maintenance. Contraintes mémoire : si la cardinalité des données est élevée (plusieurs milliards d'enregistrements), Bitmap doit stocker un grand tableau de bits. Cela augmente considérablement la consommation de mémoire et peut entraîner une insuffisance des ressources mémoire.
Déduplication approximative via la fonctionnalité HLL	Traitement de volumes massifs de données (milliards d'enregistrements) lorsqu'une marge d'erreur est acceptable (par exemple, une valeur de métrique analytique imprécise). Fusion efficace de résultats au sein de systèmes distribués.	Perte de précision : les résultats obtenus ne sont pas exacts. Le taux d'erreur diminue à mesure que la cardinalité des données augmente ; ainsi, plus la cardinalité est élevée, plus le taux d'erreur relatif est faible. Configuration appropriée des paramètres : la précision de HyperLogLog (HLL) dépend de paramètres tels que le nombre de registres et de bits de hachage. Un réglage inadapté peut nuire à la précision des résultats.