Perlu diperhatikan bahwa Anda sedang melihat dokumentasi Looker. Untuk melihat dokumentasi Looker Studio, buka https://support.google.com/looker-studio.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengoptimalkan performa Looker

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.
Jika dialek database Anda mendukung PDT inkremental, konfigurasikan PDT inkremental untuk mengurangi waktu yang dihabiskan Looker untuk mem-build ulang tabel PDT.
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 Jelajah, 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.