Conseils d’optimisation des performances pour le pool SQL serverless Azure Synapse Analytics

Article
11/20/2024

S’applique à : Azure Synapse Analytics

Cet article vous aide à améliorer les performances du pool SQL serverless Azure Synapse Analytics.

Note

Passez en revue la liste des problèmes connus actuellement actifs ou récemment résolus dans Azure Synapse Analytics.

Consultez les sections suivantes pour plus d’informations sur la façon d’obtenir des performances optimales et d’éviter les défaillances liées aux contraintes de ressources sur vos pools SQL serverless Azure Synapse Analytics.

Meilleures pratiques et guides de résolution des problèmes

Les informations et les stratégies décrites dans les articles suivants peuvent vous aider à tirer le meilleur parti des performances de votre pool SQL serverless. Nous vous recommandons d’utiliser ces articles pour examiner les cas d’usage et résoudre les problèmes courants.

Comprendre la mise à l’échelle sur un pool SQL serverless

Les pools SQL serverless ne nécessitent pas de sélectionner manuellement la taille appropriée. Le système ajuste automatiquement la taille en fonction des besoins de votre requête, et gère ainsi l’infrastructure et sélectionne la taille appropriée pour votre solution.

Conseils d’optimisation des performances pour les fichiers Delta Lake

Pour plus d’informations sur le réglage des performances pour les fichiers Delta Lake, consultez les ressources suivantes :

Conseils sur le réglage des performances pour les fichiers CSV

Lorsque vous interrogez des fichiers CSV sur un pool SQL serverless, la tâche la plus importante pour garantir des performances élevées consiste à créer des statistiques sur les tables externes. Bien que les statistiques soient créées automatiquement sur des fichiers Parquet et CSV et accessibles à l’aide OPENQUERY()de , la lecture des fichiers CSV à l’aide de tables externes vous oblige à créer manuellement des statistiques.

Pour plus d’informations sur le rôle des statistiques dans l’interrogation de fichiers CSV dans des pools SQL serverless, consultez les articles suivants :

Recommandations pour l’utilisation de Power BI et d’autres outils de création de rapports

Nous vous recommandons les meilleures pratiques suivantes lorsque vous utilisez Power BI et d’autres outils de création de rapports :

Toujours vérifier l’emplacement de votre locataire.
Configurer un cache pour une meilleure expérience utilisateur.
Éviter de retourner des millions d’enregistrements dans un tableau de bord.
Utilisez des actualisations planifiées pour éviter les exécutions de requêtes parallèles qui drainent les ressources du pool serverless SQL.
Utilisez Spark pour pré-agréger des requêtes analytiques courantes. Cette approche « écrire une fois/lire plusieurs » peut éviter les requêtes lourdes qui sont exécutées en continu.
Pour les jointures entre différents magasins de données : utilisez des filtres pour éviter les volumes Big Data qui ont été déplacés dans votre infrastructure Azure.
Utilisez Latin1_General_100_BIN2_UTF8 le classement pour les types de données caractères. Ce classement évite de transférer toutes les données du stockage vers votre pool SQL serverless en transmettant des filtres lorsque les outils lisent à partir du stockage.
Utilisez la taille la plus optimale, si vous convertissez ou convertissez des données en char une requête ou varchar lors de l’exécution d’une requête. Dans la mesure du possible, évitez d’utiliser VARCHAR(MAX).
L’inférence automatique convertit les types de données en un format qui peut ne pas être optimal. Utilisez la clause WITH pour optimiser les types de données.
Les ressources du pool serverless Azure Synapse SQL ont des limites. L’exécution de requêtes simultanément consomme des ressources. Il est courant de voir les tableaux de bord Power BI (PBI) atteindre des limites de ressources lorsque plusieurs actualisations se produisent en parallèle. Les actualisations planifiées et les tests de charge peuvent vous aider à éviter ce problème. En outre, l’utilisation de plusieurs espaces de travail Azure Synapse peut répondre à des exigences de concurrence plus importantes.
Vous pouvez exécuter la requête sys.columns ou l’utiliser sp_describe_first_result_set et select top 0 from <view> vérifier les types de données après avoir créé une vue. Cette approche est plus rapide et moins coûteuse que l’utilisation SELECT * FROM....
Utilisez le Générateur d’instructions pour créer automatiquement des formats de colonne optimaux pour votre requête.
Utilisez la OPENJSON fonction pour exposer les données JSON imbriquées en tant que colonnes. Mais si vous utilisez également la AS JSON commande, le type de colonne doit être NVARCHAR(MAX). Cette approche n’est pas idéale pour les performances. La meilleure option consiste à utiliser la clause WITH pour exposer des tableaux imbriqués en tant que colonnes.
La clé de partition de magasin transactionnel Cosmos DB n’est pas utilisée dans le magasin analytique. Dans Azure Synapse Link, vous pouvez à présent modéliser vos données transactionnelles pour optimiser l’ingestion des données et les lectures de point.

Conseils supplémentaires et meilleures pratiques

Catégorie	Documentation ou actions recommandées
Exploration des données	Azure Storage Stocker les résultats des requêtes sur le stockage Azure Entrepôt de données logique
OPENROWSET et tables externes	Fonction OPENROWSET Tables externes Procédures stockées Vues Transformations de données
Fonctionnalités T-SQL disponibles dans les pools SQL serverless	Fonctionnalités T-SQL dans des pools Azure Synapse

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Partager via