Menulis Binary Large Objects (BLOB) ke MySQL dalam lingkungan konkurensi tinggi sering menyebabkan bottleneck performa, seperti kontensi kunci dan pembuatan redo log berlebihan. PolarDB mengatasi tantangan ini melalui optimasi tingkat kernel yang menyelesaikan masalah kontensi kunci, tekanan I/O, dan manajemen ruang selama operasi BLOB. Hal ini secara signifikan meningkatkan performa DML dan DDL serta memastikan layanan Anda berjalan stabil dan efisien di bawah beban kerja konkurensi tinggi.
Ikhtisar
Binary Large Object (BLOB) adalah tipe bidang database yang digunakan untuk menyimpan objek data besar seperti gambar, dokumen, dan teks panjang. Pada engine InnoDB MySQL asli, ketika bidang BLOB dalam baris data melebihi ukuran tertentu, InnoDB menyimpannya pada halaman data off-page terpisah. Meskipun mekanisme ini mampu menangani data besar, mekanisme tersebut juga menimbulkan tiga tantangan performa utama:
Bottleneck penulisan konkuren: Memperbarui BLOB off-page memerlukan kunci pesimistis, sehingga hanya satu thread yang dapat menulis BLOB ke tabel dalam satu waktu, sangat membatasi konkurensi.
Tekanan I/O meningkat: Bidang besar menghasilkan entri redo log yang besar. Jika I/O disk tidak mencukupi, proses flushing log menjadi bottleneck dan menghambat operasi penulisan foreground.
Pemulihan ruang yang tertunda: Proses pembersihan data BLOB lama, yang dikenal sebagai Purge, tidak efisien. Hal ini dapat menyebabkan pembengkakan ruang penyimpanan dan degradasi performa.
Fitur optimasi BLOB di PolarDB menyelesaikan masalah-masalah tersebut dengan mengoptimalkan seluruh siklus hidup BLOB—termasuk penulisan, pembaruan, dan pemulihan ruang—pada tingkat kernel, tanpa memerlukan perubahan aplikasi.
Penagihan
Fitur optimasi performa BLOB telah terintegrasi dalam kernel PolarDB dan tersedia tanpa biaya tambahan.
Optimalkan performa penulisan BLOB
Jika Anda mengalami bottleneck throughput atau latensi tinggi saat menulis ke tabel BLOB selama jam sibuk, penyebabnya sering kali adalah kontensi kunci tulis. PolarDB menyelesaikan masalah ini melalui pre-alokasi halaman dan optimasi index latch.
Pre-alokasi halaman
Optimasi ini memecah proses penulisan BLOB menjadi langkah-langkah berikut:
Menghitung jumlah halaman data yang dibutuhkan dan mengalokasikannya dalam satu operasi batch.
Menyalin data dalam keadaan bebas kunci (lock-free), mengisi halaman yang baru dialokasikan dengan konten BLOB.
Menautkan rantai halaman data yang dihasilkan ke catatan indeks dengan satu operasi kunci optimis.
Sepanjang proses ini, hanya fase alokasi ruang awal yang bersifat eksklusif. Operasi yang lebih memakan waktu, seperti penyalinan data, dapat berjalan secara konkuren dengan penulisan BLOB lainnya. Selain itu, karena penyalinan data terjadi di luar critical section, sistem menghindari risiko satu operasi penulisan menghasilkan volume besar data redo log yang dapat mengisi buffer log dan menghambat penulisan. Akibatnya, mekanisme ini meminimalkan durasi pemegangan kunci global, sehingga secara signifikan meningkatkan performa penulisan konkuren.
Optimasi index latch
Untuk tabel yang berisi bidang BLOB berukuran kecil (di bawah 8 KB) atau campuran, MySQL asli sering meninggalkan kunci optimis terlalu dini selama pembaruan karena operasi modifikasi struktur halaman indeks (SMO). Sistem kemudian beralih ke model kunci pesimistis yang tidak efisien, yang sangat memengaruhi performa konkuren. Optimasi index latch mengatasi bottleneck ini dengan mempertahankan operasi pada jalur optimis lebih lama. Optimasi ini bekerja dalam langkah-langkah berikut:
Tetap pada jalur optimis: Ketika potensi pembaruan bidang BLOB terdeteksi, logika optimasi tidak langsung beralih ke kunci pesimistis. Sebaliknya, sistem tetap memegang latch bersama (S-latch)—yang memiliki probabilitas konflik lebih rendah—dan tetap berada pada jalur pembaruan optimis.
Prabangun dan coba perbarui: Pada jalur optimis, sistem membangun struktur data BLOB yang diperlukan untuk pembaruan dan mencoba memodifikasi halaman indeks secara langsung.
Putuskan dan komit atau fallback:
Berhasil: Jika catatan yang diperbarui sesuai dengan kapasitas ruang halaman indeks saat ini, operasi selesai dengan cepat melalui jalur optimis.
Gagal: Jika halaman tidak memiliki ruang yang cukup, misalnya, optimasi secara otomatis membatalkan upaya tersebut dan beralih mulus ke jalur kunci pesimistis MySQL asli. Jalur asli kemudian menyelesaikan seluruh operasi pembaruan, memastikan konsistensi data.
Keunggulan utama pendekatan optimis ini adalah meningkatkan secara signifikan tingkat keberhasilan pembaruan optimis. Pendekatan ini memungkinkan banyak operasi—yang seharusnya jatuh ke kunci pesimistis—selesai lebih efisien, sehingga sangat meningkatkan throughput pembaruan data BLOB campuran di bawah kondisi konkurensi tinggi.
Aktifkan optimasi penulisan
Di PolarDB console, buka halaman untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:
Parameter | Deskripsi | Versi yang didukung |
| Mengaktifkan atau menonaktifkan pre-alokasi halaman untuk BLOB. Nilai yang valid:
|
|
| Menetapkan panjang maksimum kolom BLOB tunggal yang menggunakan pre-alokasi halaman. | |
| Mengaktifkan atau menonaktifkan optimasi index latch untuk BLOB. |
Kurangi redo log untuk penulisan BLOB
Jika workload Anda melibatkan penulisan data BLOB dalam jumlah besar sehingga laju pembuatan redo log menjadi bottleneck I/O, Anda dapat mengaktifkan kompresi redo untuk mengurangi tekanan tersebut.
Kompresi redo bekerja dengan mengompres entri redo log terkait BLOB secara paralel sebelum menuliskannya ke buffer log. Proses ini secara signifikan mengurangi volume data redo log yang ditulis ke disk, dengan pengujian menunjukkan pengurangan rata-rata 40% hingga 60%. Hal ini menurunkan tekanan I/O penyimpanan dan mencegah modul redo menjadi bottleneck yang memengaruhi performa penulisan secara keseluruhan. Selama pemulihan crash, sistem secara otomatis mendekompresi dan menerapkan log tersebut.
Aktifkan kompresi redo
Di PolarDB console, buka halaman untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:
Parameter | Deskripsi | Versi yang didukung |
| Menetapkan algoritma kompresi untuk redo log BLOB. Nilai yang valid:
|
|
| Menetapkan tingkat kompresi untuk algoritma yang dipilih. Nilai yang valid: 0 hingga 9. Default: 6. |
Percepat pemulihan ruang BLOB
Jika Anda memperhatikan bahwa pemulihan ruang tablespace lambat dan file terus bertambah setelah sering menghapus atau memperbarui data BLOB, akar permasalahannya adalah proses Purge latar belakang MySQL asli yang tidak efisien. Saat membersihkan data, proses ini pertama-tama memperoleh kunci inti seperti Index SX sebelum membaca halaman BLOB. Jika halaman tidak berada di memori, operasi I/O disk yang memakan waktu akan dipicu sambil kunci masih dipegang, yang dapat menghambat operasi konkuren lain pada tabel dalam periode yang lama. Optimasi Purge pre-read PolarDB menyelesaikan bottleneck ini dengan memisahkan operasi I/O dari proses penguncian. Optimasi ini bekerja dalam langkah-langkah berikut:
Identifikasi halaman target: Sebelum memperoleh kunci dan memulai pembersihan, proses Purge terlebih dahulu mengidentifikasi rantai lengkap BLOB off-page yang perlu dipulihkan.
Pre-read asinkron: Proses ini memulai permintaan I/O asinkron untuk memuat halaman target yang belum berada di memori dari disk ke kolam buffer.
Bersihkan dengan cepat: Setelah semua halaman dimuat ke memori, proses Purge memperoleh kunci inti yang diperlukan seperti
Index SX, lalu dengan cepat melakukan operasi pelepasan halaman di memori dan modifikasi metadata.
Mekanisme Purge pre-read menghindari pelaksanaan operasi I/O disk apa pun dalam critical section tempat kunci dipegang. Dengan memindahkan operasi I/O—yang paling memakan waktu—ke tahap sebelumnya, durasi pemegangan kunci dikurangi menjadi hanya waktu operasi cepat di memori. Hal ini tidak hanya meningkatkan efisiensi pemulihan data BLOB dan mencegah pembengkakan ruang, tetapi yang lebih penting, mengurangi penghambatan workload foreground—seperti penulisan konkurensi tinggi—oleh proses pembersihan latar belakang. Akibatnya, performa konkurensi dan stabilitas database secara keseluruhan meningkat.
Aktifkan Purge pre-read
Di PolarDB console, buka halaman untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:
Parameter | Deskripsi | Versi yang didukung |
| Mengaktifkan atau menonaktifkan Purge pre-read untuk BLOB. Nilai yang valid:
| Didukung di semua versi. |
Tingkatkan efisiensi eksekusi DDL
Jika Anda perlu menjalankan operasi DDL, seperti ALTER TABLE, pada tabel yang berisi banyak data BLOB dan operasi tersebut memakan waktu terlalu lama, Anda dapat mengaktifkan optimasi BLOB terkait DDL untuk secara signifikan mengurangi durasi operasi.
Pre-alokasi halaman: Karena kolom overflow untuk bidang BLOB berada pada primary key, operasi DDL yang membangun ulang tabel utama juga melibatkan penulisan bidang BLOB. Optimasi pre-alokasi halaman menggunakan metode penguncian yang lebih langsung dan sederhana untuk menulis data BLOB, sehingga menghindari overhead penanganan konflik konkurensi kompleks dan secara signifikan meningkatkan efisiensi pembangunan ulang.
Optimasi latch: DDL paralel mempartisi pohon primary key, sehingga beberapa thread pekerja tidak beroperasi pada halaman data yang sama. Optimasi ini melindungi alokasi halaman baru secara independen, memungkinkan operasi lain berjalan secara konkuren dan meningkatkan efisiensi.
Optimisasi ulang:
Agregasi halaman: Selama bulk load, alih-alih menghasilkan entri redo log untuk setiap record, sistem menuliskan perubahan untuk seluruh halaman data sebagai satu entri redo log besar setelah halaman penuh. Hal ini meningkatkan efisiensi operasi redo.
Kompresi agregat: Entri redo log besar yang telah diagregasi kemudian dikompresi untuk lebih mengurangi volume data redo log yang dihasilkan selama proses DDL.
Aktifkan optimasi DDL
Di PolarDB console, buka halaman untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:
Beberapa parameter dalam tabel berikut tidak dapat diubah secara manual. Jika Anda perlu mengubahnya, silakan atau mengajukan Tiket untuk bantuan.
Parameter | Deskripsi | Versi yang didukung |
| Menentukan apakah akan mengaktifkan optimasi BLOB selama operasi DDL. Nilai yang valid:
|
|
| Menentukan apakah akan mengaktifkan optimasi kunci indeks selama operasi DDL. Nilai yang valid:
|
|
| Menentukan apakah akan mengaktifkan agregasi redo berbasis halaman selama bulk loading DDL. Nilai yang valid:
|
|
| Menetapkan algoritma kompresi redo untuk bulk loading DDL. Nilai yang valid:
|
|
| Menetapkan target kompresi redo selama operasi DDL. Nilai yang valid:
|
|
Optimasi modul terkait
Dalam skenario BLOB throughput tinggi, bottleneck juga dapat terjadi di modul lain. Untuk mencapai performa yang lebih baik lagi, PolarDB menyediakan optimasi terkait berikut:
Penulisan redo log asinkron paralel: Beberapa thread membagi data dalam buffer redo log dan mengirimkannya secara konkuren sebagai tugas I/O asinkron. Hal ini secara signifikan meningkatkan throughput penulisan redo log, mencapai hingga 4 GB/s dalam pengujian.
Optimasi ekstensi file: Berbasis sistem file terdistribusi yang dikembangkan sendiri oleh PolarDB, operasi ekstensi tablespace hanya memerlukan modifikasi sejumlah kecil metadata. Operasi zero-filling file asli dihilangkan, sehingga waktu dan overhead kunci untuk ekstensi file tidak lagi menjadi bottleneck.
Pembersihan halaman kotor bebas kunci: Optimasi ini menggunakan teknologi shadow page. Saat membersihkan halaman kotor, sistem terlebih dahulu membuat salinan di memori, melepaskan kunci halaman, lalu menggunakan salinan tersebut untuk operasi I/O. Hal ini mencegah operasi I/O menghambat permintaan tulis karena tidak ada kunci halaman yang dipegang selama flushing.
Tolok ukur performa
Data berikut menunjukkan peningkatan performa dalam skenario DML dan DDL setelah mengaktifkan optimasi BLOB.
Performa DML: Dalam skenario konkurensi tinggi dengan panjang baris 100 KB dan 200 KB, optimasi PolarDB meningkatkan performa insert dan update hampir 3 kali lipat. Ketika dikombinasikan dengan kompresi redo, performa meningkat 4 hingga 5 kali lipat.
Performa DDL: Untuk tabel 40 GB yang berisi bidang BLOB, mengaktifkan optimasi ini meningkatkan laju penulisan DDL sebesar 5 hingga 6 kali lipat dan mengurangi total durasi eksekusi sebesar 84%.
