PolarDB:Apa Itu Elastic Parallel Query

Pendahuluan

Fitur ePQ mendukung dua mesin paralel: elastic parallel query node tunggal dan elastic parallel query multi-node. Elastic parallel query node tunggal setara dengan fitur parallel query asli, sedangkan elastic parallel query multi-node mendukung penjadwalan adaptif lintas node dalam sebuah kluster.

PolarDB for MySQL 8.0.1 hanya mendukung elastic parallel query node tunggal. Data kueri dipartisi ke dalam thread yang berbeda pada lapisan penyimpanan. Thread-thread tersebut berjalan secara paralel dan mengembalikan hasilnya ke thread leader, yang kemudian menggabungkan hasil tersebut dan mengembalikan hasil akhir kepada pengguna, sehingga meningkatkan efisiensi kueri.

PolarDB for MySQL 8.0.2 mendukung elastic parallel query node tunggal dan multi-node. Elastic parallel query multi-node secara signifikan meningkatkan kemampuan akselerasi linear dan menerapkan komputasi paralel terdistribusi multi-node. Optimisasi berbasis biaya memungkinkan rencana eksekusi menjadi fleksibel dan berjalan secara paralel, mengatasi potensi bottleneck pada leader dan ketidakseimbangan beban worker yang terjadi pada elastic parallel query node tunggal. Fitur ini juga mengatasi bottleneck CPU, memori, dan I/O pada node tunggal. Tampilan resource multi-node dan penjadwalan adaptif tugas komputasi paralel sangat meningkatkan kemampuan komputasi paralel, mengurangi latensi kueri, menyeimbangkan beban resource antar node, serta meningkatkan penggunaan resource keseluruhan kluster.

Fitur ePQ dapat mengatasi masalah pemanfaatan resource CPU yang rendah dan tidak merata pada instans pengguna berbasis cloud dengan memanfaatkan sepenuhnya kemampuan pemrosesan paralel CPU multi-core dalam kluster. Gambar berikut menunjukkan proses dalam kluster PolarDB for MySQL berukuran 8-core dan 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 volume data besar. Fitur ini tidak memberikan manfaat signifikan untuk kueri pendek. Berbagai metode paralel membuat fitur ini cocok untuk skenario berikut:

• Kueri analitik pada volume data sangat besar

  Jika melibatkan data dalam jumlah menengah hingga besar, pernyataan SQL untuk kueri analitik biasanya kompleks dan memakan waktu. Anda dapat mengaktifkan fitur ePQ untuk mengurangi waktu respons secara linear.

• Beban resource tidak seimbang

  Kemampuan load balancing PolarProxy dapat membantu memastikan jumlah koneksi yang serupa dibuat untuk node-node dalam kluster. Namun, karena kompleksitas komputasi dalam kueri dan perbedaan penggunaan resource, load balancing berbasis koneksi tidak dapat sepenuhnya mencegah ketidakseimbangan beban antar node. Seperti database terdistribusi lainnya, node hotspot berdampak negatif pada PolarDB:

  1. Jika node read-only hotspot menyebabkan kueri lambat, node primary mungkin tidak dapat melakukan purge undo log, sehingga menyebabkan pembengkakan disk.

  2. Jika node read-only hotspot menyebabkan operasi redo apply yang lambat, node primary mungkin tidak dapat melakukan flush data, sehingga menurunkan kinerja throughput write.

  Fitur ePQ memperkenalkan tampilan resource global dan penjadwalan tugas adaptif berdasarkan tampilan tersebut. Berdasarkan nilai resource usage dan data affinity setiap node, sebagian atau seluruh tugas kueri dijadwalkan ke node yang memiliki resource menganggur untuk memastikan tingkat paralelisme (DOP) yang diinginkan dan penggunaan resource yang seimbang dalam kluster.

  

• Komputasi elastis

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

  

• Kombinasi layanan online dan offline

  Metode isolasi paling efektif adalah mengarahkan layanan transaksi online dan layanan analitik offline ke set node yang berbeda. Namun, metode ini meningkatkan biaya. Dalam kebanyakan kasus, layanan transaksi online dan layanan analitik offline memiliki jam puncak yang berbeda. Metode ekonomis adalah berbagi resource kluster antara layanan transaksi online dan layanan analitik offline serta mengarahkan layanan tersebut ke titik akhir kluster yang berbeda. Setelah fitur ePQ diaktifkan, resource menganggur didistribusikan ke layanan analitik offline selama jam sepi layanan transaksi online untuk mengurangi biaya dan meningkatkan efisiensi.

  

Catatan Penggunaan

Untuk informasi tentang cara menggunakan fitur ePQ, lihat Memulai.

Metrik Kinerja

Pengujian berikut menggunakan data sebesar 100 GB yang dihasilkan berdasarkan TPC Benchmark H (TPC-H) untuk menguji kinerja kluster PolarDB for MySQL 8.0. Dalam pengujian ini, kluster PolarDB memiliki empat node dengan 32 core CPU dan memori 256 GB (Dedicated). Untuk elastic parallel query node tunggal, parameter max_parallel_degree diatur ke 32 dan 0. Bandingkan data kinerja untuk kueri berurutan, elastic parallel query node tunggal dengan DOP 32, dan elastic parallel query empat node dengan DOP 128. Untuk informasi lebih lanjut, lihat Hasil pengujian kinerja dalam skenario parallel query.

Hasil pengujian di atas menunjukkan bahwa 100% kueri SQL dalam TPC-H dipercepat. Kecepatan kueri rata-rata 17 kali lebih cepat dan maksimal 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 elastic parallel query

Untuk informasi tentang cara mengeksekusi pernyataan EXPLAIN guna melihat informasi elastic parallel query dalam rencana eksekusi, lihat Eksekusi pernyataan EXPLAIN untuk melihat rencana eksekusi elastic parallel query.

Istilah

• Pemindaian paralel

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

• Penggabungan tabel paralel

  Jika fitur ePQ diaktifkan, operasi penggabungan multi-tabel didorong ke worker untuk pemrosesan paralel. Pengoptimal PolarDB memilih tabel optimal untuk pemindaian paralel, tetapi tidak melakukan pemindaian paralel untuk tabel lainnya. Setiap worker menghasilkan hasil parsial dan mengembalikannya ke thread leader. Thread leader mengumpulkan hasil tersebut menggunakan gather node dan mengembalikan hasil akhir ke client.

• Pengurutan paralel

  Pengoptimal PolarDB mendorong operasi ORDER BY ke semua worker untuk pengurutan paralel. Setiap worker menghasilkan hasil parsial dan mengembalikannya ke thread leader. Thread leader mengumpulkan, menggabungkan, dan mengurutkan semua hasil parsial menggunakan gather merge node, lalu mengembalikan hasil pengurutan akhir ke sisi client.

• Pengelompokan paralel

  Pengoptimal 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 mengembalikannya ke thread leader. Thread leader mengumpulkan hasil dari semua worker menggunakan gather node. Pengoptimal PolarDB menentukan apakah perlu melakukan operasi GROUP BY lagi di thread leader berdasarkan rencana kueri. Misalnya, jika loose index scan digunakan untuk mengeksekusi pernyataan GROUP BY, thread leader tidak melakukan operasi GROUP BY. Jika loose index scan tidak digunakan, thread leader melakukan operasi GROUP BY dan mengembalikan hasil akhir ke sisi client.

• Agregasi paralel

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

  • Agregasi satu fase: Pengoptimal 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 leader melakukan agregasi kedua.

  • Agregasi dua fase: Pada fase pertama, setiap worker yang terlibat dalam elastic parallel query melakukan agregasi. Pada fase kedua, gather node atau gather merge node mengembalikan hasil yang dihasilkan setiap worker ke thread leader. Kemudian, thread leader mengagregasi hasil dari semua worker untuk menghasilkan hasil akhir.

  • Agregasi shuffle dua fase: Pada fase pertama, setiap worker dalam elastic parallel query melakukan agregasi. Pada fase kedua, repartition node mendistribusikan hasil yang dihasilkan setiap worker ke beberapa worker berdasarkan kolom pengelompokan. Worker-worker tersebut menyelesaikan komputasi agregasi akhir secara paralel. Terakhir, hasil agregasi dirangkum di thread leader.

  Pengoptimal PolarDB menentukan metode agregasi spesifik berdasarkan biaya.

• Fungsi jendela paralel

  Pengoptimal 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 tahap selanjutnya, tugas komputasi berikutnya didistribusikan ke beberapa worker untuk eksekusi berdasarkan biaya guna memastikan paralelisasi maksimum.

• Dukungan untuk subkueri

  Dalam elastic parallel query, Anda dapat menggunakan salah satu kebijakan berikut untuk menjalankan subkueri:

  • Eksekusi berurutan di thread leader

    Jika subkueri tidak mendukung pemrosesan paralel, subkueri di thread leader dijalankan secara berurutan. Misalnya, jika dua tabel digabungkan menggunakan klausa JOIN yang mereferensikan user-defined function (UDF), subkueri dijalankan secara berurutan.

  • Eksekusi paralel di thread leader (menggunakan kelompok worker lain)

    Setelah rencana elastic parallel query dihasilkan, jika rencana eksekusi thread leader mencakup subkueri yang mendukung pemrosesan paralel, subkueri paralel tersebut tidak dapat dijalankan lebih awal atau secara paralel berdasarkan kebijakan akses bersama. Misalnya, jika subkueri mencakup fungsi jendela, subkueri tidak dapat dijalankan secara paralel berdasarkan kebijakan akses bersama.

  • Akses bersama

    Setelah rencana elastic parallel query dihasilkan, jika rencana eksekusi worker mereferensikan subkueri yang mendukung pemrosesan paralel, pengoptimal PolarDB menjalankan subkueri paralel lebih awal. Dengan demikian, worker dapat langsung mengakses hasil subkueri tersebut.

  • Didorong ke bawah (pushed down)

    Setelah rencana elastic parallel query dihasilkan, jika rencana eksekusi worker mereferensikan subkueri berkorelasi, worker menjalankan subkueri berkorelasi tersebut.