ApsaraDB RDS：Cache Kueri Cepat

Prasyarat

• Instans RDS Anda menjalankan MySQL 5.7 dengan versi mesin minor 20200331 atau lebih baru.

• Layanan proxy khusus dinonaktifkan untuk instans RDS Anda. Untuk informasi lebih lanjut, lihat Nonaktifkan layanan proxy khusus untuk instans ApsaraDB RDS for MySQL.

Informasi latar belakang

Cache kueri adalah mekanisme yang meningkatkan performa dengan menyimpan set hasil kueri dalam cache. Prinsip utamanya meliputi:

• Menyimpan set hasil: Untuk kueri yang memenuhi syarat, hasilnya langsung disimpan dalam cache, menghindari proses analisis SQL, optimisasi, dan eksekusi berulang, sehingga mengurangi beban CPU.

• Tujuan performa: Dengan mengurangi konsumsi sumber daya komputasi, waktu respons untuk kueri sederhana frekuensi tinggi dapat ditingkatkan secara signifikan.

Kekurangan Query Cache MySQL Asli

Query Cache MySQL asli menunjukkan performa buruk dalam skenario konkurensi tinggi karena cacat desain, termasuk masalah berikut:

• Pemrosesan konkurensi yang buruk. Jika beberapa core CPU dikonfigurasikan, jumlah kueri konkuren yang lebih besar dapat mengakibatkan penurunan performa.

• Manajemen memori yang buruk, dengan pemanfaatan memori rendah dan pengembalian tertunda, menyebabkan pemborosan memori.

• Jika rasio hit cache rendah, performa kueri tidak meningkat dan bahkan bisa menurun secara signifikan.

Karena masalah-masalah ini, Query Cache MySQL asli telah sepenuhnya dihapus di MySQL 8.0 dan secara default dinonaktifkan di versi sebelumnya.

Peningkatan inovatif dalam Fast Query Cache Alibaba Cloud

Tim database Alibaba Cloud merancang ulang dan mengimplementasikan Fast Query Cache untuk mengatasi kekurangan Query Cache asli, dengan optimisasi inti berikut:

Fast Query Cache dapat digunakan dalam berbagai skenario bisnis untuk meningkatkan performa kueri. Namun, query cache MySQL asli tidak memberikan dukungan yang sama.

Aktifkan fast query cache

Anda dapat mengaktifkan Fast Query Cache dengan mengonfigurasi parameter query_cache_type dan query_cache_size di Konsol ApsaraDB RDS.

Fast Query Cache membutuhkan ruang memori tambahan. Saat mengonfigurasi Fast Query Cache, kami sarankan Anda juga mengonfigurasi ulang parameter innodb_buffer_pool_size:

1. Atur parameter innodb_buffer_pool_size menjadi 90% dari nilai aslinya. 10% memori yang dikurangi digunakan sebagai ukuran cache kueri yang ditentukan oleh parameter query_cache_size. Misalnya, jika nilai asli parameter innodb_buffer_pool_size adalah {DBInstanceClassMemory*7/10}, atur parameter ini menjadi {DBInstanceClassMemory*63/100}. Untuk informasi lebih lanjut, lihat Ubah ukuran kolam buffer InnoDB.

2. Atur parameter query_cache_size. Untuk informasi lebih lanjut, lihat Modifikasi parameter instans.

   • Jika Anda dapat memperkirakan ukuran set hasil dengan akurat, Anda dapat mengatur parameter query_cache_size menjadi nilai yang sama dengan 20% dari ukuran set hasil.

   • Jika Anda tidak dapat memperkirakan ukuran set hasil dengan akurat, Anda dapat mengatur parameter query_cache_size menjadi nilai yang sama dengan 10% dari nilai parameter innodb_buffer_pool_size.

   Catatan

   Saat Anda mengubah spesifikasi instans RDS Anda, nilai parameter query_cache_size tidak berubah berdasarkan spesifikasi baru. Setelah perubahan spesifikasi diterapkan, Anda harus segera mengonfigurasi ulang parameter ini.

3. Atur parameter query_cache_type menjadi 1. Ini memungkinkan Anda mengaktifkan Fast Query Cache. Untuk informasi lebih lanjut, lihat Modifikasi parameter instans.

Perbandingan performa

Bandingkan permintaan per detik (QPS) dengan konfigurasi cache kueri yang berbeda dalam kondisi yang sama di berbagai kasus uji. Konfigurasi cache kueri ini adalah QC-OFF (tidak ada cache kueri yang diaktifkan), MySQL-QC (cache kueri MySQL asli diaktifkan), dan Fast-QC (Fast Query Cache diaktifkan).

• Lingkungan uji: Instans RDS khusus dengan 4 core CPU dan 8 GB memori.

• Alat uji: Sysbench.

• Ukuran data uji: 250 MB (total 25 tabel, 40.000 catatan per tabel).

• Skenario 1: Semua hit (read-only).

  Skrip oltp_point_select digunakan. Jalankan hanya pernyataan POINT SELECT berdasarkan kunci utama. Selain itu, pastikan Anda mengatur ukuran cache kueri menjadi 512 MB. Ukuran ini lebih besar dari ukuran data uji dan memungkinkan rasio hit cache mencapai 100%. Dalam kasus uji ini, fokus pada berapa banyak QPS meningkat berdasarkan jumlah kueri konkuren.

  Tabel 1. QPS untuk kueri baca dengan rasio hit cache 100%

  Jumlah kueri konkuren	QC-OFF	MySQL-QC (Peningkatan QPS dibandingkan QC-OFF)	Fast-QC (Peningkatan QPS dibandingkan QC-OFF)
  1	8.093	8.771 (8,38%)	9.261 (14,43%)
  8	62.262	65.686 (5,50%)	75.313 (20,96%)
  16	97.083	73.027 (-24,78%)	139.323 (43,51%)
  32	97.337	60.567 (-37,78%)	200.978 (106,48%)
  64	106.283	60.216 (-43,34%)	221.659 (108,56%)
  128	107.781	62.844 (-41,69%)	231.409 (114,70%)
  256	106.694	63.832 (-40,17%)	222.187 (108,25%)
  512	101.733	64.866 (-36,24%)	203.789 (100,32%)
  1.024	89.548	62.291 (-30,44%)	203.542 (127,30%)

  

  Catatan

  Berdasarkan hasil uji, saat jumlah kueri konkuren meningkat, QPS cache kueri MySQL asli menurun secara signifikan. Namun, QPS Fast Query Cache tidak menurun dan bahkan dapat meningkat hingga 100%.

• Skenario 2: Tingkat hit tinggi (read-only).

  Skenario uji adalah Sysbench oltp_read_only. Kasus penggunaan mencakup kueri rentang yang mengembalikan beberapa catatan. Saat Query Cache diatur ke 512 MB, memori relatif cukup, dan tingkat hit dapat melebihi 80%. Uji ini berfokus pada peningkatan performa di bawah berbagai beban konkuren.

  Tabel 2. QPS untuk kueri baca dengan rasio hit cache lebih dari 80%

  Jumlah kueri konkuren	QC-OFF	MySQL-QC (Peningkatan QPS dibandingkan QC-OFF)	Fast-QC (Peningkatan QPS dibandingkan QC-OFF)
  1	5099	6467 (26,83%)	7022 (37,71%)
  8	28782	28651 (-0,46%)	45017 (56,41%)
  16	35333	31099 (-11,98%)	66770 (88,97%)
  32	34864	27610 (-20,81%)	67623 (93,96%)
  64	35503	27518 (-22,49%)	75981 (114,01%)
  128	35744	27733 (-22,41%)	80396 (124,92%)
  256	35685	27738 (-22,27%)	80925 (126,78%)
  512	35308	27398 (-22,40%)	79323 (124,66%)
  1024	34044	26861 (-22,10%)	75742 (122,48%)

  

  Catatan

  Berdasarkan hasil uji, saat jumlah kueri konkuren meningkat, QPS cache kueri MySQL asli menurun secara signifikan. Namun, QPS Fast Query Cache terus meningkat, dan bahkan dapat meningkat lebih dari 100% pada puncaknya.

• Kasus uji 3: Uji QPS untuk kueri baca dengan rasio hit cache sekitar 10%.

  Skrip oltp_read_only digunakan. Jalankan kueri termasuk kueri rentang yang masing-masing mengembalikan beberapa catatan. Selain itu, pastikan Anda mengatur ukuran cache kueri menjadi 16 MB. Ukuran ini menghasilkan ruang memori yang tidak cukup dan penghapusan sejumlah besar data yang di-cache. Ini memungkinkan rasio hit cache turun menjadi sekitar 10%. Dalam kasus uji ini, fokus pada berapa banyak QPS menurun berdasarkan jumlah kueri konkuren.

  Tabel 3. QPS untuk kueri baca dengan rasio hit cache sekitar 10%

  Jumlah kueri konkuren	QC-OFF	MySQL-QC (Peningkatan QPS dibandingkan QC-OFF)	Fast-QC (Peningkatan QPS dibandingkan QC-OFF)
  1	5.004	4.727 (-5,54%)	5.199 (3,90%)
  8	28.795	22.542 (-21,72%)	28.578 (-0,75%)
  16	35455	24.064 (-32,13%)	35.682 (0,64%)
  32	34.526	21.330 (-38,22%)	35.871 (3,90%)
  64	35.514	19.791 (-44,27%)	36.051 (1,51%)
  128	35.983	19.519 (-45,75%)	36.253 (0,75%)
  256	35.695	19.168 (-46,30%)	36.337 (1,80%)
  512	35.182	18.420 (-47,64%)	35.972 (2,25%)
  1.024	33.915	20.168 (-40,53%)	34.546 (1,86%)

  

  Catatan

  Berdasarkan hasil uji, QPS cache kueri MySQL asli menurun secara signifikan, dengan kerugian performa mendekati 50% pada sebagian besar kasus. Namun, Fast Query Cache mengoptimalkan skenario dengan rasio hit rendah dan hampir tidak menyebabkan kerugian performa tambahan.

• Kasus uji 4: Uji QPS untuk kueri baca dan tulis.

  Skrip oltp_read_write digunakan. Jalankan transaksi yang berisi pembaruan ke tabel. Pembaruan sering ini mengakibatkan penghapusan data yang di-cache. Akibatnya, cache kueri yang dikonfigurasikan dianggap tidak valid. Dalam kasus uji ini, fokus pada berapa banyak QPS menurun berdasarkan jumlah kueri konkuren.

  Tabel 4. QPS untuk kueri baca dan tulis

  Jumlah kueri konkuren	QC-OFF	Fast-QC (Peningkatan QPS dibandingkan QC-OFF)
  1	4.152	4.098 (-1,30%)
  8	21.359	21.195 (-0,77%)
  16	26.020	25.548 (-1,81%)
  32	27.595	26.996 (-2,17%)
  64	29.229	28.733 (-1,70%)
  128	29.265	28.828 (-1,49%)
  256	29.911	29.616 (-0,99%)
  512	29.148	28.816 (-1,14%)
  1.024	29.204	28.824 (-1,30%)

  

  Catatan

  Berdasarkan hasil uji, saat jumlah kueri konkuren baca dan tulis meningkat, QPS Fast Query Cache hanya menurun dalam jumlah kecil.

Panduan praktik

Skenario

Fast Query Cache terutama digunakan untuk meningkatkan performa dalam skenario intensif baca. Direkomendasikan untuk lingkungan di mana pembacaan jauh lebih banyak daripada penulisan:

• Operasi bisnis yang didominasi oleh kueri dengan frekuensi penulisan rendah (seperti halaman detail produk e-commerce, kueri laporan).

• Menggunakan SQL_CACHE untuk secara eksplisit mengaktifkan caching untuk tabel tertentu (seperti tabel dengan rasio baca-tulis tinggi). Anda juga dapat melihat rasio baca-tulis tingkat tabel melalui tabel TABLE_STATISTICS dan secara eksplisit mengaktifkan Fast Query Cache menggunakan kata kunci SQL_CACHE untuk tabel dengan rasio baca-tulis tinggi. Untuk informasi tentang cara menanyakan tabel TABLE_STATISTICS, lihat Performance Insight.

Tidak direkomendasikan untuk:

• Skenario intensif penulisan (seperti sistem transaksi frekuensi tinggi): Invalidasi cache yang sering dapat menyebabkan penurunan performa.

• Skenario yang memerlukan akurasi data real-time tinggi (seperti kutipan pasar saham): Data yang di-cache mungkin tidak konsisten dengan data real-time.

• Sebelum mengaktifkan secara global, disarankan untuk memeriksa rasio hit InnoDB Buffer Pool (rasio hit = 1 - Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests). Jika rasio hit kurang dari 80%, mengaktifkan Fast Query Cache tidak direkomendasikan.

Metode penggunaan cache (Query_cache_type)

Parameter query_cache_type mendukung modifikasi tingkat sesi. Pengguna dapat mengonfigurasinya secara fleksibel berdasarkan skenario bisnis aktual. Silakan merujuk pada rekomendasi berikut:

Pengaturan ukuran cache (Query_cache_size)

query_cache_size erat kaitannya dengan kueri SQL. Jika cache berisi kueri yang mengembalikan beberapa catatan, cache mungkin perlu beberapa kali lebih besar dari volume data. Jika kueri SQL tidak termasuk kueri rentang, Anda dapat merujuk pada tes berikut untuk mengevaluasi hubungan antara volume data dan query_cache_size.

• Lingkungan uji: Instans RDS khusus dengan 4 core CPU dan 8 GB memori (innodb_buffer_pool_size = 6 GB).

• Alat uji: Sysbench.

• Ukuran data uji: 10 GB (total 100 tabel, 400.000 catatan per tabel).

Kasus uji: Tentukan ukuran cache yang berbeda menggunakan parameter query_cache_size dan jalankan skrip oltp_point_select untuk setiap ukuran cache. Pastikan 64 thread berjalan bersamaan untuk menanyakan data. Dalam hal ini, data uji mencakup 20% data panas. Dengan cara ini, Anda dapat memperoleh dampak dari ukuran cache yang berbeda (query_cache_size) terhadap QPS. Ukuran set hasil aktual adalah 2,5 GB berdasarkan ukuran data uji.

Performa Fast Query Cache tidak menurun terlepas dari nilai parameter query_cache_size. Secara spesifik, Fast Query Cache memberikan performa yang jauh lebih tinggi daripada Query Cache MySQL asli untuk kueri kunci utama tanpa memandang rasio hit cache. Dalam beberapa keadaan, performa bahkan bisa meningkat lebih dari 90%. Jika rasio hit cache kurang dari 90%, Fast Query Cache memberikan performa yang lebih tinggi daripada Query Cache MySQL asli dan menghemat banyak sumber daya CPU untuk kueri rentang dan kueri yang berisi klausa ORDER BY.