Lindorm:FAQ Lindorm SQL

• Bagaimana cara mengatasi atau menghindari kueri yang tidak efisien?

• Mengapa kueri GROUP BY gagal dengan error The diff group keys of subPlan is over lindorm.aggregate.subplan.groupby.keys.limit=..., it may cost a lot memory so we shutdown this SubPlan?

• Mengapa kueri SELECT * pada tabel yang memiliki dynamic columns aktif gagal dengan error Limit of this select statement is not set or exceeds config when select all columns from table with property DYNAMIC_COLUMNS=true?

• Mengapa pembuatan secondary index gagal dengan error Executing job number exceed, max job number = 8?

• Setelah menghapus kolom di LindormTable, mengapa menambahkan kembali kolom dengan nama yang sama gagal dengan error column is under deleting?

• Setelah membuat secondary index, mengapa penulisan data gagal dengan error Performing put operations with User-Defined-Timestamp in indexed column on MULTABLE_LATEST table is unsupported?

• Mengapa kueri SQL gagal dengan error Code grows beyond 64 KB?

• Mengapa kueri SQL gagal dengan error The estimated memory used by the query exceeds the maximum limit?

• Mengapa pembaruan batch tidak didukung, atau mengapa muncul error "Update's WHERE clause can only contain PK columns"?

• Bagaimana cara mengaktifkan penghapusan batch?

Bagaimana cara mengatasi atau menghindari kueri yang tidak efisien?

Mengapa kueri GROUP BY gagal dengan error The diff group keys of subPlan is over lindorm.aggregate.subplan.groupby.keys.limit=..., it may cost a lot memory so we shutdown this SubPlan?

Penyebab:

Jumlah kelompok yang dibuat oleh operasi GROUP BY terlalu besar. Operasi ini dapat mengonsumsi sumber daya memori secara berlebihan dan meningkatkan beban instans. Oleh karena itu, LindormTable membatasi kueri yang menghasilkan banyak kelompok dalam set hasil.

Solusi:

• Tambahkan kondisi filter ke pernyataan kueri untuk mengurangi jumlah akhir kelompok.

• Hubungi dukungan teknis Lindorm (ID DingTalk: s0s3eg3) untuk menaikkan ambang batas jumlah kelompok.

  Penting

  Menambah ambang batas jumlah kelompok dapat memengaruhi stabilitas instans.

• Untuk skenario kueri multidimensi, kami merekomendasikan penggunaan indeks pencarian. Untuk informasi lebih lanjut, lihat Pengantar indeks pencarian.

Mengapa kueri SELECT * pada tabel yang memiliki dynamic columns aktif gagal dengan error Limit of this select statement is not set or exceeds config when select all columns from table with property DYNAMIC_COLUMNS=true?

Penyebab:

Tabel dengan kolom dinamis yang diaktifkan mungkin berisi banyak kolom dinamis, dan skemanya tidak tetap. Jika Anda melakukan pemindaian tabel penuh pada tabel semacam itu, hal ini dapat menyebabkan konsumsi I/O yang tinggi dan meningkatkan beban instans. Untuk mencegah situasi beban tinggi, LindormTable memberlakukan pembatasan pada pernyataan kueri untuk tabel dengan kolom dinamis.

Solusi:

Tambahkan klausa LIMIT ke pernyataan SELECT untuk membatasi jumlah hasil yang dikembalikan. Contohnya: SELECT * FROM test LIMIT 10;.

Mengapa pembuatan secondary index gagal dengan error Executing job number exceed, max job number = 8?

Penyebab:

Sebuah instans mengizinkan maksimal delapan tugas pembuatan indeks sekunder berjalan secara bersamaan. Jika delapan tugas pembuatan sudah berjalan, upaya baru untuk membuat indeks sekunder akan gagal dengan kesalahan ini.

Solusi:

Hindari membuat banyak indeks sekunder secara bersamaan. Untuk membuat banyak indeks, hubungi dukungan teknis Lindorm (ID DingTalk: s0s3eg3).

Setelah menghapus kolom di LindormTable, mengapa menambahkan kembali kolom dengan nama yang sama gagal dengan error column is under deleting?

Penyebab:

Untuk mencegah masalah data kotor yang disebabkan oleh faktor-faktor seperti tipe data, LindormTable membersihkan data kolom tersebut secara asinkron dari memori, penyimpanan panas, dan penyimpanan dingin setelah Anda menghapus kolom tersebut. Sistem tidak mengizinkan Anda menambahkan kolom baru dengan nama yang sama hingga proses pembersihan selesai.

Solusi:

Pembersihan data dilakukan oleh sistem dan dapat memakan waktu lama. Anda dapat menggunakan metode berikut untuk mempercepat proses pembersihan. Setelah pembersihan selesai, Anda dapat menambahkan kembali kolom dengan nama yang sama.

Asumsikan bahwa tabel tempat kolom dihapus bernama dt:

-- Jalankan operasi FLUSH untuk memaksa data sisa di memori dituliskan ke media penyimpanan.
ALTER TABLE dt FLUSH;

-- Jalankan operasi COMPACTION untuk menggabungkan dan menghapus data.
ALTER TABLE dt COMPACT;

Setelah membuat secondary index, mengapa penulisan data gagal dengan error Performing put operations with User-Defined-Timestamp in indexed column on MULTABLE_LATEST table is unsupported?

Penyebab:

Jika Anda secara eksplisit menentukan timestamp kustom saat menulis data (misalnya, menggunakan HINT /*+ _l_ts */ dalam pernyataan UPSERT), kemutabelan baik tabel utama maupun tabel indeks sekunder harus diatur sebagai MULTABLE_ALL. Namun, demi alasan kinerja, Lindorm secara default mengatur kemutabelan tabel utama dan tabel indeks menjadi MULTABLE_LATEST. Membuat dan mengaktifkan indeks sekunder dengan konfigurasi ini memicu pelanggaran batasan kemutabelan, yang menyebabkan kesalahan tersebut.

Solusi:

Nilai parameter MUTABILITY tidak dapat diubah setelah tabel indeks dibuat. Anda harus terlebih dahulu menghapus indeks sekunder asli.

1. Hapus indeks sekunder asli dari tabel utama.

   -- Nonaktifkan indeks sekunder asli.
   ALTER INDEX IF EXISTS <original_secondary_index_name> ON <primary_table_name> DISABLED;
   
   -- Hapus indeks sekunder asli.
   DROP INDEX IF EXISTS <original_secondary_index_name> ON <primary_table_name>;

   Untuk informasi lebih lanjut tentang sintaks DROP INDEX, lihat Menghapus indeks sekunder.

2. Ubah nilai properti MUTABILITY tabel utama menjadi MUTABLE_ALL.

   ALTER TABLE IF EXISTS <primary_table_name> SET MUTABILITY='MUTABLE_ALL';

3. Buat indeks sekunder baru dan tulis data. Untuk informasi lebih lanjut tentang sintaks pembuatan indeks sekunder, lihat CREATE INDEX.

   Catatan

   • Untuk informasi lebih lanjut tentang cara menulis data dengan timestamp kustom, lihat Gunakan HINT untuk mengatur timestamp dalam manajemen data multi-versi.

   • Untuk informasi lebih lanjut tentang hubungan antara batasan kemutabelan indeks sekunder dan timestamp kustom, lihat Perbarui indeks dengan timestamp kustom.

Mengapa kueri SQL gagal dengan error Code grows beyond 64 KB?

Penyebab:

Mesin SQL Lindorm menggunakan kompilasi Just-In-Time (JIT) untuk mengeksekusi kueri. Mesin ini secara dinamis menghasilkan bytecode dari rencana fisik kueri, lalu mengompilasi dan mengeksekusinya. Kesalahan Code grows beyond 64KB menunjukkan bahwa ukuran bytecode untuk metode yang dihasilkan melebihi batas yang diizinkan oleh Java Virtual Machine (JVM). Hal ini dapat terjadi jika predikat dalam pernyataan kueri SQL terlalu panjang atau kompleks, sehingga menghasilkan bytecode yang terlalu besar untuk dieksekusi.

Solusi:

Ubah pernyataan SQL untuk menyederhanakan ekspresi predikat yang relevan.

Mengapa kueri SQL gagal dengan error The estimated memory used by the query exceeds the maximum limit?

Penyebab:

Mesin SQL sering mengonsumsi sumber daya memori dalam jumlah besar saat memproses set hasil yang dikembalikan dari mesin penyimpanan, misalnya selama agregasi, pengurutan, atau deduplikasi. Lindorm SQL dirancang untuk skenario bisnis online di mana banyak kueri dapat berjalan secara bersamaan. Untuk memastikan efisiensi kueri dalam skenario konkurensi tinggi, sistem membatasi penggunaan memori untuk satu kueri. Batas default saat ini adalah 8 MB. Jika batas ini dilampaui, pengecualian overflow memori akan dipicu.

Solusi:

• Optimalkan pernyataan kueri. Anda dapat mendorong operator seperti agregasi dan pengurutan ke mesin penyimpanan menggunakan indeks. Anda juga dapat mengoptimalkan kondisi filter untuk mengurangi jumlah data yang perlu diproses oleh mesin SQL.

  Catatan

  Anda dapat memeriksa rencana eksekusi untuk melihat apakah operator seperti agregasi dan pengurutan didorong ke mesin penyimpanan atau dieksekusi oleh mesin SQL. Untuk informasi lebih lanjut, lihat Menafsirkan rencana eksekusi.

• Sesuaikan ambang batas memori `QUERY_MAX_MEM`. Setelah Anda mengevaluasi sepenuhnya throughput kueri, Anda dapat menyesuaikan item konfigurasi `QUERY_MAX_MEM` menggunakan pernyataan ALTER SYSTEM. Contohnya: ALTER SYSTEM SET QUERY_MAX_MEM = 8388608;. Jika versi mesin SQL Anda lebih awal dari 2.9.6.0, hubungi dukungan teknis Lindorm (ID DingTalk: s0s3eg3) untuk menaikkan ambang batas memori.

  Penting

  Jika aplikasi online memiliki konkurensi kueri yang tinggi, menaikkan ambang batas memori ini dapat meningkatkan beban memori pada Lindorm. Hal ini, pada gilirannya, dapat memicu perilaku seperti Full GC paksa dan mengurangi responsivitas seluruh kluster. Oleh karena itu, lakukan evaluasi menyeluruh sebelum menaikkan batas memori ini. Anda dapat mengambil nilai saat ini dari QUERY_MAX_MEM menggunakan pernyataan SHOW VARIABLES.

Mengapa pembaruan batch tidak didukung, atau mengapa muncul error Update's WHERE clause can only contain PK columns?

Secara default, hanya pembaruan satu baris yang didukung. Untuk informasi lebih lanjut tentang cara mengaktifkan fitur ini, lihat FAQ operasi batch.

Bagaimana cara mengaktifkan penghapusan batch?

Untuk informasi lebih lanjut tentang cara mengaktifkan dan memeriksa pengaturan penghapusan batch, lihat FAQ operasi batch.