Mengimpor pertimbangan data untuk MariaDB

Konten berikut berisi informasi teknis terkait pemuatan data ke MariaDB. Konten ini ditujukan untuk pengguna yang akrab dengan arsitektur server MariaDB.

Pencatatan biner

Mengaktifkan pencatatan biner mengurangi kinerja pemuatan data dan membutuhkan hingga empat kali ruang disk tambahan dibandingkan dengan pencatatan yang dinonaktifkan. Ukuran transaksi yang digunakan untuk memuat data secara langsung mempengaruhi kinerja sistem dan kebutuhan ruang disk — transaksi yang lebih besar membutuhkan lebih banyak sumber daya.

Ukuran transaksi

Ukuran transaksi mempengaruhi aspek-aspek berikut dari pemuatan data MariaDB:

• Konsumsi sumber daya

• Pemanfaatan ruang disk

• Lanjutkan proses

• Waktu untuk pulih

• Format input (file datar atau SQL)

Bagian ini menjelaskan bagaimana ukuran transaksi dapat memengaruhi log biner dan mengakibatkan kasus penonaktifan log biner selama pemuatan data yang besar. Anda dapat mengaktifkan dan menonaktifkan pencatatan biner dengan mengatur periode retensi cadangan otomatis Amazon RDS. Nilai non-nol mengaktifkan log biner, dan nilai nol menonaktifkannya. Untuk informasi selengkapnya, lihat Periode retensi cadangan.

Bagian ini juga menjelaskan dampak transaksi besar pada InnoDB dan mengapa penting untuk menjaga ukuran transaksi tetap kecil.

Transaksi kecil

Untuk transaksi kecil, log biner menggandakan jumlah tulis disk yang dibutuhkan untuk memuat data. Efek ini dapat secara ekstrem menurunkan performa untuk sesi basis data lain dan meningkatkan waktu yang dibutuhkan untuk memuat data. Degradasi yang dialami sebagian tergantung pada faktor-faktor berikut:

• Tingkat unggah

• Aktivitas database lainnya yang terjadi selama pemuatan

• Kapasitas instans Amazon RDS DB Anda

Log biner juga mengkonsumsi ruang disk kira-kira sama dengan jumlah data yang dimuat sampai log dicadangkan dan dihapus. Amazon RDS meminimalkan ini dengan sering mencadangkan dan menghapus log biner.

Transaksi besar

Untuk transaksi besar, pencatatan biner melipatgandakan IOPS dan penggunaan disk karena alasan berikut:

• Cache log biner menyimpan data transaksi sementara pada disk.

• Cache ini tumbuh dengan ukuran transaksi, yang menghabiskan ruang disk.

• Ketika transaksi (commit atau rollback) selesai, sistem menyalin cache ke log biner.

Proses ini membuat tiga salinan data:

• Data asli

• Cache pada disk

• Entri log biner terakhir

Setiap operasi penulisan menimbulkan IO tambahan, yang selanjutnya memengaruhi kinerja.

Karena itu, logging biner membutuhkan tiga kali lipat ruang disk dibandingkan dengan logging yang dinonaktifkan. Misalnya, memuat 10 GiB data sebagai satu transaksi menghasilkan tiga salinan:

• 10 GiB untuk data tabel

• 10 GiB untuk cache log biner

• 10 GiB untuk file log biner

Total ruang disk sementara yang dibutuhkan adalah 30 GiB.

Pertimbangan ruang disk penting:

• File cache tetap ada sampai sesi berakhir atau transaksi baru membuat cache lain.

• Log biner tetap ada sampai dicadangkan, berpotensi menahan 20 GiB (cache dan log) untuk waktu yang lama.

Jika Anda menggunakan LOAD DATA LOCAL INFILE untuk memuat data, pemulihan data membuat salinan keempat jika database harus dipulihkan dari cadangan yang dibuat sebelum pemuatan. Selama pemulihan, MariaDB mengekstrak data dari log biner ke file datar. MariaDB kemudian berjalan. LOAD DATA LOCAL INFILE Berdasarkan contoh sebelumnya, pemulihan ini membutuhkan total ruang disk sementara 40 GiB, atau masing-masing 10 GiB untuk tabel, cache, log, dan file lokal. Tanpa setidaknya 40 GiB ruang disk kosong, pemulihan gagal.

Mengoptimalkan beban data yang besar

Untuk pemuatan data yang besar, nonaktifkan pencatatan biner untuk mengurangi kebutuhan ruang overhead dan disk. Anda dapat menonaktifkan pencatatan biner dengan mengatur periode retensi cadangan ke 0. Setelah pemuatan selesai, kembalikan periode retensi cadangan ke nilai bukan nol yang sesuai. Untuk informasi selengkapnya, lihat Memodifikasi instans Amazon RDS DB dan Periode retensi cadangan di tabel pengaturan.

catatan

Jika instans DB adalah instans DB sumber untuk replika baca, maka Anda tidak dapat mengatur periode retensi cadangan ke 0.

Sebelum memuat data, kami sarankan Anda membuat snapshot DB. Untuk informasi selengkapnya, lihat Mengelola backup manual.

InnoDB

Informasi berikut tentang opsi undo logging dan recovery mendukung menjaga transaksi InnoDB tetap kecil untuk mengoptimalkan kinerja database.

Memahami InnoDB undo logging

Undo adalah mekanisme logging yang memungkinkan rollback transaksi dan mendukung kontrol konkurensi multi-versi (MVCC).

Untuk MariaDB 10.11 dan versi yang lebih rendah, batalkan log disimpan di tablespace sistem InnoDB (biasanya ibdata1) dan dipertahankan sampai thread pembersihan menghapusnya. Akibatnya, transaksi pemuatan data yang besar dapat menyebabkan tablespace sistem menjadi cukup besar dan menghabiskan ruang disk yang tidak dapat Anda reklamasi kecuali Anda membuat ulang database.

Untuk semua versi MariaDB, thread pembersihan harus menunggu untuk menghapus log pembatalan apa pun hingga transaksi aktif tertua melakukan atau memutar kembali. Jika database memproses transaksi lain selama pemuatan, log pembatalan mereka juga terakumulasi dan tidak dapat dihapus, bahkan jika transaksi dilakukan dan tidak ada transaksi lain yang memerlukan log pembatalan untuk MVCC. Dalam situasi ini, semua transaksi—termasuk transaksi hanya-baca—melambat. Perlambatan ini terjadi karena semua transaksi mengakses semua baris yang transaksi—bukan hanya transaksi muatan—berubah. Akibatnya, transaksi harus memindai melalui log undo yang mencegah transaksi pemuatan yang berjalan lama dicegah untuk dibersihkan selama pembersihan log batal. Ini memengaruhi kinerja untuk setiap operasi yang mengakses baris yang dimodifikasi.

Opsi pemulihan transaksi InnoDB

Meskipun InnoDB mengoptimalkan operasi komit, rollback transaksi besar lambat. Untuk pemulihan yang lebih cepat, lakukan point-in-time pemulihan atau pulihkan snapshot DB. Untuk informasi selengkapnya, lihat Point-in-time pemulihan dan Memulihkan ke instans DB.

Format impor data

MariaDB mendukung dua format impor data: file datar dan SQL. Tinjau informasi tentang setiap format untuk menentukan opsi terbaik untuk kebutuhan Anda.

File rata

Untuk transaksi kecil, muat file datar denganLOAD DATA LOCAL INFILE. Format impor data ini dapat memberikan manfaat berikut dibandingkan menggunakan SQL:

• Lebih sedikit lalu lintas jaringan

• Biaya transmisi data yang lebih rendah

• Overhead pemrosesan basis data menurun

• Pemrosesan lebih cepat

LOAD DATA LOCAL INFILEmemuat seluruh file datar sebagai satu transaksi. Jaga ukuran masing-masing file kecil untuk keuntungan berikut:

• Kemampuan melanjutkan - Anda dapat melacak file mana yang telah dimuat. Jika masalah muncul selama beban, Anda dapat mengambil tempat yang Anda tinggalkan. Anda mungkin perlu mengirimkan kembali beberapa data ke Amazon RDS, tetapi dengan file kecil, jumlah yang dikirim ulang minimal.

• Pemuatan data paralel — Jika Anda memiliki IOPS dan bandwidth jaringan yang cukup untuk satu pemuatan file, pemuatan secara paralel dapat menghemat waktu.

• Kontrol laju beban - Jika beban data Anda berdampak negatif pada proses lain, Anda dapat mengontrol laju beban dengan meningkatkan interval antar file.

Transaksi besar mengurangi manfaat penggunaan LOAD DATA LOCAL INFILE untuk mengimpor data. Bila Anda tidak dapat memecah sejumlah besar data menjadi file yang lebih kecil, pertimbangkan untuk menggunakan SQL.

SQL

SQL memiliki satu keunggulan utama dibandingkan file datar: Anda dapat dengan mudah menjaga ukuran transaksi kecil. Namun, SQL dapat memakan waktu lebih lama untuk memuat daripada file datar. Juga, setelah kegagalan, mungkin sulit untuk menentukan di mana harus melanjutkan—Anda tidak dapat me-restart file mariadb-dump. Jika terjadi kegagalan saat memuat file mariadb-dump, Anda harus memodifikasi atau mengganti file sebelum pemuatan dapat dilanjutkan. Atau, sebagai alternatif, setelah Anda memperbaiki penyebab kegagalan, Anda dapat mengembalikan ke titik waktu sebelum memuat dan mengirim ulang file. Untuk informasi selengkapnya, lihat Point-in-time pemulihan.

Menggunakan snapshot Amazon RDS DB untuk pos pemeriksaan database

Jika Anda memuat data dalam jangka waktu yang lama—seperti jam atau hari—tanpa pencatatan biner, gunakan snapshot DB untuk menyediakan pos pemeriksaan berkala demi keamanan data. Setiap snapshot DB membuat salinan konsisten dari instance database Anda yang berfungsi sebagai titik pemulihan selama kegagalan sistem atau peristiwa korupsi data. Karena snapshot DB cepat, checkpointing yang sering memiliki dampak minimal pada kinerja beban. Anda dapat menghapus snapshot DB sebelumnya tanpa memengaruhi daya tahan database atau kemampuan pemulihan. Untuk informasi selengkapnya tentang snapshot DB, lihatMengelola backup manual.

Mengurangi waktu muat database

Item berikut adalah tips tambahan untuk mengurangi waktu muat:

• Buat semua indeks sekunder sebelum memuat data ke database MariaDB. Tidak seperti sistem database lainnya, MariaDB membangun kembali seluruh tabel saat menambahkan atau memodifikasi indeks sekunder. Proses ini membuat tabel baru dengan perubahan indeks, menyalin semua data, dan menjatuhkan tabel asli.

• Muat data dalam urutan kunci primer. Untuk tabel InnoDB, ini dapat mengurangi waktu muat hingga 75% — 80% dan mengurangi ukuran file data hingga 50%.

• Nonaktifkan kendala kunci asing dengan menyetel ke. foreign_key_checks 0 Ini sering diperlukan untuk file datar yang dimuatLOAD DATA LOCAL INFILE. Untuk beban apa pun, menonaktifkan pemeriksaan kunci asing mempercepat pemuatan data. Setelah pemuatan selesai, aktifkan kembali kendala dengan mengatur foreign_key_checks dan memverifikasi data. 1

• Muat data secara paralel kecuali mendekati batas sumber daya. Untuk mengaktifkan pemuatan bersamaan di beberapa segmen tabel, gunakan tabel yang dipartisi bila sesuai.

• Untuk mengurangi overhead eksekusi SQL, gabungkan beberapa INSERT pernyataan menjadi operasi INSERT multi-nilai tunggal. mariadb-dumpmengimplementasikan optimasi ini secara otomatis.

• Kurangi operasi IO log InnoDB dengan menyetel innodb_flush_log_at_trx_commit ke. 0 Setelah pemuatan selesai, kembalikan innodb_flush_log_at_trx_commit ke1.

  Awas

  Pengaturan innodb_flush_log_at_trx_commit untuk 0 menyebabkan InnoDB menyiram lognya setiap detik, bukan di setiap komit. Pengaturan ini meningkatkan kinerja tetapi dapat mengambil risiko kerugian transaksi selama kegagalan sistem.

• Jika Anda memuat data ke instans DB yang tidak memiliki replika baca, setel sync_binlog ke0. Setelah pemuatan selesai, kembalikan sync_binlog parameter ke1.

• Muat data ke instans DB AZ tunggal sebelum mengonversi instans DB menjadi penerapan Multi-AZ. Jika instans DB sudah menggunakan penerapan Multi-AZ, kami tidak menyarankan untuk beralih ke penerapan AZ tunggal untuk pemuatan data. Melakukannya hanya memberikan perbaikan marjinal