Mengimpor data ke Amazon RDS untuk instans DB Amazon RDS for MariaDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Anda dapat menggunakan beberapa teknik untuk mengimpor data ke dalam instans basis data RDS for MariaDB. Pendekatan terbaik bergantung pada sumber data, jumlah data, dan apakah impor dilakukan satu kali atau berlanjut. Jika Anda turut memigrasikan aplikasi bersama data, pertimbangkan juga jumlah waktu henti yang bersedia Anda terima.

Tabel berikut mencantumkan teknik untuk mengimpor data ke RDS untuk instance MariaDB DB.

Impor pertimbangan data

Dalam konten berikut, Anda dapat menemukan informasi teknis tambahan terkait pemuatan data ke MariaDB. Informasi ini ditujukan untuk pengguna tingkat lanjut yang akrab dengan arsitektur server MariaDB.

Log biner

Beban data menimbulkan penalti performa dan memerlukan ruang disk kosong tambahan (hingga empat kali lebih banyak) jika log biner diaktifkan dibandingkan jika pemuatan data yang sama dengan log biner yang tidak diaktifkan. Keparahan penalti performa dan jumlah ruang disk kosong yang dibutuhkan berbanding lurus dengan ukuran transaksi yang digunakan untuk memuat data.

Ukuran transaksi

Ukuran transaksi memainkan peran penting dalam pemuatan data MariaDB. Ukuran ini memiliki pengaruh besar pada konsumsi sumber daya, pemanfaatan ruang disk, kelanjutan proses, waktu untuk pemulihan, dan format input (file rata atau SQL). Bagian ini menjelaskan bagaimana ukuran transaksi dapat memengaruhi log biner dan mengakibatkan kasus penonaktifan log biner selama pemuatan data yang besar. Sebagaimana disebutkan sebelumnya, log biner diaktifkan dan dinonaktifkan dengan mengatur periode retensi cadangan otomatis Amazon RDS. Nilai non-nol mengaktifkan log biner, dan nilai nol menonaktifkannya. Kami juga akan menjelaskan dampak transaksi yang besar pada InnoDB dan mengapa menjaga ukuran transaksi tetap kecil itu penting.

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 bergantung pada tingkat pengunggahan, aktivitas basis data lainnya yang terjadi selama pemuatan, dan kapasitas dari instans DB Amazon RDS Anda.

Log biner juga mengonsumsi ruang disk kira-kira setara dengan jumlah data yang dimuat sampai log dicadangkan dan dihapus. Untungnya, Amazon RDS meminimalkan hal ini dengan mencadangkan dan menghapus log biner secara rutin.

Transaksi besar

Transaksi besar menimbulkan penalti 3X untuk IOPS dan konsumsi disk dengan log biner diaktifkan. Tindakan ini dilakukan karena cache log biner tumpah ke disk, sehingga mengonsumsi ruang disk dan menimbulkan IO tambahan untuk setiap penulisan. Cache tidak dapat ditulis ke binlog hingga transaksi dipindahkan atau di-rollback, sehingga mengonsumsi ruang disk sebanding dengan jumlah data yang dimuat. Saat transaksi dipindahkan, cache harus disalin ke binlog, sehingga menciptakan salinan ketiga dari data pada disk.

Karenanya, harus ada ruang disk kosong setidaknya tiga kali ukuran data untuk memuat data dibandingkan jika memuat dengan log biner dinonaktifkan. Misalnya, 10 GiB data yang dimuat sebagai transaksi tunggal mengonsumsi setidaknya 30 GiB ruang disk selama pemuatan. Data akan mengonsumsi 10 GiB untuk tabel + 10 GiB untuk cache log biner + 10 GiB untuk log biner itu sendiri. File cache akan tetap berada pada disk hingga sesi yang menciptakannya berakhir atau sesi mengisi cache log biner lagi pada transaksi lain. Log biner harus tetap berada pada disk hingga pencadangan selesai, sehingga mungkin perlu waktu beberapa saat sebelum 20 GiB ekstra tersebut dibebaskan.

Jika data dimuat menggunakanLOAD DATA LOCAL INFILE, salinan data lain dibuat jika database harus dipulihkan dari cadangan yang dibuat sebelum pemuatan. Selama pemulihan, MariaDB mengekstrak data dari log biner ke file datar. MariaDB kemudian LOAD DATA LOCAL INFILE berjalan, seperti dalam transaksi asli. Akan tetapi, saat ini file input bersifat lokal bagi server basis data. Melanjutkan contoh sebelumnya, pemulihan gagal kecuali jika ada setidaknya 40 GiB ruang disk kosong yang tersedia.

Penonaktifan log biner

Jika memungkinkan, nonaktifkan log biner selama pemuatan data besar untuk menghindari kebutuhan overhead sumber daya dan ruang disk tambahan. Dalam Amazon RDS, penonaktifan log biner sesederhana mengatur periode retensi cadangan menjadi nol. Jika Anda melakukan ini, kami menyarankan agar Anda mengambil snapshot DB dari instans basis data sesaat sebelum pemuatan. Dengan melakukan ini, Anda dapat dengan cepat dan mudah membatalkan perubahan yang dibuat selama pemuatan jika Anda membutuhkannya.

Setelah pemuatan, atur periode retensi cadangan kembali ke nilai yang sesuai (bukan nol).

Anda tidak dapat mengatur periode retensi cadangan ke nol jika instans DB adalah instans DB sumber untuk replika baca.

InnoDB

Informasi dalam bagian ini menyediakan alasan yang kuat untuk menjaga ukuran transaksi tetap kecil saat menggunakan InnoDB.

Urungkan

InnoDB menghasilkan pembatalan untuk mendukung fitur seperti rollback dan MVCC transaksi. Pembatalan disimpan dalam tablespace sistem InnoDB (biasanya ibdata1) dan dipertahankan hingga dibuang oleh utas pembersihan. Utas pembersihan tidak dapat melangkahi pembatalan transaksi aktif terlama, sehingga secara efektif diblokir hingga transaksi dipindahkan atau menyelesaikan rollback. Jika basis data sedang memproses transaksi lain selama pemuatan, pembatalan juga terakumulasi dalam tablespace sistem dan tidak dapat dibuang meskipun transaksi dipindahkan dan tidak ada transaksi lain yang harus dibatalkan untuk MVCC. Dalam situasi ini, semua transaksi (termasuk transaksi hanya baca) yang mengakses baris mana pun yang diubah oleh transaksi apa pun (bukan hanya transaksi pemuatan) akan melambat. Pelambatan terjadi karena transaksi memindai melalui pembatalan yang seharusnya telah dibersihkan jika bukan karena transaksi pemuatan yang berjalan lama.

Pembatalan disimpan dalam tablespace sistem, dan tablespace sistem tidak pernah menyusut ukurannya. Karenanya, transaksi pemuatan data yang besar dapat menyebabkan tablespace sistem menjadi cukup besar, yang mengonsumsi ruang disk yang tidak dapat Anda klaim ulang tanpa menciptakan ulang basis data dari awal.

Rollback

InnoDB dioptimalkan untuk dipindahkan. Pelaksanaan rollback pada transaksi yang besar dapat memakan waktu yang sangat lama. Dalam beberapa kasus, mungkin lebih cepat untuk melakukan point-in-time pemulihan atau mengembalikan snapshot DB.

Format data input

MariaDB dapat menerima data yang masuk dalam salah satu dari dua bentuk: file datar dan SQL. Bagian ini menjelaskan beberapa keuntungan dan kerugian utama dari masing-masing faktor.

File rata

Memuat file datar dengan LOAD DATA LOCAL INFILE dapat menjadi metode pemuatan data tercepat dan paling murah selama transaksi disimpan relatif kecil. Dibandingkan dengan pemuatan data yang sama dengan SQL, file rata biasanya membutuhkan lebih sedikit lalu lintas jaringan, yang mengurangi biaya transmisi, dan memuat lebih cepat karena pengurangan overhead dalam basis data.

Satu transaksi besar

LOAD DATA LOCAL INFILEmemuat seluruh file datar sebagai satu transaksi. Ini bukan hal yang buruk. Jika ukuran masing-masing file dapat dijaga tetap kecil, ada sejumlah keuntungan:

Berhati-hatilah

Keuntungan LOAD DATA LOCAL INFILE berkurang dengan cepat seiring dengan meningkatnya ukuran transaksi. Jika membagi sejumlah data yang besar menjadi data yang lebih kecil bukanlah opsi yang tepat, SQL dapat menjadi pilihan yang lebih baik.

SQL

SQL memiliki satu keuntungan utama dibandingkan file rata: kemudahannya untuk menjaga ukuran transaksi tetap kecil. Akan tetapi, SQL dapat memakan waktu yang jauh lebih lama untuk memuat dibandingkan file rata dan sulit untuk menentukan di mana pemuatan dapat dilanjutkan setelah sebuah kegagalan. Misalnya, mariadb-dump file tidak dapat dimulai ulang. Jika terjadi kegagalan saat memuat mariadb-dump file, file memerlukan modifikasi atau penggantian sebelum pemuatan dapat dilanjutkan. Alternatifnya adalah pemulihan pada titik waktu sebelum pemuatan dan pemutaran ulang file setelah penyebab kegagalan diperbaiki.

Pengambilan titik pemeriksaan menggunakan snapshot Amazon RDS

Jika Anda memiliki pemuatan yang akan memakan waktu berjam-jam atau bahkan berhari-hari, pemuatan tanpa log biner bukanlah sebuah prospek yang sangat menarik kecuali Anda dapat melakukan titik pemeriksaan secara berkala. Di sinilah fitur snapshot DB Amazon RDS menjadi sangat berguna. Snapshot DB membuat salinan point-in-time konsisten dari instance database Anda yang dapat digunakan mengembalikan database ke titik waktu itu setelah crash atau kecelakaan lainnya.

Untuk menciptakan sebuah titik pemeriksaan, ambil sebuah snapshot DB saja. Snapshot DB sebelumnya yang diambil untuk titik pemeriksaan dapat dibuang tanpa memengaruhi durabilitas atau waktu pemulihan.

Snapshot juga cepat, sehingga titik pemeriksaan yang sering tidak menambah waktu pemuatan secara signifikan.

Pengurangan waktu pemuatan

Berikut ini adalah beberapa tips tambahan untuk mengurangi waktu pemuatan: