Optimalisasi Kinerja BLOB - PolarDB - Alibaba Cloud Documentation Center

Menulis Binary Large Objects (BLOB) di MySQL dalam kondisi konkurensi tinggi dapat menyebabkan masalah kinerja seperti perebutan kunci dan hambatan log redo. PolarDB for MySQL mengatasi tantangan ini melalui optimalisasi tingkat kernel yang meningkatkan seluruh siklus hidup data BLOB, termasuk penulisan, pembaruan, dan pengelolaan ruang. Fitur-fitur ini secara signifikan meningkatkan kinerja operasi Data Manipulation Language (DML) dan Data Definition Language (DDL), memastikan aplikasi Anda berjalan efisien di bawah beban kerja konkurensi tinggi.

Cara kerjanya

BLOB adalah tipe data yang digunakan untuk menyimpan objek besar seperti gambar, dokumen, atau teks panjang. Pada engine InnoDB MySQL asli, ketika sebuah BLOB melebihi ukuran tertentu, ia disimpan pada halaman data eksternal terpisah (off-pages). Mekanisme ini menciptakan tiga tantangan kinerja utama:

Hambatan Tulis Konkuren: Memperbarui off-page BLOB memicu kunci pesimistis. Ini hanya memungkinkan satu thread untuk melakukan penulisan BLOB pada satu tabel dalam satu waktu, yang sangat membatasi konkurensi.
Tekanan I/O Meningkat: Bidang objek besar menghasilkan log redo yang besar. Jika disk I/O tidak cukup, flushing log menjadi hambatan dan memblokir penulisan latar depan.
Pengembalian Ruang Tertunda: Pembersihan (Purge) data BLOB lama tidak efisien. Hal ini dapat menyebabkan pembengkakan ruang penyimpanan dan penurunan kinerja.

PolarDB menyelesaikan masalah-masalah ini di tingkat kernel tanpa mengubah cara aplikasi Anda menggunakan BLOB. Diagram berikut menggambarkan cara kerjanya:

Penagihan

Fitur optimalisasi kinerja BLOB terintegrasi ke dalam kernel PolarDB dan tidak dikenakan biaya.

Optimalkan kinerja penulisan BLOB

Jika Anda mengalami hambatan throughput tulis atau latensi tinggi untuk penulisan konkuren pada tabel BLOB selama jam sibuk bisnis, penyebabnya biasanya adalah perebutan kunci tulis. PolarDB menyediakan alokasi halaman awal dan optimasi kunci indeks untuk menyelesaikan masalah ini.

Halaman pra-alokasi

Optimasi ini memecah proses penulisan BLOB menjadi langkah-langkah yang lebih cepat dan konkuren:

Hitung dan minta semua halaman data yang diperlukan dalam satu batch.
Salin data tanpa kunci dan isi halaman yang baru dialokasikan dengan konten BLOB.
Lampirkan rantai halaman data yang dihasilkan ke catatan indeks menggunakan satu operasi kunci optimis.

Selama proses ini, hanya fase alokasi ruang awal yang eksklusif. Operasi penyalinan data yang memakan waktu dapat berjalan paralel dengan penulisan BLOB lainnya. Desain ini meminimalkan waktu kunci global dipegang, secara dramatis meningkatkan throughput tulis konkuren.

Optimasi kunci indeks

Untuk tabel dengan BLOB kecil (di bawah 8 KB) atau ukuran campuran, MySQL asli sering meninggalkan kunci optimis terlalu dini selama pembaruan dan jatuh kembali ke kunci pesimistis yang tidak efisien. Optimasi kunci memecahkan ini dengan melakukan lebih banyak pekerjaan pada jalur optimis.

Mempertahankan Jalur Optimis: Ketika sistem mendeteksi bahwa bidang BLOB mungkin perlu diperbarui, logika optimasi tidak segera beralih ke kunci pesimistis. Sebagai gantinya, ia tetap memegang kunci bersama (S-latch), yang memiliki probabilitas konflik lebih rendah, dan tetap berada di jalur pembaruan optimis.
Prabangun dan Coba Perbarui: Di jalur optimis, ia prabangun struktur data BLOB yang diperlukan untuk pembaruan dan mencoba memodifikasi halaman indeks secara langsung.
Periksa dan Komit atau Rollback:
- Berhasil: Jika catatan yang diperbarui sesuai pada halaman indeks saat ini, operasi selesai dengan cepat di jalur optimis.
- Gagal: Jika halaman memiliki ruang yang tidak mencukupi, optimasi secara otomatis menyerah dari upaya tersebut. Kemudian ia kembali tanpa gangguan ke jalur kunci pesimistis MySQL asli untuk menyelesaikan operasi pembaruan, yang memastikan konsistensi data.

Mekanisme ini secara signifikan meningkatkan tingkat keberhasilan pembaruan optimis, meningkatkan throughput untuk beban kerja BLOB ukuran campuran di bawah konkurensi tinggi.

Aktifkan optimasi tulis

Untuk mengaktifkan optimasi, buka halaman Configurations And Management > Parameter Settings di Konsol PolarDB untuk melihat dan memodifikasi parameter berikut:

Parameter	Deskripsi	Versi yang didukung
`innodb_blob_prepare_pages`	Mengaktifkan atau menonaktifkan optimasi alokasi halaman BLOB. Nilai valid: ON: diaktifkan OFF: dinonaktifkan	MySQL 5.6: Tidak didukung. MySQL 5.7: Versi mesin minor harus 5.7.1.0.35 atau lebih baru. MySQL 8.0.1: Versi mesin minor harus 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 untuk optimasi alokasi halaman BLOB.
`innodb_blob_latch_optimize`	Mengaktifkan atau menonaktifkan optimasi kunci indeks BLOB.

Kurangi volume redo log untuk penulisan BLOB

Jika aplikasi Anda menulis sejumlah besar data BLOB dan laju pembuatan redo log menjadi hambatan I/O, Anda dapat mengaktifkan kompresi redo untuk mengurangi tekanan I/O.

Fitur ini mengompresi catatan redo log untuk BLOB secara paralel sebelum ditulis ke buffer log. Ini dapat mengurangi volume aktual redo log yang ditulis ke disk rata-rata sebesar 40%-60%, yang menurunkan tekanan I/O dan mencegah modul redo memengaruhi kinerja tulis keseluruhan. Log akan secara otomatis didekompresi selama pemulihan crash database.

Aktifkan kompresi redo

Untuk mengaktifkan optimasi, buka halaman Configurations And Management > Parameter Settings di Konsol PolarDB untuk melihat dan memodifikasi parameter berikut:

Parameter

Deskripsi

Versi yang didukung

innodb_blob_redo_compress_algorithm

Menetapkan algoritma kompresi untuk redo log BLOB. Nilai valid:

none (default)
lz4
zstd
zlib

MySQL 5.6: Tidak didukung.
MySQL 5.7: Versi mesin minor harus 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 kompresi yang dipilih.

Nilai berkisar dari 0 hingga 9. Nilai default adalah 6.

Percepat relokasi ruang BLOB

Jika ruang tabel Anda terus bertambah meskipun Anda sering menghapus atau memperbarui data BLOB, penyebabnya adalah proses Purge latar belakang yang tidak efisien di MySQL asli. Proses Purge asli memegang kunci inti sambil melakukan potensi lambat disk I/O untuk membaca halaman BLOB. PolarDB memisahkan kedua operasi ini untuk memecahkan hambatan ini.

Identifikasi Halaman Target: Sebelum mengunci dan memulai pembersihan, proses Purge pertama-tama mengidentifikasi rantai halaman eksternal BLOB lengkap yang perlu direklamasi.
Prabaca Asinkron: Ini memulai permintaan I/O asinkron untuk memuat halaman target yang belum ada di memori dari disk ke dalam kolam buffer.
Pembersihan Cepat: Setelah semua halaman dimuat ke memori, proses Purge memperoleh kunci inti, seperti Index SX. Kemudian dengan cepat melakukan pelepasan halaman dalam memori dan modifikasi metadata.

Mekanisme ini menghindari melakukan disk I/O apa pun saat memegang kunci penting. Ini secara dramatis mempersingkat waktu pegang kunci, yang tidak hanya meningkatkan efisiensi reklamasi data BLOB tetapi juga mengurangi dampak pembersihan latar belakang pada operasi latar depan.

Aktifkan Purge pre-read

Untuk mengaktifkan optimasi, buka halaman Configurations And Management > Parameter Settings di Konsol PolarDB untuk melihat dan memodifikasi parameter berikut:

Parameter

Deskripsi

Versi yang didukung

innodb_purge_blob_read_ahead

Mengaktifkan atau menonaktifkan optimasi prabaca halaman untuk proses Purge BLOB.

Nilai valid:

ON: diaktifkan
OFF: dinonaktifkan

Didukung di semua versi.

Tingkatkan kecepatan eksekusi DDL

Jika operasi ALTER TABLE pada tabel dengan jumlah besar data BLOB terlalu lambat, Anda dapat mengaktifkan optimasi BLOB spesifik DDL untuk secara signifikan mengurangi waktu eksekusi.

Optimasi Alokasi Halaman Pra-Penyediaan: Karena kolom overflow BLOB merupakan bagian dari tabel utama, operasi DDL yang membangun ulang tabel utama juga melibatkan penulisan bidang BLOB. Optimasi alokasi halaman pra-penyediaan menggunakan metode penguncian yang lebih langsung dan disederhanakan untuk menulis data BLOB. Ini menghindari overhead menangani konflik konkurensi kompleks dan secara signifikan meningkatkan efisiensi pembangunan ulang.
Optimasi Kunci: DDL paralel membagi pohon kunci utama, sehingga beberapa thread pekerja tidak beroperasi pada halaman data yang sama. Optimasi ini melindungi operasi alokasi halaman baru secara independen, yang memungkinkan operasi lain berjalan secara konkuren dan meningkatkan efisiensi.
Optimisasi Ulang:
1. Aggregasi Halaman: Selama pemuatan massal data, alih-alih menghasilkan redo log untuk setiap rekaman, sistem menulis perubahan seluruh halaman data sebagai satu redo record besar setelah halaman penuh. Ini meningkatkan efisiensi operasi redo.
2. Kompresi Agregasi: Sistem mengompresi redo record besar yang teragregasi untuk lebih mengurangi jumlah redo log yang dihasilkan selama proses DDL.

Aktifkan optimasi DDL

Untuk mengaktifkan optimasi, buka halaman Configurations And Management > Parameter Settings di Konsol PolarDB untuk melihat dan memodifikasi parameter berikut:

Catatan

Beberapa parameter dalam tabel berikut tidak dapat dimodifikasi secara manual. Untuk mengubah parameter ini, ajukan tiket untuk menghubungi kami.

Parameter	Deskripsi	Versi yang Didukung
`innodb_blob_prepare_pages_in_ddl`	Menentukan apakah akan mengaktifkan optimasi objek besar selama proses DDL. Nilai valid: OFF (default) ON	MySQL 5.6: Tidak didukung. MySQL 5.7: Versi mesin minor harus 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Versi mesin minor harus 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 proses DDL. Nilai valid: OFF (default) ON	MySQL 5.6: Tidak didukung. MySQL 5.7: Versi mesin minor harus 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Versi mesin minor harus 8.0.1.1.47 atau lebih baru. MySQL 8.0.2: Versi mesin minor harus 8.0.2.2.30 atau lebih baru.
`innodb_bulk_load_page_grained_redo_enable`	Menentukan apakah akan mengaktifkan agregasi redo halaman selama pemuatan massal DDL. Nilai valid: OFF ON (default)	MySQL 5.6: Tidak didukung. MySQL 5.7: Didukung. Tidak ada batasan versi mesin minor. MySQL 8.0.1: Didukung. Tidak ada batasan versi mesin minor. MySQL 8.0.2: Didukung. Tidak ada batasan versi mesin minor.
`innodb_bulk_load_redo_compress_algorithm`	Menetapkan algoritma kompresi redo untuk pemuatan massal DDL. Nilai valid: `none` (default) `lz4` `zstd`	MySQL 5.6: Tidak didukung. MySQL 5.7: Versi mesin minor harus 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Tidak didukung. MySQL 8.0.2: Versi mesin minor harus 8.0.2.2.30 atau lebih baru.
`innodb_bulk_load_redo_compress_enable`	Menetapkan target aplikasi untuk kompresi redo selama proses DDL. Nilai valid: 0: none (default) 1: indeks sekunder 2: semua	MySQL 5.6: Tidak didukung MySQL 5.7: Versi mesin minor harus 5.7.1.0.39 atau lebih baru. MySQL 8.0.1: Tidak didukung MySQL 8.0.2: Versi mesin minor harus 8.0.2.2.30 atau lebih baru.

Optimasi sistem terkait

Untuk mencapai kinerja terbaik, PolarDB juga mengoptimalkan modul sistem terkait yang dapat menjadi hambatan dalam skenario BLOB throughput tinggi:

Tulisan Redo Asinkron Paralel: Sistem membagi data di buffer redo dan menggunakan beberapa thread untuk mengeluarkan tugas I/O asinkron secara bersamaan. Ini sangat meningkatkan throughput tulis log redo, mencapai hingga 4 GB/detik dalam pengujian.
Optimasi Ekstensi File: Berdasarkan sistem file terdistribusi yang dikembangkan sendiri oleh PolarDB, operasi ekstensi ruang tabel hanya perlu memodifikasi sejumlah kecil metadata. Operasi zero-filling file asli dihapus, sehingga waktu dan overhead kunci dari ekstensi file tidak lagi menjadi hambatan.
Pembersihan Halaman Kotor Tanpa Kunci: Sistem menggunakan teknologi Shadow Page. Saat membersihkan halaman kotor, ia pertama-tama membangun salinan dalam memori, melepaskan kunci halaman, dan kemudian menggunakan salinan untuk operasi I/O. Ini menghindari pemblokiran permintaan tulis dengan memegang kunci halaman selama pembersihan halaman kotor.

Data 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, solusi optimalisasi PolarDB untuk insert dan update memberikan peningkatan kinerja hampir tiga kali lipat. Ketika digabungkan dengan kompresi redo, kinerja dapat ditingkatkan empat hingga lima kali lipat.
Kinerja DDL Untuk tabel 40 GB yang berisi bidang BLOB, laju tulis DDL meningkat 5 hingga 6 kali lipat dan total waktu eksekusi berkurang 84% setelah optimasi diaktifkan.