Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Praktik terbaik ini mencerminkan rekomendasi yang dibagikan oleh tim lintas fungsional yang terdiri dari Looker berpengalaman. Insight ini berasal dari pengalaman bertahun-tahun bekerja dengan pelanggan Looker, mulai dari penerapan hingga kesuksesan jangka panjang. Praktik ini ditulis agar dapat digunakan oleh sebagian besar pengguna dan situasi, tetapi Anda harus menggunakan penilaian terbaik saat menerapkannya.
Mengoptimalkan performa kueri
Anda dapat memastikan bahwa kueri dibuat dan dijalankan secara optimal terhadap database dengan tips frontend dan backend berikut:
Buat Jelajah menggunakan join many_to_one jika memungkinkan. Menggabungkan tampilan dari tingkat yang paling terperinci ke tingkat detail tertinggi (many_to_one) biasanya memberikan performa kueri terbaik.
Maksimalkan penyimpanan dalam cache untuk disinkronkan dengan kebijakan ETL Anda jika memungkinkan untuk mengurangi traffic kueri database. Secara default, Looker menyimpan kueri dalam cache selama satu jam. Anda dapat mengontrol kebijakan penyimpanan dalam cache dan menyinkronkan pembaruan data Looker dengan proses ETL Anda dengan menerapkan datagroup
dalam Eksplorasi, menggunakan parameter persist_with. Hal ini memungkinkan Looker berintegrasi lebih erat dengan pipeline data backend, sehingga penggunaan cache dapat dimaksimalkan tanpa risiko menganalisis data yang sudah tidak berlaku. Kebijakan penyimpanan dalam cache yang dinamai dapat diterapkan ke seluruh model dan/atau ke setiap Jelajah dan tabel turunan persisten (PDT).
Gunakan fungsi pengetahuan gabungan Looker untuk membuat tabel gabungan atau ringkasan yang dapat digunakan Looker untuk kueri jika memungkinkan, terutama untuk kueri umum dari database besar. Anda juga dapat memanfaatkan kesadaran gabungan untuk meningkatkan performa seluruh dasbor secara drastis. Lihat Tutorial kesadaran gabungan untuk informasi tambahan.
Gunakan PDT untuk kueri yang lebih cepat. Konversi Jelajah dengan banyak join yang rumit atau tidak berperforma baik, atau dimensi dengan subkueri atau subseleksi, menjadi PDT sehingga tampilan telah disambungkan sebelumnya dan siap sebelum runtime.
Hindari menggabungkan tampilan ke Jelajah pada kunci utama yang digabungkan dan ditentukan di Looker. Sebagai gantinya, gabungkan kolom dasar yang membentuk kunci utama yang digabungkan dari tampilan. Atau, buat ulang tampilan sebagai PDT dengan kunci utama yang digabungkan yang telah ditentukan sebelumnya dalam definisi SQL tabel, bukan dalam LookML tampilan.
Manfaatkan alat Explain in SQL Runner untuk benchmark. EXPLAIN menghasilkan ringkasan rencana eksekusi kueri database untuk kueri SQL tertentu, sehingga Anda dapat mendeteksi komponen kueri yang dapat dioptimalkan. Pelajari lebih lanjut di Postingan komunitas Cara mengoptimalkan SQL dengan EXPLAIN.
Mendeklarasikan indeks. Anda dapat melihat indeks setiap tabel langsung di Looker dari SQL Runner dengan mengklik ikon roda gigi di tabel, lalu memilih Show Indexes.
Kolom yang paling umum yang dapat memanfaatkan indeks adalah tanggal penting dan kunci asing. Menambahkan indeks ke kolom ini akan meningkatkan performa untuk hampir semua kueri. Hal ini juga berlaku untuk PDT. Parameter LookML, seperti indexes, sort keys, dan distribution, dapat diterapkan dengan tepat.
Tingkatkan memori, core, dan I/O (input/output) database dengan hardware yang tidak memadai atau resource yang disediakan yang diperlukan (seperti AWS) untuk memproses set data besar, guna meningkatkan performa kueri.
Mengoptimalkan performa server Looker
Anda juga dapat mengambil langkah-langkah untuk memastikan server dan aplikasi Looker berperforma optimal:
Membatasi jumlah elemen dalam setiap dasbor. Tidak ada aturan yang tepat untuk menentukan jumlah kartu, karena desain setiap elemen memengaruhi konsumsi memori berdasarkan berbagai faktor; namun, dasbor dengan 25 kartu atau lebih cenderung bermasalah dalam hal performa.
Gunakan fitur pemuatan ulang otomatis dasbor secara strategis. Jika dasbor menggunakan pembaruan otomatis, pastikan pembaruan tidak lebih cepat dari proses ETL yang berjalan di balik layar.
Gunakan pivot secara strategis, dan hindari penggunaan pivot secara berlebihan dalam kartu dasbor dan Tampilan. Kueri dengan dimensi yang diputar akan menggunakan lebih banyak memori. Makin banyak dimensi yang diputar, makin banyak memori yang digunakan saat konten (Jelajahi, Tampilan, atau dasbor) dimuat.
Gunakan fitur, seperti menggabungkan hasil, kolom kustom, dan penghitungan tabel, seperlunya.
Fitur ini dimaksudkan untuk digunakan sebagai bukti konsep untuk membantu mendesain model Anda.
Praktik terbaiknya adalah melakukan hardcode pada penghitungan dan fungsi yang sering digunakan di LookML, yang akan menghasilkan SQL untuk diproses di database Anda.
Penghitungan yang berlebihan dapat bersaing untuk mendapatkan memori Java di instance Looker, sehingga menyebabkan instance Looker merespons lebih lambat.
Membatasi jumlah tampilan yang disertakan dalam model jika ada banyak file tampilan. Menyertakan semua tampilan dalam satu model dapat memperlambat performa. Jika ada banyak tampilan dalam project, sebaiknya sertakan hanya file tampilan yang diperlukan dalam setiap model. Pertimbangkan untuk menggunakan konvensi penamaan strategis untuk nama file tampilan, agar mudah menyertakan grup tampilan dalam model. Contohnya diuraikan dalam dokumentasi parameter includes.
Hindari menampilkan titik data dalam jumlah besar secara default dalam kartu dasbor dan Tampilan. Kueri yang menampilkan ribuan titik data akan menggunakan lebih banyak memori. Pastikan data dibatasi jika memungkinkan dengan menerapkan
filter frontend ke dasbor, Look, dan Eksplorasi, serta di tingkat LookML dengan parameter required filters, conditionally_filter, dan sql_always_where.
Download atau kirim kueri menggunakan opsi Semua Hasil seperlunya, karena beberapa kueri dapat berukuran sangat besar dan membebani server Looker saat diproses.
Untuk mendapatkan bantuan lebih lanjut dalam mengidentifikasi sumber masalah performa, lihat halaman Praktik Terbaik Ringkasan performa.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
