Ces bonnes pratiques reflètent les recommandations partagées par une équipe interfonctionnelle de chercheurs expérimentés. Ces insights sont issus de nos années d'expérience auprès des clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour fonctionner pour la plupart des utilisateurs et des situations, mais vous devez faire preuve de bon sens lors de leur implémentation.
Optimiser les performances des requêtes
Vous pouvez vous assurer que les requêtes sont créées et exécutées de manière optimale sur votre base de données grâce aux conseils de front-end et de backend suivants:
-
Dans la mesure du possible, créez des explorations à l'aide de jointures
many_to_one
. Associer des vues du niveau le plus détaillé au niveau le plus détaillé (many_to_one
) offre généralement les meilleures performances de requête. -
Maximisez la mise en cache pour vous synchroniser avec vos règles ETL dans la mesure du possible afin de réduire le trafic de requêtes de base de données. Par défaut, Looker met en cache les requêtes pendant une heure. Vous pouvez contrôler la stratégie de mise en cache et synchroniser les actualisations de données Looker avec votre processus ETL en appliquant des groupes de données dans les explorations à l'aide du paramètre
persist_with
. Cela permet à Looker de s'intégrer plus étroitement au pipeline de données backend. L'utilisation du cache peut ainsi être maximisée sans risque d'analyser des données obsolètes. Les règles de mise en cache nommées peuvent être appliquées à l'ensemble d'un modèle et/ou à des explorations et des tables dérivées persistantes (PDT) individuelles. - Utilisez la fonctionnalité de connaissance des agrégats de Looker pour créer des agrégations ou des tableaux récapitulatifs que Looker peut utiliser pour les requêtes dans la mesure du possible, en particulier pour les requêtes courantes de grandes bases de données. Vous pouvez également exploiter la reconnaissance d'agrégats pour améliorer considérablement les performances de l'ensemble des tableaux de bord. Pour en savoir plus, consultez le tutoriel sur la sensibilisation globale.
- Utilisez des PDT pour accélérer les requêtes. Convertissez les explorations contenant de nombreuses jointures complexes ou peu performantes, ou des dimensions avec des sous-requêtes ou des sous-sélections, en fichiers PDT afin que les vues soient pré-jointes et prêtes avant l'exécution.
- Si votre dialecte de base de données est compatible avec les augmentations de tables PDT, configurez les augmentations de tables PDT pour réduire le temps que Looker passe à regénérer les tables PDT.
- Évitez d'associer des vues à des explorations sur des clés primaires concatenantes définies dans Looker. À la place, effectuez une jointure sur les champs de base qui constituent la clé primaire concaténée à partir de la vue. Vous pouvez également recréer la vue en tant que PDT avec la clé primaire concaténée prédéfinie dans la définition SQL de la table, plutôt que dans le code LookML d'une vue.
- Utilisez l'outil Explain in SQL Runner pour effectuer des analyses comparatives.
EXPLAIN
fournit un aperçu du plan d'exécution de requêtes de votre base de données pour une requête SQL donnée, ce qui vous permet de détecter les composants de requête pouvant être optimisés. Pour en savoir plus, consultez le post destiné à la communauté Comment optimiser SQL avecEXPLAIN
. -
Déclarer des index. Vous pouvez consulter les index de chaque table directement dans Looker depuis SQL Runner en cliquant sur l'icône en forme de roue dentée d'un tableau, puis en sélectionnant Afficher les index.
Les colonnes les plus courantes qui peuvent bénéficier d'index sont les dates importantes et les clés étrangères. L'ajout d'index à ces colonnes améliore les performances de presque toutes les requêtes. Cela s'applique également aux tables PDT. Les paramètres LookML, tels que
indexes
,sort keys
etdistribution
, peuvent être appliqués de manière appropriée. - Augmentez la mémoire, les cœurs et les E/S (entrées/sorties) des bases de données dont le matériel ou les ressources provisionnées (telles qu'AWS) sont insuffisants pour traiter de grands ensembles de données, afin d'améliorer les performances des requêtes.
Optimiser les performances du serveur Looker
Vous pouvez également prendre des mesures pour vous assurer que le serveur et l'application Looker fonctionnent de manière optimale:
- Limitez le nombre d'éléments dans un tableau de bord spécifique. Il n'existe pas de règle précise pour définir ce nombre, car la conception de chaque élément a un impact sur la consommation de mémoire en fonction de divers facteurs. Toutefois, les tableaux de bord comportant 25 tuiles ou plus ont tendance à poser problème en termes de performances.
- Utilisez la fonctionnalité d'actualisation automatique du tableau de bord de manière stratégique. Si un tableau de bord utilise l'actualisation automatique, assurez-vous qu'il ne s'actualise pas plus rapidement que les processus ETL exécutés en arrière-plan.
- Utilisez les pivots de manière stratégique et évitez de les utiliser à outrance dans les cartes de tableau de bord et les présentations. Les requêtes avec des dimensions pivotées consomment plus de mémoire. Plus vous pivotez des dimensions, plus la mémoire est utilisée lorsque le contenu (une exploration, une présentation ou un tableau de bord) est chargé.
- Utilisez les fonctionnalités telles que les résultats de fusion, les champs personnalisés et les calculs de table avec parcimonie. Ces fonctionnalités sont destinées à servir de preuve de concept pour vous aider à concevoir votre modèle. Il est recommandé de coder en dur tous les calculs et fonctions fréquemment utilisés dans LookML, ce qui génère du code SQL à traiter dans votre base de données. Des calculs excessifs peuvent entrer en concurrence pour la mémoire Java de l'instance Looker, ce qui ralentit sa réponse.
-
Limitez le nombre de vues incluses dans un modèle lorsque de nombreux fichiers de vue sont présents. Inclure toutes les vues dans un seul modèle peut ralentir les performances. Lorsqu'un projet comporte un grand nombre de vues, envisagez de n'inclure que les fichiers de vue nécessaires dans chaque modèle. Envisagez d'utiliser des conventions de nommage stratégiques pour les noms de fichiers de vue afin de pouvoir inclure facilement des groupes de vues dans un modèle. Un exemple est décrit dans la documentation du paramètre
includes
. -
Évitez de renvoyer un grand nombre de points de données par défaut dans les cartes de tableau de bord et les looks. Les requêtes qui renvoient des milliers de points de données consomment plus de mémoire. Assurez-vous que les données sont limitées dans la mesure du possible en appliquant des
filtres côté client aux tableaux de bord, aux looks et aux explorations, et au niveau de LookML avec les paramètres
required filters
,conditionally_filter
etsql_always_where
. - Téléchargez ou envoyez des requêtes à l'aide de l'option Tous les résultats avec parcimonie, car certaines requêtes peuvent être très volumineuses et submerger le serveur Looker lors de leur traitement.
Pour vous aider à identifier la source des problèmes de performances, consultez la page des bonnes pratiques sur la présentation des performances.