Bagikan melalui


Praktik terbaik untuk kueri Bahasa Kueri Kusto

Berlaku untuk: ✅Microsoft Fabric✅Azure Data ExplorerAzure MonitorMicrosoft Sentinel

Berikut adalah beberapa praktik terbaik yang harus diikuti untuk membuat kueri Anda berjalan lebih cepat.

Singkatnya

Perbuatan Menggunakan Jangan gunakan Catatan
Mengurangi jumlah data yang sedang dikueri Gunakan mekanisme seperti where operator untuk mengurangi jumlah data yang sedang diproses. Untuk informasi selengkapnya tentang cara efisien untuk mengurangi jumlah data yang sedang diproses, lihat Mengurangi jumlah data yang sedang diproses.
Hindari menggunakan referensi berkualifikasi redundan Saat mereferensikan entitas lokal, gunakan nama yang tidak memenuhi syarat. Untuk informasi selengkapnya, lihat Menghindari penggunaan referensi berkualifikasi redundan.
datetime Kolom datetime Gunakan jenis data. Jangan gunakan long jenis data. Dalam kueri, jangan gunakan fungsi konversi waktu Unix, seperti unixtime_milliseconds_todatetime(). Sebagai gantinya, gunakan kebijakan pembaruan untuk mengonversi waktu Unix ke datetime jenis data selama penyerapan.
Operator string Gunakan operator has. Jangan gunakan contains Saat mencari token penuh, has bekerja lebih baik, karena tidak mencari substring.
Operator peka huruf besar/kecil Gunakan ==. Jangan gunakan =~. Gunakan operator peka huruf besar/kecil jika memungkinkan.
Gunakan in. Jangan gunakan in~.
Gunakan contains_cs. Jangan gunakan contains. Menggunakan has/has_cs lebih disukai untuk contains/contains_cs.
Mencari teks Lihat di kolom tertentu. Jangan gunakan *. * melakukan pencarian teks penuh di semua kolom.
Mengekstrak bidang dari objek dinamis di jutaan baris Materialisasikan kolom Anda pada waktu penyerapan jika sebagian besar kueri Anda mengekstrak bidang dari objek dinamis di jutaan baris. Dengan metode ini Anda hanya membayar sekali untuk ekstraksi kolom.
Mencari kunci/nilai langka dalam objek dinamis Gunakan MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value". Jangan gunakan MyTable | where DynamicColumn.SomeKey == "Rare value". Dengan metode ini Anda memfilter sebagian besar rekaman dan hanya melakukan penguraian JSON pada sisanya.
let pernyataan dengan nilai yang Anda gunakan lebih dari sekali Gunakan fungsi materialize(). Untuk informasi selengkapnya tentang cara menggunakan materialize(), lihat materialize(). Untuk informasi selengkapnya, lihat Mengoptimalkan kueri yang menggunakan ekspresi bernama.
Menerapkan konversi jenis pada lebih dari satu miliar rekaman Membentuk kembali kueri Anda untuk mengurangi jumlah data yang dimasukkan ke dalam konversi. Jangan mengonversi data dalam jumlah besar jika dapat dihindari.
Kueri baru Gunakan limit [small number] atau count di akhir. Menjalankan kueri yang tidak terikat melalui himpunan data yang tidak diketahui dapat menghasilkan pengembalian gigabyte hasil, menghasilkan respons yang lambat dan lingkungan yang sibuk.
Perbandingan tidak peka huruf besar/kecil Gunakan Col =~ "lowercasestring". Jangan gunakan tolower(Col) == "lowercasestring".
Membandingkan data yang sudah dalam huruf kecil (atau huruf besar) Col == "lowercasestring" (atau Col == "UPPERCASESTRING"). Hindari menggunakan perbandingan tidak peka huruf besar/kecil.
Pemfilteran pada kolom Filter pada kolom tabel. Jangan memfilter pada kolom terhitung.
Menggunakan T | where predicate(*Expression*) Jangan gunakan T | extend _value = *Expression* | where predicate(_value)
operator ringkas Gunakan hint.shufflekey=<key> saat group by keys summarize operator memiliki kardinalitas tinggi. Kardinalitas tinggi idealnya lebih dari satu juta.
operator gabungan Pilih tabel dengan baris terkecil sebagai baris pertama (paling kiri dalam kueri).
Gunakan in alih-alih left semi join untuk memfilter dengan satu kolom.
Bergabung di seluruh kluster Jalankan kueri di sisi "kanan" gabungan di seluruh lingkungan jarak jauh, seperti kluster atau Eventhouses, tempat sebagian besar data berada.
Gabungkan saat sisi kiri kecil dan sisi kanan besar Gunakan hint.strategy=broadcast. Kecil mengacu pada hingga 100 megabyte (MB) data.
Gabungkan ketika sisi kanan kecil dan sisi kiri besar Gunakan operator pencarian alih-alih join operator Jika sisi kanan pencarian lebih besar dari beberapa puluh MB, kueri gagal.
Gabungkan ketika kedua sisi terlalu besar Gunakan hint.shufflekey=<key>. Gunakan saat kunci bergabung memiliki kardinalitas tinggi.
Ekstrak nilai pada kolom dengan string yang berbagi format atau pola yang sama Gunakan operator penguraian. Jangan gunakan beberapa pernyataan extract(). Misalnya, nilai seperti "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
fungsi extract() Gunakan saat string yang diurai tidak semuanya mengikuti format atau pola yang sama. Ekstrak nilai yang diperlukan dengan menggunakan REGEX.
fungsi materialize() Dorong semua operator yang mungkin mengurangi himpunan data terwujud dan tetap menyimpan semantik kueri. Misalnya, filter, atau kolom yang hanya diperlukan proyek. Untuk informasi selengkapnya, lihat Mengoptimalkan kueri yang menggunakan ekspresi bernama.
Menggunakan tampilan materialisasi Gunakan tampilan materialisasi untuk menyimpan agregasi yang umum digunakan. Lebih suka menggunakan materialized_view() fungsi untuk mengkueri bagian yang terwujud saja. materialized_view('MV')

Mengurangi jumlah data yang sedang diproses

Performa kueri bergantung langsung pada jumlah data yang perlu diproses. Semakin sedikit data yang diproses, semakin cepat kueri (dan semakin sedikit sumber daya yang digunakannya). Oleh karena itu, praktik terbaik yang paling penting adalah menyusun kueri sedih sehingga mengurangi jumlah data yang sedang diproses.

Catatan

Dalam diskusi berikut, penting untuk diingat konsep pemilihan filter. Selektivitas adalah persentase rekaman yang difilter saat memfilter berdasarkan beberapa predikat. Predikat yang sangat selektif berarti bahwa hanya beberapa catatan yang tersisa setelah menerapkan predikat, mengurangi jumlah data yang kemudian perlu diproses secara efektif.

Dalam urutan kepentingan:

  • Hanya tabel referensi yang datanya diperlukan oleh kueri. Misalnya, saat menggunakan union operator dengan referensi tabel kartubebas, lebih baik dari sudut pandang performa untuk hanya mereferensikan beberapa tabel, alih-alih menggunakan kartubebas (*) untuk mereferensikan semua tabel lalu memfilter data menggunakan predikat pada nama tabel sumber.

  • Manfaatkan cakupan data tabel jika kueri hanya relevan untuk cakupan tertentu. Fungsi table() menyediakan cara yang efisien untuk menghilangkan data dengan mencakupnya sesuai dengan kebijakan penembolokan ( parameter DataScope ).

  • Terapkan where operator kueri segera mengikuti referensi tabel.

  • Saat menggunakan where operator kueri, urutan tempat Anda menempatkan predikat, baik Anda menggunakan operator tunggal where , atau beberapa operator berturut-turut where , dapat memiliki efek signifikan pada performa kueri.

  • Terapkan predikat seluruh shard terlebih dahulu. Ini berarti bahwa predikat yang menggunakan fungsi extent_id() dan fungsi extent_tags() harus diterapkan terlebih dahulu. Selain itu, ketika Anda memiliki predikat selektif yang mempersempit data ke partisi tertentu, mereka harus diterapkan terlebih dahulu.

  • Kemudian terapkan predikat yang bertindak berdasarkan datetime kolom tabel. Kusto menyertakan indeks yang efisien pada kolom tersebut, seringkali sepenuhnya menghilangkan seluruh pecahan data tanpa perlu mengakses pecahan tersebut.

  • Kemudian terapkan predikat yang bertindak berdasarkan string dan dynamic kolom, terutama predikat seperti itu yang berlaku pada tingkat istilah. Urutkan predikat berdasarkan selektivitas. Misalnya, mencari ID pengguna ketika ada jutaan pengguna sangat selektif dan biasanya melibatkan pencarian istilah, yang indeksnya sangat efisien.

  • Kemudian terapkan predikat yang selektif dan didasarkan pada kolom numerik.

  • Terakhir, untuk kueri yang memindai data kolom tabel (misalnya, untuk predikat seperti contains "@!@!", yang tidak memiliki istilah dan tidak mendapat manfaat dari pengindeksan), urutkan predikat sederajat sehingga yang memindai kolom dengan lebih sedikit data adalah yang pertama. Melakukannya mengurangi kebutuhan untuk mendekompresi dan memindai kolom besar.

Hindari menggunakan referensi berkualifikasi redundan

Entitas referensi seperti tabel dan tampilan materialisasi berdasarkan nama.

Misalnya, tabel T dapat dirujuk sebagai sederhana T ( nama yang tidak memenuhi syarat), atau dengan menggunakan kualifikasi database (misalnya, database("DB").T ketika tabel berada dalam database yang disebut DB), atau dengan menggunakan nama yang sepenuhnya memenuhi syarat (misalnya, cluster("<serviceURL>").database("DB").T).

Misalnya, tabel T dapat dirujuk sebagai sederhana T ( nama yang tidak memenuhi syarat), atau dengan menggunakan kualifikasi database (misalnya, database("DB").T ketika tabel berada dalam database yang disebut DB), atau dengan menggunakan nama yang sepenuhnya memenuhi syarat (misalnya, cluster("X.Y.kusto.windows.net").database("DB").T).

Ini adalah praktik terbaik untuk menghindari penggunaan kualifikasi nama saat berlebihan, karena alasan berikut:

  1. Nama yang tidak memenuhi syarat lebih mudah diidentifikasi (untuk pembaca manusia) sebagai milik database dalam cakupan.

  2. Mereferensikan entitas dalam cakupan database selalu setidaknya secepat, dan dalam beberapa kasus jauh lebih cepat, maka entitas yang termasuk dalam database lain.

Ini terutama berlaku ketika database tersebut berada di kluster yang berbeda.

Ini terutama berlaku ketika database tersebut berada di Eventhouse yang berbeda.

Menghindari nama yang memenuhi syarat membantu pembaca untuk melakukan hal yang benar.

Catatan

Ini tidak berarti bahwa nama yang memenuhi syarat buruk untuk performa. Bahkan, Kusto dapat dalam banyak kasus untuk mengidentifikasi kapan nama yang sepenuhnya memenuhi syarat mereferensikan entitas milik database dalam cakupan dan "sirkuit pendek" kueri sehingga tidak dianggap sebagai kueri lintas kluster. Namun, kami tidak menyarankan untuk mengandalkan ini jika tidak perlu.

Catatan

Ini tidak berarti bahwa nama yang memenuhi syarat buruk untuk performa. Bahkan, Kusto dapat dalam banyak kasus untuk mengidentifikasi kapan nama yang sepenuhnya memenuhi syarat mereferensikan entitas milik database dalam cakupan. Namun, kami tidak menyarankan untuk mengandalkan ini jika tidak perlu.