Optimalisasi Kinerja BLOB - PolarDB - Alibaba Cloud Documentation Center

Menulis Binary Large Objects (BLOB) ke MySQL di lingkungan konkurensi tinggi sering menyebabkan bottleneck kinerja, seperti contention kunci dan generasi redo log berlebihan. PolarDB mengatasi tantangan ini dengan optimasi tingkat kernel yang menyelesaikan masalah contention kunci, tekanan I/O, dan manajemen ruang selama operasi BLOB. Hal ini secara signifikan meningkatkan kinerja DML dan DDL, memastikan layanan Anda berjalan stabil dan efisien di bawah beban kerja konkurensi tinggi.

Ikhtisar

Binary Large Object (BLOB) adalah tipe field database yang digunakan untuk menyimpan objek data besar seperti gambar, dokumen, dan teks panjang. Pada engine InnoDB MySQL native, ketika field BLOB dalam baris data melebihi ukuran tertentu, InnoDB menyimpannya pada halaman data off-page terpisah. Meskipun mekanisme ini mampu menangani data besar, hal tersebut juga menimbulkan tiga tantangan kinerja 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: Field besar menghasilkan entri redo log yang besar. Jika I/O disk tidak mencukupi, flushing log menjadi bottleneck dan menghambat operasi tulis foreground.
Pemulihan ruang yang tertunda: Proses pembersihan data BLOB lama, yang dikenal sebagai proses Purge, tidak efisien. Hal ini dapat menyebabkan pembengkakan ruang penyimpanan dan degradasi kinerja.

Fitur optimasi BLOB di PolarDB menyelesaikan permasalahan ini dengan mengoptimalkan seluruh siklus hidup BLOB—termasuk penulisan, pembaruan, dan pemulihan ruang—pada tingkat kernel, tanpa memerlukan perubahan aplikasi.

Penagihan

Fitur optimasi kinerja BLOB sudah terintegrasi dalam kernel PolarDB dan tersedia tanpa biaya tambahan.

Optimalkan kinerja penulisan BLOB

Jika Anda mengalami bottleneck throughput atau latensi tinggi saat menulis ke tabel BLOB selama jam sibuk, penyebabnya sering kali adalah contention kunci tulis. PolarDB menyelesaikan masalah ini dengan 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 diperlukan dan mengalokasikannya dalam satu operasi batch.
Menyalin data dalam kondisi 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 tulis 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 kinerja penulisan konkuren.

Optimasi index latch

Untuk tabel yang berisi field BLOB kecil (di bawah 8 KB) atau campuran ukuran, MySQL native 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, sehingga sangat memengaruhi kinerja 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: Saat potensi pembaruan field BLOB terdeteksi, logika optimasi tidak langsung beralih ke kunci pesimistis. Sebaliknya, sistem tetap memegang shared latch (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 native. Jalur native 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 beralih ke kunci pesimistis—selesai lebih efisien. Hal ini sangat meningkatkan throughput untuk memperbarui data BLOB campuran ukuran di bawah konkurensi tinggi.

Aktifkan optimasi penulisan

Di PolarDB console, buka halaman Settings and Management > Parameters untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:

Parameter	Deskripsi	Versi yang didukung
`innodb_blob_prepare_pages`	Mengaktifkan atau menonaktifkan pre-alokasi halaman untuk BLOB. Nilai yang valid: ON: Diaktifkan OFF: Dinonaktifkan	MySQL 5.6: Tidak didukung MySQL 5.7: versi minor 5.7.1.0.35 atau lebih baru. MySQL 8.0.1: versi minor 8.0.1.1.47 atau lebih baru. MySQL 8.0.2: Tidak didukung
`innodb_blob_prepare_max_extern_size`	Menetapkan panjang maksimum kolom BLOB tunggal yang menggunakan pre-alokasi halaman.
`innodb_blob_latch_optimize`	Mengaktifkan atau menonaktifkan optimasi index latch untuk BLOB.

Kurangi redo log untuk penulisan BLOB

Jika beban kerja Anda melibatkan penulisan data BLOB dalam jumlah besar sehingga laju generasi redo log menjadi bottleneck I/O, Anda dapat mengaktifkan kompresi redo untuk mengurangi tekanan tersebut.

Kompresi redo bekerja dengan mengompresi 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 storage dan mencegah modul redo menjadi bottleneck yang memengaruhi kinerja tulis secara keseluruhan. Selama pemulihan crash, sistem secara otomatis mendekompresi dan menerapkan log tersebut.

Aktifkan kompresi redo

Di PolarDB console, buka halaman Configurations and management > Parameter settings untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:

Parameter

Deskripsi

Versi yang didukung

innodb_blob_redo_compress_algorithm

Menetapkan algoritma kompresi untuk redo log BLOB. Nilai yang valid:

none (Default)
lz4
zstd
zlib

MySQL 5.6: Tidak didukung
MySQL 5.7: versi minor 5.7.1.0.39 atau lebih baru.
MySQL 8.0.1: Tidak didukung
MySQL 8.0.2: Tidak didukung

innodb_blob_redo_compress_level

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 native yang tidak efisien. Saat membersihkan data, proses ini pertama-tama memperoleh kunci inti, seperti Index SX, sebelum membaca halaman BLOB. Jika halaman tidak ada di memori, operasi I/O disk yang memakan waktu 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 tersebut memulai permintaan I/O asinkron untuk memuat halaman target yang belum ada di memori dari disk ke buffer pool.
Bersihkan dengan cepat: Setelah semua halaman dimuat ke memori, proses Purge memperoleh kunci inti yang diperlukan, seperti Index SX, dan dengan cepat melakukan operasi pelepasan halaman di memori serta 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 operasi cepat di memori. Hal ini tidak hanya meningkatkan efisiensi pemulihan data BLOB dan mencegah pembengkakan ruang, tetapi yang lebih penting, mengurangi penghambatan beban kerja foreground—seperti penulisan konkurensi tinggi—oleh proses pembersihan latar belakang. Akibatnya, kinerja konkurensi dan stabilitas database secara keseluruhan meningkat.

Aktifkan Purge pre-read

Di PolarDB console, buka halaman Configurations and management > Parameter settings untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:

Parameter

Deskripsi

Versi yang didukung

innodb_purge_blob_read_ahead

Mengaktifkan atau menonaktifkan Purge pre-read untuk BLOB.

Nilai yang valid:

ON: Diaktifkan
OFF: Dinonaktifkan

Didukung di semua versi.

Tingkatkan efisiensi eksekusi DDL

Jika Anda perlu melakukan operasi DDL, seperti ALTER TABLE, pada tabel dengan data BLOB dalam jumlah besar 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 field BLOB ada pada primary key, operasi DDL yang membangun ulang tabel utama juga melibatkan penulisan field BLOB. Optimasi pre-alokasi halaman menggunakan metode penguncian yang lebih langsung dan disederhanakan 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, yang memungkinkan operasi lain berjalan secara konkuren dan meningkatkan efisiensi.
Redo Optimization:
1. Agregasi halaman: Selama bulk load, alih-alih menghasilkan entri redo log untuk setiap catatan, sistem menuliskan perubahan untuk seluruh halaman data sebagai satu entri redo log besar setelah halaman penuh. Hal ini meningkatkan efisiensi operasi redo.
2. 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 Configurations and management > Parameter settings untuk melihat dan mengubah parameter berikut guna mengaktifkan optimasi ini:

Catatan

Beberapa parameter dalam tabel berikut tidak dapat diubah secara manual. Jika Anda perlu mengubahnya, silakan submit a ticket untuk bantuan.

Parameter	Deskripsi	Versi yang didukung
`innodb_blob_prepare_pages_in_ddl`	Menentukan apakah akan mengaktifkan optimasi BLOB selama operasi DDL. Nilai yang valid: OFF (Default) ON	MySQL 5.6: Tidak didukung MySQL 5.7: versi minor 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: versi minor 8.0.1.1.50 atau lebih baru. MySQL 8.0.2: Tidak didukung
`innodb_bulk_load_without_index_lock_enable`	Menentukan apakah akan mengaktifkan optimasi kunci indeks selama operasi DDL. Nilai yang valid: OFF (Default) ON	MySQL 5.6: Tidak didukung MySQL 5.7: versi minor 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: versi minor 8.0.1.1.47 atau lebih baru. MySQL 8.0.2: versi minor 8.0.2.2.30 atau lebih baru.
`innodb_bulk_load_page_grained_redo_enable`	Menentukan apakah akan mengaktifkan agregasi redo berbasis halaman selama bulk loading DDL. Nilai yang valid: OFF ON (Default)	MySQL 5.6: Tidak didukung MySQL 5.7: Didukung, tanpa persyaratan versi minor. MySQL 8.0.1: Didukung, tanpa persyaratan versi minor. MySQL 8.0.2: Didukung, tanpa persyaratan versi minor.
`innodb_bulk_load_redo_compress_algorithm`	Menetapkan algoritma kompresi redo untuk bulk loading DDL. Nilai yang valid: `none` (Default) `lz4` `zstd`	MySQL 5.6: Tidak didukung MySQL 5.7: versi minor 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Tidak didukung MySQL 8.0.2: versi minor 8.0.2.2.30 atau lebih baru.
`innodb_bulk_load_redo_compress_enable`	Menetapkan target kompresi redo selama operasi DDL. Nilai yang valid: 0: none (Default) 1: secondary index 2: all	MySQL 5.6: Tidak didukung MySQL 5.7: versi minor 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Tidak didukung MySQL 8.0.2: versi minor 8.0.2.2.30 atau lebih baru.

Optimasi modul terkait

Dalam skenario BLOB throughput tinggi, bottleneck juga dapat terjadi di modul lain. Untuk mencapai kinerja 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: Berdasarkan sistem file terdistribusi yang dikembangkan sendiri oleh PolarDB, operasi ekstensi tablespace hanya memerlukan modifikasi sejumlah kecil metadata. Operasi zero-filling file native 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 kinerja

Data berikut menunjukkan peningkatan kinerja dalam skenario DML dan DDL setelah mengaktifkan optimasi BLOB.

Kinerja DML: Dalam skenario konkurensi tinggi dengan panjang baris 100 KB dan 200 KB, optimasi PolarDB meningkatkan kinerja insert dan update hampir 3x. Ketika dikombinasikan dengan kompresi redo, kinerja meningkat 4 hingga 5 kali lipat.
Kinerja DDL: Untuk tabel 40 GB yang berisi field BLOB, mengaktifkan optimasi ini meningkatkan laju penulisan DDL sebesar 5 hingga 6 kali lipat dan mengurangi total waktu eksekusi sebesar 84%.