PolarDB：Cache Hasil Parsial

Ikhtisar

PTRC menyimpan set hasil perantara yang dihasilkan oleh operator tertentu dalam query, seperti subquery terkait dan nested loop join. Hasil yang disimpan akan digunakan kembali jika operator yang sama dieksekusi lagi.

Cache hasil bersifat "parsial" dalam dua aspek:

• PTRC hanya menyimpan set hasil perantara dari operator tertentu dalam query, bukan set hasil dari seluruh query.

• PTRC tidak menyimpan semua set hasil dari operator-operator tersebut. Ruang lingkup set hasil yang disimpan dibatasi oleh batasan memori.

Dibandingkan dengan mekanisme cache query tradisional, PTRC bekerja untuk subquery, bukan seluruh query, dan siklus hidupnya dimulai dan berakhir seiring dengan eksekusi query. PTRC cocok untuk berbagai skenario yang lebih luas karena hanya bekerja pada operator, sehingga tidak menyebabkan inkonsistensi data ketika query dijalankan di beberapa node. PTRC dapat diaktifkan selama satu operator dalam query memenuhi persyaratan tertentu, seperti yang dijelaskan dalam bagian berikut. Pengoptimal query menentukan apakah akan menggunakan PTRC berdasarkan biaya.

Cara Kerja PTRC

PTRC dapat diaktifkan untuk operator jika memenuhi persyaratan berikut:

• Operator bergantung pada parameter terkait dan dieksekusi beberapa kali dalam query, seperti nested loop join dan subquery terkait.

• Parameter terkait dari operator tetap sama saat operator dieksekusi berulang kali. Operator tidak boleh berisi fungsi yang menyebabkan perubahan pada hasil, seperti Random, NOW, dan UDF.

Parameter terkait adalah parameter dalam query luar yang menjadi acuan operator. Sebagai contoh, sebuah query berisi operasi berikut: t1 JOIN t2 ON t1.a = t2.a. Dalam operasi ini, setiap baris dari t1, tabel penggerak, secara terpisah digabungkan dengan baris dari tabel t2. t1.a adalah parameter terkait dari nested loop join ini. Jika t1 berisi nilai duplikat yang sesuai dengan t1.a, PTRC dapat menggunakan kembali hasil untuk nilai-nilai tersebut. Contoh lainnya adalah subquery terkait, di mana setiap eksekusi subquery bergantung pada hasil query luar sebagai parameter penggerak.

TPC-H Q17 adalah contoh tipikal query yang dapat memperoleh manfaat dari PTRC.

select
        sum(l_extendedprice) / 7.0 as avg_yearly
from
        lineitem,
        part
where
        p_partkey = l_partkey
        and p_brand = 'Brand#34'
        and p_container = 'MED BOX'
        and l_quantity < (
                select
                        0.2 * avg(l_quantity)
                from
                        lineitem
                where
                        l_partkey = p_partkey
        );

PTRC menyimpan hasil dalam format pasangan kunci-nilai, di mana kuncinya adalah parameter terkait dari operator dan nilainya adalah hasil perantara. Dalam contoh ini, kuncinya adalah p_partkey dan nilainya adalah true atau false.

Gambar berikut menunjukkan proses eksekusi yang melibatkan PTRC.

Setiap kali subquery dieksekusi, sistem memeriksa apakah kunci p_partkey ada dalam cache PTRC.

• Jika tidak ditemukan, subquery dieksekusi, dan hasilnya ditambahkan ke cache.

• Jika ditemukan, sistem langsung menggunakan hasil yang tersimpan tanpa mengeksekusi subquery.

Dalam TPC-H Q17, subquery dieksekusi setelah part digabungkan dengan lineitem. Hasil gabungan tersebut berisi sejumlah besar nilai identik dalam p_partkey, yaitu parameter terkait. Hasil untuk nilai-nilai p_partkey ini dapat digunakan kembali oleh PTRC, yang secara signifikan meningkatkan performa.

Dalam rencana eksekusi yang dikembalikan untuk pernyataan EXPLAIN, operator bernama Partial result cache ditampilkan sebelum subquery dieksekusi, seperti yang ditunjukkan pada gambar berikut. Ini menunjukkan bahwa fitur PTRC sedang berlaku.

Prasyarat

Kluster PolarDB for MySQL menjalankan MySQL 8.0 dan menggunakan versi revisi 8.0.2.2.9 atau yang lebih baru. Untuk informasi tentang cara memeriksa versi kluster, lihat Versi Engine.

Parameter

Bagaimana Pengoptimal Menentukan Apakah Akan Menggunakan PTRC

PTRC mengonsumsi sumber daya sistem saat berlaku. Misalnya, ia memeriksa hasil yang disimpan setiap kali operator dieksekusi, dan hasil yang disimpan menempati ruang memori. Oleh karena itu, PTRC mungkin tidak cocok untuk semua query.

Terserah pengoptimal untuk menentukan apakah akan menggunakan PTRC untuk query. Parameter berikut dipertimbangkan:

• partial_result_cache_cost_threshold

• partial_result_cache_low_hit_rate

partial_result_cache_cost_threshold memiliki prioritas.

• Jika biaya keseluruhan query lebih rendah dari threshold ini, pengoptimal menganggap query ini sebagai query pendek yang menimbulkan biaya eksekusi yang sepele. Dalam hal ini, PTRC hanya dapat sedikit meningkatkan performa, atau bahkan memperlambat kecepatan respons karena pemeriksaan cache.

• Jika biaya keseluruhan query lebih tinggi dari threshold ini, pengoptimal melintasi semua operator untuk menemukan yang memenuhi persyaratan PTRC, lalu memperkirakan laju hit dari operator yang memenuhi syarat.

  hit_rate = (fanout - ndv)/fanout

  fanout menunjukkan jumlah total eksekusi operator. ndv menunjukkan jumlah nilai unik dari parameter terkait (kunci).

Ketika hit_rate lebih rendah dari nilai partial_result_cache_low_hit_rate, PTRC tidak digunakan untuk operator tersebut. Namun, estimasi mungkin tidak selalu akurat. Di MySQL, biaya diperkirakan berdasarkan indeks atau histogram. Jika kolom parameter terkait tidak memiliki indeks atau histogram, ndv tidak dapat diperkirakan dengan akurat. Dalam kasus ini, pengoptimal mengaktifkan PTRC untuk query tanpa memperkirakan biaya. Mekanisme umpan balik dinamis akan menentukan, selama eksekusi query, apakah akan terus menggunakan PTRC.

Mekanisme Umpan Balik Dinamis PTRC

Selama eksekusi query, sistem memantau laju hit dan penggunaan memori PTRC dan menentukan apakah akan terus menggunakan fitur tersebut. Ini adalah mekanisme umpan balik dinamis. Saat PTRC diaktifkan, sistem mengumpulkan informasi dari setiap pemeriksaan cache, dan secara berkala menghitung laju hit berdasarkan informasi tersebut. Jika laju hit menjadi lebih rendah dari nilai partial_result_cache_low_hit_rate, sistem menonaktifkan PTRC untuk sisa eksekusi guna mengurangi overhead performa.

Parameter partial_result_cache_check_frequency menentukan seberapa sering laju hit dihitung. Misalnya, jika nilai default 200 digunakan, laju hit dihitung setiap 200 cache miss.

Sistem juga menghitung laju hit ketika jumlah memori yang digunakan oleh cache PTRC mencapai nilai threshold. Dalam kasus ini, sistem mungkin juga menghapus cache atau memindahkan cache ke disk.

Penjelasan mekanisme saat batas memori terlampaui:

1. Ketika hit_rate lebih rendah dari partial_result_cache_low_hit_rate, PTRC dinonaktifkan.

2. Ketika hit_rate lebih tinggi dari partial_result_cache_high_hit_rate, cache yang disimpan di memori dipindahkan ke disk. Perubahan media penyimpanan tidak secara drastis menurunkan peningkatan performa.

3. Ketika hit_rate berada di antara dua threshold, mekanisme Least Recently Used (LRU) berlaku. Sistem menghapus cache yang tidak memenuhi persyaratan laju hit, dan menyimpan data baru. Jika cache baru lagi-lagi menyebabkan penggunaan memori berlebih, mekanisme umpan balik dinamis dipicu kembali.

Batas memori ditentukan oleh parameter partial_result_cache_max_mem_size. Saat penggunaan memori PTRC dalam query melebihi batas ini, mekanisme umpan balik dinamis dipicu untuk semua operator yang menggunakan PTRC dalam query tersebut.

Pengujian Performa

Faktor-faktor berikut memengaruhi dampak PTRC:

• Biaya operator tempat PTRC digunakan. Semakin tinggi biayanya, semakin besar peningkatan performa. Jika biayanya rendah, PTRC hanya memberikan peningkatan performa yang kecil.

• Laju hit cache. Semakin tinggi laju hit, semakin besar peningkatan performa.

Dalam pengujian ini, PTRC digunakan untuk subquery berikut dalam TPC-H Q17.

Rencana eksekusi query dengan PTRC diaktifkan.

Dalam TPCH-Q17, laju hit cache adalah 96%. Performa meningkat secara signifikan berkat PTRC, seperti yang ditunjukkan pada gambar berikut.

Ringkasan

PTRC dirancang untuk query dengan operator kompleks yang bergantung pada parameter terkait. Ia menyimpan dan menggunakan kembali set hasil perantara untuk mengurangi komputasi berulang. Jika laju hit tinggi, PTRC dapat memberikan peningkatan performa yang signifikan. Operator yang cocok untuk PTRC termasuk subquery terkait dan nested loop join (inner join, outer join, semi join, dan anti join).