Batas kueri

  • Artikel

Kusto adalah mesin kueri ad-hoc yang menghosting himpunan data besar dan mencoba memenuhi kueri dengan menyimpan semua data yang relevan dalam memori. Ada risiko yang melekat bahwa kueri akan memonopoli sumber daya layanan tanpa batas. Kusto menyediakan beberapa perlindungan bawaan dalam bentuk batas kueri default. Jika Anda mempertimbangkan untuk menghapus batas ini, pertama-tama tentukan apakah Anda benar-benar mendapatkan nilai apa pun dengan melakukannya.

Membatasi konkurensi permintaan

Konkurensi permintaan adalah batas yang dikenakan kluster pada beberapa permintaan yang berjalan pada saat yang bersamaan.

  • Nilai default batas bergantung pada SKU yang dijalankan kluster, dan dihitung sebagai: Cores-Per-Node x 10.
    • Misalnya, untuk kluster yang disiapkan pada SKU D14v2, di mana setiap komputer memiliki 16 vCore, batas defaultnya adalah 16 cores x10 = 160.
  • Nilai default dapat diubah dengan mengonfigurasi kebijakan batas tingkat permintaan grup beban kerja default.
    • Jumlah aktual permintaan yang dapat berjalan secara bersamaan pada kluster bergantung pada berbagai faktor. Faktor yang paling dominan adalah SKU kluster, sumber daya kluster yang tersedia, dan pola penggunaan. Kebijakan ini dapat dikonfigurasi berdasarkan uji beban yang dilakukan pada pola penggunaan seperti produksi.

Untuk informasi selengkapnya, lihat Mengoptimalkan konkurensi tinggi dengan Azure Data Explorer.

Membatasi ukuran tataan hasil (pemotongan hasil)

Pemotongan hasil adalah batas yang ditetapkan secara default pada tataan hasil yang dikembalikan oleh kueri. Kusto membatasi jumlah rekaman yang dikembalikan ke klien menjadi 500.000, dan ukuran data keseluruhan untuk rekaman tersebut menjadi 64 MB. Ketika salah satu dari batas ini terlampaui, kueri gagal dengan "kegagalan kueri parsial". Melebihi ukuran data secara keseluruhan akan menghasilkan pengecualian dengan pesan:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

Melebihi jumlah rekaman akan gagal dengan pengecualian yang mengatakan:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Ada beberapa strategi untuk mengatasi kesalahan ini.

  • Kurangi ukuran tataan hasil dengan mengubah kueri untuk hanya mengembalikan data yang menarik. Strategi ini berguna ketika kueri gagal awal terlalu "lebar". Misalnya, kueri tidak memproyeksikan kolom data yang tidak diperlukan.
  • Kurangi ukuran tataan hasil dengan menggeser pemrosesan pasca-kueri, seperti agregasi, ke dalam kueri itu sendiri. Strategi ini berguna dalam skenario saat output kueri dimasukkan ke sistem pemrosesan lain, dan kemudian melakukan agregasi lainnya.
  • Beralih dari kueri ke menggunakan ekspor data saat Anda ingin mengekspor kumpulan data besar dari layanan.
  • Instruksikan layanan untuk menekan batas kueri ini menggunakan set pernyataan yang tercantum di bawah ini atau bendera di properti permintaan klien.

Metode untuk mengurangi ukuran tataan hasil yang dihasilkan oleh kueri meliputi:

Anda dapat menonaktifkan pemotongan hasil dengan menggunakan opsi permintaan notruncation. Kami menyarankan agar beberapa bentuk pembatasan masih diberlakukan.

Contohnya:

set notruncation;
MyTable | take 1000000

Anda juga dapat memiliki kontrol yang lebih halus atas pemotongan hasil dengan mengatur nilai truncationmaxsize (ukuran data maksimum dalam byte, secara default hingga 64 MB) dan truncationmaxrecords (jumlah maksimum catatan, secara default hingga 500.000). Misalnya, kueri berikut menetapkan pemotongan hasil untuk terjadi pada 1.105 rekaman atau 1 MB, mana pun yang terlampaui.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Menghapus batas pemotongan hasil berarti Anda berniat untuk memindahkan data massal dari Kusto.

Anda dapat menghapus batas pemotongan hasil baik untuk tujuan ekspor dengan menggunakan perintah .export atau untuk agregasi nanti. Jika Anda memilih agregasi nanti, pertimbangkan untuk mengagregasi dengan menggunakan Kusto.

Kusto menyediakan sejumlah pustaka klien yang dapat menangani hasil "sangat besar" dengan mengalirkannya ke pemanggil. Gunakan salah satu pustaka ini, dan konfigurasikan ke mode streaming. Misalnya, gunakan klien .NET Framework (Microsoft.Azure.Kusto.Data) dan atur properti streaming string koneksi ke true, atau gunakan panggilan ExecuteQueryV2Async() yang selalu mengalirkan hasil. Untuk contoh cara menggunakan ExecuteQueryV2Async(), lihat aplikasi HelloKustoV2.

Anda juga dapat menemukan aplikasi sampel konsumsi streaming C # bermanfaat.

Pemotongan hasil diterapkan secara default, bukan hanya ke aliran hasil yang dikembalikan ke klien. Ini juga diterapkan secara default ke subkueri apa pun yang diterbitkan satu kluster ke kluster lain dalam kueri lintas kluster, dengan efek serupa.

Mengatur beberapa properti pemotongan hasil

Berikut ini berlaku saat menggunakan set pernyataan, dan/atau saat menentukan bendera di properti permintaan klien.

  • Jika notruncation diatur, dan salah satu dari truncationmaxsize, truncationmaxrecords, atau query_take_max_records juga diatur - notruncation diabaikan.
  • Jika truncationmaxsize, truncationmaxrecords dan/atau query_take_max_records ditetapkan beberapa kali - nilai yang lebih rendah untuk setiap properti diterapkan.

Batas memori yang digunakan oleh operator kueri (E_RUNAWAY_QUERY)

Kusto membatasi memori yang dapat dikonsumsi setiap operator kueri untuk melindungi dari kueri "runaway". Batas ini mungkin dicapai oleh beberapa operator kueri, seperti join dan summarize, yang beroperasi dengan menyimpan data yang signifikan dalam memori. Secara default, batasnya adalah 5GB (per node kluster), dan dapat ditingkatkan dengan mengatur opsi maxmemoryconsumptionperiteratorpermintaan :

set maxmemoryconsumptionperiterator=68719476736;
MyTable | summarize count() by Use

Ketika batas ini tercapai, kegagalan kueri parsial dipancarkan dengan pesan yang menyertakan teks E_RUNAWAY_QUERY.

The ClusterBy operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete E_RUNAWAY_QUERY.

The DemultiplexedResultSetCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The ExecuteAndCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Summarize operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNestedAggregator operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNested operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

Jika maxmemoryconsumptionperiterator ditetapkan beberapa kali, misalnya di properti permintaan klien dan menggunakan pernyataan set, nilai yang lebih rendah diterapkan.

Batas tambahan yang mungkin memicu E_RUNAWAY_QUERY kegagalan kueri parsial adalah batas ukuran akumulasi maksimum string yang dipegang oleh satu operator. Batas ini tidak dapat ditimpa oleh opsi permintaan di atas:

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Ketika batas ini terlampaui, kemungkinan besar operator kueri yang relevan adalah join, , summarizeatau make-series. Untuk mengatasi batas, seseorang harus memodifikasi kueri untuk menggunakan strategi kueri acak . (Ini juga kemungkinan akan meningkatkan performa kueri.)

Dalam semua kasus E_RUNAWAY_QUERY, opsi tambahan (di luar peningkatan batas dengan mengatur opsi permintaan dan mengubah kueri untuk menggunakan strategi pengacakan) adalah beralih ke pengambilan sampel. Dua kueri di bawah ini menunjukkan cara melakukan pengambilan sampel. Kueri pertama adalah pengambilan sampel statistik, menggunakan generator angka acak. Kueri kedua adalah pengambilan sampel deterministik, yang dilakukan dengan hashing beberapa kolom dari himpunan data, biasanya beberapa ID.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

Membatasi memori per node

Memori maks per kueri per node adalah batas lain yang digunakan untuk melindungi terhadap kueri "runaway". Batas ini, direpresentasikan oleh opsi permintaan max_memory_consumption_per_query_per_node, menetapkan batas atas pada jumlah memori yang dapat digunakan pada satu node untuk kueri tertentu.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Jika max_memory_consumption_per_query_per_node ditetapkan beberapa kali, misalnya di properti permintaan klien dan menggunakan pernyataan set, nilai yang lebih rendah diterapkan.

Jika kueri menggunakan operator summarize, join, atau make-series, Anda dapat menggunakan strategi kueri shuffle untuk mengurangi tekanan memori pada satu mesin.

Membatasi batas waktu eksekusi

Batas waktu server adalah batas waktu sisi layanan yang diterapkan ke semua permintaan. Batas waktu untuk menjalankan permintaan (kueri dan perintah manajemen) diberlakukan di beberapa titik di Kusto:

  • pustaka klien (jika digunakan)
  • titik akhir layanan yang menerima permintaan
  • mesin layanan yang memproses permintaan

Secara default, batas waktu diatur ke empat menit untuk kueri, dan 10 menit untuk perintah manajemen. Nilai ini dapat ditingkatkan jika diperlukan (dibatasi pada satu jam).

  • Berbagai alat klien mendukung perubahan batas waktu sebagai bagian dari pengaturan global atau per koneksi mereka. Misalnya, di Kusto.Explorer, gunakan Tools>Options* >Connections>Query Server Timeout.
  • Secara terprogram, SDK mendukung pengaturan batas waktu di seluruh properti servertimeout. Misalnya, di .NET SDK ini dilakukan melalui properti permintaan klien, dengan menetapkan nilai jenis System.TimeSpan.

Catatan tentang batas waktu

  • Di sisi klien, batas waktu diterapkan dari permintaan yang dibuat sampai saat respons mulai tiba ke klien. Waktu yang dibutuhkan untuk membaca payload kembali pada klien tidak diperlakukan sebagai bagian dari batas waktu. Itu tergantung pada seberapa cepat pemanggil menarik data dari aliran.
  • Juga di sisi klien, nilai batas waktu aktual yang digunakan sedikit lebih tinggi dari nilai batas waktu server yang diminta oleh pengguna. Perbedaan ini, adalah untuk memungkinkan latensi jaringan.
  • Untuk secara otomatis menggunakan batas waktu permintaan maksimum yang diizinkan, atur properti permintaan klien norequesttimeout ke true.

Catatan

Lihat mengatur batas waktu habis untuk panduan langkah demi langkah tentang cara mengatur batas waktu di UI web Azure Data Explorer, Kusto.Explorer, Kusto.Cli, Power BI, dan saat menggunakan SDK.

Membatasi penggunaan sumber daya CPU kueri

Kusto memungkinkan Anda menjalankan kueri dan menggunakan sumber daya CPU sebanyak yang dimiliki kluster. Ini mencoba untuk melakukan round-robin yang adil antara kueri jika lebih dari satu berjalan. Metode ini menghasilkan performa terbaik untuk fungsi yang ditentukan kueri. Di lain waktu, Anda mungkin ingin membatasi sumber daya CPU yang digunakan untuk kueri tertentu. Jika Anda menjalankan "pekerjaan latar belakang", misalnya, sistem mungkin mentolerir latensi yang lebih tinggi untuk memberikan kueri sebaris bersamaan dengan prioritas tinggi.

Kusto mendukung penentuan dua properti permintaan saat menjalankan kueri. Propertinya adalah query_fanout_threads_percent dan query_fanout_nodes_percent. Kedua properti adalah bilangan bulat yang diatur secara default ke nilai maksimum (100), tetapi dapat dikurangi untuk kueri tertentu ke beberapa nilai lainnya.

Yang pertama, query_fanout_threads_percent, mengontrol faktor fanout untuk penggunaan utas. Ketika properti ini diatur 100%, kluster akan menetapkan semua CPU pada setiap node. Misalnya, 16 CPU pada kluster yang disebarkan pada node Azure D14. Ketika properti ini diatur ke 50%, maka setengah dari CPU akan digunakan, dan seterusnya. Angka-angka dibulatkan ke seluruh CPU, jadi aman untuk mengatur nilai properti menjadi 0.

Yang kedua, query_fanout_nodes_percent, mengontrol berapa banyak node kueri dalam kluster yang akan digunakan per operasi distribusi subkueri. Ini berfungsi dengan cara yang sama.

Jika query_fanout_nodes_percent atau query_fanout_threads_percent ditetapkan beberapa kali, misalnya di properti permintaan klien dan menggunakan pernyataan set, nilai yang lebih rendah untuk setiap properti diterapkan.

Membatasi kompleksitas kueri

Selama eksekusi kueri, teks kueri diubah menjadi pohon operator relasi yang mewakili kueri. Jika kedalaman pohon melebihi ambang internal, kueri dianggap terlalu rumit untuk diproses, dan akan gagal dengan kode galat. Kegagalan menunjukkan bahwa pohon operator relasi melebihi batasnya.

Contoh berikut menunjukkan pola kueri umum yang dapat menyebabkan kueri melebihi batas ini dan gagal:

  • daftar panjang operator biner yang dirangkai bersama- sama. Contohnya:
T 
| where Column == "value1" or 
        Column == "value2" or 
        .... or
        Column == "valueN"

Untuk kasus khusus ini, tulis ulang kueri menggunakan operator in().

T 
| where Column in ("value1", "value2".... "valueN")
  • kueri yang memiliki operator union yang menjalankan analisis skema yang terlalu luas terutama bahwa versi default union adalah mengembalikan skema union "luar" (artinya – output itu akan mencakup semua kolom tabel yang mendasarinya).

Saran dalam kasus ini adalah meninjau kueri dan mengurangi kolom yang digunakan oleh kueri.

Konten terkait