PolarDB：Query paralel elastis

Pengenalan

Fitur ePQ mendukung dua mesin paralel: query paralel elastis satu node dan query paralel elastis multi-node. Query paralel elastis satu node setara dengan fitur query paralel asli. Query paralel elastis multi-node mendukung penjadwalan adaptif lintas node dalam kluster.

PolarDB for MySQL 8.0.1 hanya mendukung query paralel elastis satu node. Data kueri dibagi ke berbagai thread di lapisan penyimpanan. Thread-thread tersebut berjalan secara paralel dan mengembalikan hasilnya ke thread pemimpin. Kemudian, thread pemimpin menggabungkan hasil dan mengembalikan hasil akhir kepada pengguna. Ini meningkatkan efisiensi kueri.

PolarDB for MySQL 8.0.2 mendukung query paralel elastis satu node dan query paralel elastis multi-node. Query paralel elastis multi-node secara signifikan meningkatkan kemampuan akselerasi linier dan menerapkan komputasi paralel terdistribusi multi-node. Optimasi berbasis biaya memungkinkan rencana eksekusi menjadi fleksibel dan berjalan secara paralel. Ini menangani potensi hambatan pemimpin dan ketidakseimbangan beban pekerja yang terjadi dalam query paralel elastis satu node. Ini juga mengatasi hambatan CPU, memori, dan I/O dari satu node. Tampilan sumber daya multi-node dan penjadwalan adaptif tugas komputasi paralel sangat meningkatkan kemampuan komputasi paralel, mengurangi latensi kueri, menyeimbangkan beban sumber daya node, dan meningkatkan penggunaan sumber daya keseluruhan kluster.

Fitur ePQ dapat mengatasi masalah pemanfaatan sumber daya CPU yang rendah dan tidak merata di instance pengguna berbasis cloud dengan sepenuhnya memanfaatkan kemampuan pemrosesan paralel CPU multi-core dalam kluster. Gambar berikut menunjukkan proses dalam kluster PolarDB for MySQL 8-core, 32 GB (spesifikasi khusus).

Prasyarat

Untuk informasi tentang cara melihat versi kluster, lihat Kueri versi mesin.

Skenario

Fitur ePQ berlaku untuk sebagian besar pernyataan SELECT, seperti kueri pada tabel besar, kueri multi-tabel yang menggunakan pernyataan JOIN, dan kueri pada sejumlah besar data. Fitur ini tidak memberikan manfaat signifikan untuk kueri pendek. Metode paralel yang beragam membuat fitur ini cocok untuk skenario berikut:

• Kueri analitik pada sejumlah besar data

  Jika melibatkan data dalam jumlah sedang atau besar, pernyataan SQL untuk kueri analitik sering kali kompleks dan memakan waktu. Anda dapat mengaktifkan fitur ePQ untuk mengurangi waktu respons secara linier.

• Beban sumber daya tidak seimbang

  Kemampuan penyeimbangan beban PolarProxy dapat membantu memastikan bahwa jumlah koneksi serupa dibuat untuk node dalam kluster. Namun, karena kompleksitas komputasi dalam kueri dan perbedaan dalam penggunaan sumber daya, penyeimbangan beban berdasarkan koneksi tidak dapat sepenuhnya mencegah ketidakseimbangan beban antar node. Mirip dengan database terdistribusi lainnya, node hotspot memiliki dampak negatif pada PolarDB:

  1. Jika node baca-saja hotspot menyebabkan kueri lambat, node utama mungkin tidak dapat melakukan purge undo log, yang mengakibatkan pembengkakan disk.

  2. Jika node baca-saja hotspot menyebabkan operasi redo apply lambat, node utama mungkin tidak dapat flush data, yang mengakibatkan penurunan performa throughput tulis.

  Fitur ePQ memperkenalkan tampilan sumber daya global dan penjadwalan tugas adaptif berdasarkan tampilan. Berdasarkan nilai resource usage dan data affinity dari setiap node, beberapa atau semua tugas kueri dijadwalkan ke node yang memiliki sumber daya idle untuk memastikan derajat paralelisme (DOP) yang diinginkan dan penggunaan sumber daya yang seimbang dalam kluster.

  

• Komputasi elastis

  Elastisitas adalah salah satu kemampuan inti PolarDB. Penskalaan otomatis memberikan elastisitas yang cocok untuk kueri pendek. Namun, ini tidak cocok untuk kueri analitik kompleks karena satu kueri tidak dapat dipercepat dengan menambahkan node dalam skenario kueri berskala besar. Ketika fitur ePQ diaktifkan untuk kluster, node yang baru ditambahkan secara otomatis ditambahkan ke kluster untuk berbagi sumber daya komputasi dan meningkatkan elastisitas.

  

• Kombinasi layanan online dan offline

  Metode isolasi yang paling efektif adalah merutekan layanan transaksi online dan layanan analitik offline ke set node yang berbeda. Namun, metode ini meningkatkan biaya. Dalam banyak kasus, layanan transaksi online dan layanan analitik offline memiliki jam puncak yang berbeda. Metode yang hemat biaya adalah berbagi sumber daya kluster antara layanan transaksi online dan layanan analitik offline dan merutekan layanan ke titik akhir kluster yang berbeda. Setelah fitur ePQ diaktifkan, sumber daya idle didistribusikan ke layanan analitik offline selama jam non-puncak layanan transaksi online untuk mengurangi biaya dan meningkatkan efisiensi.

  

Catatan Penggunaan

Untuk informasi tentang cara menggunakan fitur ePQ, lihat Penggunaan.

Metrik Performa

Tes berikut menggunakan 100 GB data yang dihasilkan berdasarkan TPC Benchmark H (TPC-H) untuk memeriksa performa kluster PolarDB for MySQL 8.0. Dalam tes ini, kluster PolarDB memiliki empat node yang menggunakan 32 core CPU dan 256 GB memori (Dedicated). Untuk query paralel elastis satu node, parameter max_parallel_degree diatur ke 32 dan 0. Bandingkan data performa untuk kueri sekuensial, query paralel elastis satu node dengan DOP 32, dan query paralel elastis empat node dengan DOP 128. Untuk informasi lebih lanjut, lihat Hasil tes performa dalam skenario kueri paralel.

Hasil tes di atas menunjukkan bahwa 100% kueri SQL dalam TPC-H dipercepat. Kecepatan kueri rata-rata 17 kali lebih cepat dan maksimum 56 kali lebih cepat.

When multi-node elastic parallel query is enabled, the query speed is 59 times faster on average and 159 times faster at maximum.

Lihat rencana eksekusi query paralel elastis

Untuk informasi tentang cara menjalankan pernyataan EXPLAIN untuk melihat informasi query paralel elastis dalam rencana eksekusi, lihat Jalankan pernyataan EXPLAIN untuk melihat rencana eksekusi query paralel elastis.

Istilah

• Pemindaian paralel

  Dalam pemindaian paralel, worker memindai data tabel secara paralel. Setiap worker menghasilkan hasil parsial dan mengembalikan hasil parsial ke thread pemimpin. Thread pemimpin mengumpulkan hasil menggunakan node gather dan mengembalikan hasil akhir ke sisi klien.

• Gabungan paralel pada beberapa tabel

  Jika fitur ePQ diaktifkan, operasi gabungan multi-tabel didorong ke worker untuk pemrosesan paralel. Optimizer PolarDB memilih tabel optimal untuk pemindaian paralel, tetapi tidak melakukan pemindaian paralel untuk tabel lainnya. Setiap worker menghasilkan hasil parsial dan mengembalikan hasil parsial ke thread pemimpin. Thread pemimpin mengumpulkan hasil menggunakan node gather dan mengembalikan hasil akhir ke klien.

• Pengurutan paralel

  Optimizer PolarDB mendorong operasi ORDER BY ke semua worker untuk pengurutan paralel. Setiap worker menghasilkan hasil parsial dan mengembalikan hasil parsial ke thread pemimpin. Thread pemimpin mengumpulkan, menggabungkan, dan mengurutkan semua hasil parsial menggunakan node gather merge, dan mengembalikan hasil pengurutan akhir ke sisi klien.

• Pengelompokan paralel

  Optimizer PolarDB mendorong operasi GROUP BY ke worker untuk pemrosesan paralel. Setiap worker melakukan operasi GROUP BY pada sebagian data. Setiap worker menghasilkan hasil parsial GROUP BY dan mengembalikan hasil parsial ke thread pemimpin. Thread pemimpin mengumpulkan hasil dari semua worker menggunakan node gather. Optimizer PolarDB menentukan apakah akan melakukan operasi GROUP BY lagi di thread pemimpin berdasarkan rencana kueri. Misalnya, jika loose index scan digunakan untuk mengeksekusi pernyataan GROUP BY, thread pemimpin tidak melakukan operasi GROUP BY. Jika loose index scan tidak digunakan, thread pemimpin melakukan operasi GROUP BY dan mengembalikan hasil akhir ke sisi klien.

• Agregasi paralel

  Jika fitur ePQ diaktifkan, fungsi agregat dikirim ke semua worker untuk agregasi paralel. Optimizer menentukan apakah akan melakukan eksekusi serial, agregasi satu fase, atau agregasi dua fase berdasarkan biaya.

  • Agregasi satu fase: Optimizer mendistribusikan operasi agregasi ke worker. Setiap worker berisi semua data dalam grup. Oleh karena itu, komputasi agregasi fase kedua tidak diperlukan. Setiap worker langsung menghitung hasil agregasi akhir grup untuk mencegah thread pemimpin melakukan agregasi kedua.

  • Agregasi dua fase: Pada fase pertama, setiap worker yang terlibat dalam query paralel elastis melakukan agregasi. Pada fase kedua, node gather atau node gather merge mengembalikan hasil yang dihasilkan oleh setiap worker ke thread pemimpin. Kemudian, thread pemimpin menggabungkan hasil dari semua worker untuk menghasilkan hasil akhir.

  • Agregasi dua fase shuffle: Pada fase pertama, setiap worker dalam query paralel elastis melakukan agregasi. Pada fase kedua, node repartition mendistribusikan hasil yang dihasilkan oleh setiap worker ke beberapa worker berdasarkan kolom pengelompokan. Worker menyelesaikan komputasi agregasi akhir secara paralel. Akhirnya, hasil agregasi dirangkum di thread pemimpin.

  Optimizer PolarDB menentukan metode agregasi spesifik berdasarkan biaya.

• Fungsi jendela paralel

  Optimizer PolarDB melakukan komputasi dan mendistribusikan fungsi jendela ke worker untuk eksekusi paralel berdasarkan biaya. Setiap worker menghitung sebagian data. Metode distribusi ditentukan oleh kunci klausa PARTITION BY dalam fungsi jendela. Jika fungsi jendela tidak mengandung klausa PARTITION BY, komputasi serial dilakukan. Jika komputasi paralel dapat dilakukan pada titik waktu berikutnya, tugas komputasi berikutnya didistribusikan ke beberapa worker untuk eksekusi berdasarkan biaya untuk memastikan paralelisasi maksimum.

• Dukungan untuk subkueri

  Dalam query paralel elastis, Anda dapat menggunakan salah satu kebijakan berikut untuk menjalankan subkueri:

  • Eksekusi sekuensial di thread pemimpin

    Jika subkueri tidak mendukung pemrosesan paralel, subkueri di thread pemimpin dilakukan secara berurutan. Sebagai contoh, jika dua tabel digabungkan menggunakan klausa JOIN yang merujuk ke fungsi yang ditentukan pengguna (UDF), subkueri dilakukan secara berurutan.

  • Eksekusi paralel di thread pemimpin (kelompok worker lain digunakan)

    Setelah rencana query paralel elastis dihasilkan, jika rencana eksekusi thread pemimpin mencakup subkueri yang mendukung pemrosesan paralel, subkueri paralel ini tidak dapat dijalankan terlebih dahulu atau dijalankan secara paralel berdasarkan kebijakan akses bersama. Sebagai contoh, jika subkueri mencakup fungsi jendela, subkueri tidak dapat dijalankan secara paralel berdasarkan kebijakan akses bersama.

  • Akses bersama

    Setelah rencana query paralel elastis dihasilkan, jika rencana eksekusi worker merujuk pada subkueri yang mendukung pemrosesan paralel, optimizer PolarDB menjalankan subkueri paralel terlebih dahulu. Dengan cara ini, worker dapat langsung mengakses hasil subkueri.

  • Didorong ke bawah

    Setelah rencana query paralel elastis dihasilkan, jika rencana eksekusi worker merujuk pada subkueri terkait, worker menjalankan subkueri terkait.