Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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 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.
É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 avec EXPLAIN.
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 et distribution, 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 et sql_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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/31 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/31 (UTC)."],[],[],null,["# Optimize Looker performance\n\n\u003e *These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\nOptimize query performance\n--------------------------\n\n\nYou can ensure that queries are built and executed optimally against your database with the following frontend and backend tips:\n\n- Build Explores using [`many_to_one`](/looker/docs/reference/param-explore-join-relationship#many_to_one_(the_default_value)) joins whenever possible. Joining views from the most granular level to the highest level of detail (`many_to_one`) typically provides the best query performance.\n- Maximize caching to sync with your ETL policies wherever possible to reduce database query traffic. By default, Looker caches queries for one hour. You can control the caching policy and sync Looker data refreshes with your ETL process by applying [datagroups](/looker/docs/caching-and-datagroups) within Explores, using the [`persist_with`](/looker/docs/reference/param-explore-persist-with) parameter. This enables Looker to integrate more closely with the backend data pipeline, so cache usage can be maximized without the risk of analyzing stale data. Named caching policies can be applied to an entire model and/or to individual Explores and [persistent derived tables](/looker/docs/caching-and-datagroups#how_looker_uses_pdts_and_rebuilds_them) (PDTs).\n- Use Looker's [aggregate awareness](/looker/docs/aggregate_awareness) functionality to create roll-ups or summary tables that Looker can use for queries whenever possible, especially for common queries of large databases. You can also leverage aggregate awareness to drastically [improve the performance of entire dashboards](/looker/docs/reference/param-explore-aggregate-table#get_lookml_dashboard). See the [Aggregate awareness tutorial](/looker/docs/best-practices/aggregate-awareness-tutorial) for additional information.\n- Use [PDTs](/looker/docs/derived-tables#persistent_derived_table) for faster queries. Convert Explores with many complex or unperformant joins, or dimensions with subqueries or subselects, into PDTs so that the views are pre-joined and ready prior to runtime.\n- If your [database dialect supports incremental PDTs](/looker/docs/incremental-pdts#supported_database_dialects_for_incremental_pdts), configure [incremental PDTs](/looker/docs/incremental-pdts) to reduce the time Looker spends rebuilding PDT tables.\n- Avoid joining views into Explores on concatenated [primary keys](/looker/docs/reference/param-field-primary-key) that are defined in Looker. Instead, join on the base fields that make up the concatenated primary key from the view. Alternatively, recreate the view as a PDT with the concatenated primary key predefined in the table's SQL definition, rather than in a view's LookML.\n- Leverage the [Explain in SQL Runner tool](/looker/docs/sql-runner-manage-db#examining_an_execution_plan_using_explain) for benchmarking. `EXPLAIN` produces an overview of your database's query execution plan for a given SQL query, letting you detect query components that can be optimized. Learn more in the [How to optimize SQL with `EXPLAIN`](https://community.looker.com/technical-tips-tricks-1021/how-to-optimize-sql-with-explain-30772) Community post.\n- Declare indexes. You can look at the indexes of each table directly in Looker from [SQL Runner](/looker/docs/sql-runner-basics) by clicking the gear icon in a table and then selecting [**Show Indexes**](/looker/docs/sql-runner-manage-db#getting_table_information).\n\n \u003cbr /\u003e\n\n The most common columns that can benefit from indexes are important dates and foreign keys. Adding indexes to these columns will increase performance for almost all queries. This also applies for PDTs. LookML parameters, such as [`indexes`](/looker/docs/reference/param-view-indexes), [`sort keys`](/looker/docs/reference/param-view-sortkeys), and [`distribution`](/looker/docs/reference/param-view-distribution), can be applied appropriately.\n- Increase memory, cores, and I/O (input/output) of databases with insufficient hardware or necessary provisioned resources (such as AWS) for processing large datasets, to increase query performance.\n\nOptimize Looker server performance\n----------------------------------\n\n\nYou can also take measures to ensure that the Looker server and application are performing optimally:\n\n- Limit the number of elements within an individual dashboard. There is no precise rule for defining the number, because the design of each element impacts memory consumption based on a variety of factors; however, dashboards with 25 or more tiles tend to be problematic when it comes to performance.\n- Use the [dashboard auto refresh](/looker/docs/editing-user-defined-dashboards#autorefresh) feature strategically. If a dashboard uses auto refresh, make sure it refreshes no faster than the ETL processes running behind the scenes.\n- Use pivots strategically, and avoid over-using pivots within dashboard tiles and Looks. Queries with pivoted dimensions will consume more memory. The more dimensions that are pivoted, the more memory is consumed when content (an Explore, a Look, or a dashboard) is loaded.\n- Use features, such as [merge results](/looker/docs/merged-results), [custom fields](/looker/docs/custom-fields), and [table calculations](/looker/docs/table-calculations), sparingly. These features are intended to be used as proofs of concept to help design your model. It is best practice to hardcode any frequently used calculations and functions in LookML, which will generate SQL to be processed on your database. Excessive calculations can compete for Java memory on the Looker instance, causing the Looker instance to respond more slowly.\n- Limit the number of views included within a model when a large number of view files are present. Including all views in a single model can slow performance. When a large number of views are present within a project, consider including only the view files needed within each model. Consider using strategic naming conventions for view file names, to enable easy inclusion of groups of views within a model. An example is outlined in the [`includes`](/looker/docs/reference/param-model-include#things_to_know) parameter documentation.\n- Avoid returning a large number of data points by default within dashboard tiles and Looks. Queries that return thousands of data points will consume more memory. Ensure that data is limited wherever possible by applying frontend [filters](/looker/docs/filters-user-defined-dashboards#adding_dashboard_filters) to dashboards, Looks and Explores, and on the LookML level with [`required filters`](/looker/docs/filters-user-defined-dashboards#requiring_a_filter_value), [`conditionally_filter`](/looker/docs/reference/param-explore-conditionally-filter) and [`sql_always_where`](/looker/docs/reference/param-explore-sql-always-where) parameters.\n- Download or deliver queries using the [**All Results**](/looker/docs/downloading#all_results) option sparingly, as some queries can be very large and overwhelm the Looker server when processed.\n\n\nFor more help identifying the source of performance issues, check out the [Performance overview](/looker/docs/best-practices/how-to-optimize-looker-performance) Best Practices page."]]