Optimalkan kueri di ApsaraDB for SelectDB - ApsaraDB for SelectDB

ApsaraDB for SelectDB menggunakan pengoptimal Nereids dan mesin eksekusi Pipeline untuk mengoptimalkan kueri secara otomatis. Untuk memenuhi kebutuhan kueri berkinerja tinggi, Anda juga dapat melakukan optimasi kueri secara manual, misalnya dengan menggunakan akselerasi berbasis indeks, kueri titik berkonkurensi tinggi, tampilan yang di-materialisasi, serta optimasi penggabungan tabel.

Perencanaan optimasi kueri otomatis

Di SelectDB, pengoptimal Nereids dan mesin eksekusi Pipeline merupakan teknologi inti dalam pemrosesan kueri yang mampu melakukan optimasi mendalam pada tahap perencanaan dan eksekusi kueri. Teknologi ini secara signifikan meningkatkan kinerja kueri kompleks dan efisiensi penggunaan sumber daya. Gambar berikut menunjukkan cara teknologi tersebut mengoptimalkan pernyataan SQL di SelectDB.

Tabel berikut menjelaskan fitur utama masing-masing teknologi. Untuk informasi lebih lanjut, lihat dokumentasi terkait.

Technology	Feature description
Nereids	Mendukung kueri kompleks seperti subkueri bersarang multi-level dan kueri penggabungan multi-tabel. Mengurangi kemungkinan terjadinya kesalahan logika dalam aturan optimasi.
Pipeline execution engine	Meningkatkan pemanfaatan CPU. Meredakan konflik sumber daya antara kueri besar dan kecil.

Optimasi kueri manual

Jika pengoptimal Nereids dan mesin eksekusi Pipeline di SelectDB tidak memenuhi kebutuhan kueri Anda, Anda dapat menggunakan statistik untuk menganalisis data kueri dan memilih kebijakan yang sesuai guna mengoptimalkan kueri.

Optimization policy	Scenario	Limit
High-concurrency point queries	Anda ingin mengoptimalkan kueri titik berkonkurensi tinggi. Catatan Point query adalah mengambil sejumlah kecil data dari database yang memenuhi kondisi tertentu. Dalam kebanyakan kasus, primary key atau kolom dengan kardinalitas tinggi digunakan untuk melakukan pengambilan tersebut.	Mengaktifkan mode penyimpanan baris (row storage) akan mengonsumsi ruang penyimpanan tambahan. PreparedStatement hanya mendukung kueri titik berbasis primary key.
Synchronous materialized view	Anda ingin mengoptimalkan kueri kompleks yang bersifat repetitif dan memakan waktu lama.	Pada tabel yang menggunakan model Unique Key, Anda dapat menggunakan tampilan yang di-materialisasi untuk mengubah urutan kolom tetapi tidak dapat menggunakannya sebagai fungsi agregat. Oleh karena itu, Anda tidak dapat membuat tampilan yang di-materialisasi untuk tabel yang menggunakan model Unique Key guna melakukan operasi agregat kasar (coarse-grained). Jika jumlah tampilan yang di-materialisasi yang dibuat pada suatu tabel terlalu banyak, efisiensi impor data akan terpengaruh. Untuk informasi lebih lanjut, lihat Synchronous materialized view.
Index-based acceleration	Anda ingin melakukan kueri atau menemukan data dengan cepat dalam skenario apa pun.	Batasan bervariasi tergantung pada jenis indeks. Untuk informasi lebih lanjut, lihat Index-based acceleration.
Bucket Shuffle Join	Anda ingin mengoptimalkan kueri penggabungan tabel (join queries).	Kondisi join harus mencakup kolom terdistribusi dari tabel kiri, dan tabel kiri hanya menggunakan data dari satu partisi selama eksekusi.
Colocation Join	Anda ingin mengoptimalkan kueri penggabungan tabel (join queries).	Kondisi join harus mencakup kolom terdistribusi dari tabel kiri, dan tabel kiri serta kanan termasuk dalam Colocate Group yang sama.
Runtime filter	Skema di mana proses penggabungan tabel besar dengan tabel kecil perlu dioptimalkan.	Saat menggunakan Runtime filter, pernyataan JOIN harus memenuhi persyaratan berikut: Tabel kiri berukuran besar, dan tabel kanan berukuran kecil. Saat membangun Runtime filter, Anda harus mempertimbangkan biaya komputasi, termasuk overhead memori. Ukuran set hasil join kecil. Ukuran set hasil yang kecil menunjukkan bahwa pernyataan JOIN menyaring sebagian besar data dari tabel kiri.
Precise deduplication with BITMAP	Skema di mana hasil deduplikasi harus akurat dan melibatkan jutaan catatan data. Skema di mana sumber daya penyimpanan mencukupi.	Batasan tipe data: Bilangan bulat bertipe TINYINT, SMALLINT, INT, dan BIGINT dapat langsung digunakan. Data non- bilangan bulat, seperti string, dapat digunakan setelah dipetakan ke bilangan bulat menggunakan kamus global. Hal ini meningkatkan biaya maintenance. Batasan memori: Jika kardinalitas data tinggi, misalnya miliaran catatan data, Bitmap perlu menyimpan larik bit berukuran besar. Hal ini secara signifikan meningkatkan penggunaan memori dan dapat menyebabkan kekurangan sumber daya memori.
Approximate deduplication by using the HLL feature	Skema di mana sejumlah besar data, seperti miliaran catatan data, perlu diproses dan margin kesalahan tertentu—misalnya nilai metrik analitis yang tidak akurat—diperbolehkan dalam hasil. Skema di mana penggabungan hasil secara efisien diperlukan dalam sistem terdistribusi.	Loss akurasi: Anda tidak dapat memperoleh hasil yang akurat. Laju error menurun seiring peningkatan kardinalitas data. Misalnya, semakin tinggi kardinalitas data, semakin rendah laju error relatifnya. Konfigurasi parameter yang tepat: Akurasi HyperLogLog (HLL) ditentukan oleh parameter, seperti parameter yang menentukan jumlah register dan bit hash. Pengaturan parameter yang tidak tepat dapat memengaruhi akurasi hasil.