AnalyticDB for MySQL menyediakan berbagai metode impor data untuk skenario yang berbeda. Namun, berbagai faktor dapat memengaruhi kinerja impor data. Misalnya, skema tabel yang buruk dapat menyebabkan tugas long-tail, dan konfigurasi impor yang rendah dapat menyebabkan pemanfaatan sumber daya yang tidak efisien. Topik ini menjelaskan cara mengoptimalkan kinerja impor data dalam berbagai skenario.
Mengoptimalkan impor data dari tabel eksternal
Periksa kunci distribusi
Kunci distribusi menentukan partisi hash untuk impor data. Data diimpor ke setiap tabel secara konkuren pada tingkat partisi hash. Jika data tidak didistribusikan secara merata, partisi hash yang berisi lebih banyak data akan menjadi node long-tail, sehingga menurunkan kinerja seluruh tugas impor. Oleh karena itu, Anda harus memastikan bahwa data didistribusikan secara merata selama impor. Untuk informasi selengkapnya tentang cara memilih kunci distribusi, lihat Memilih kunci distribusi.
Untuk menentukan apakah kunci distribusi sesuai, pertimbangkan poin-poin berikut:
Sebelum impor, tentukan apakah kunci distribusi yang dipilih sesuai berdasarkan konteks bisnis. Misalnya, pada tabel Lineitem, jika Anda memilih kolom l_discount sebagai kunci distribusi, nilai diskon pesanan hanya memiliki kardinalitas rendah dengan 11 nilai unik. Data dengan nilai l_discount yang sama didistribusikan ke partisi yang sama. Hal ini menyebabkan kesenjangan data yang parah dan menciptakan tugas long-tail, sehingga menurunkan kinerja. Kolom l_orderkey merupakan pilihan yang lebih baik karena ID pesanan bersifat unik, yang memastikan data didistribusikan lebih merata.
Setelah impor, jika diagnostik pemodelan data menunjukkan adanya kesenjangan data pada bidang distribusi, maka kunci distribusi yang dipilih menyebabkan distribusi data yang tidak merata. Untuk informasi selengkapnya tentang cara melihat diagnostik kunci distribusi, lihat Diagnostik penyimpanan.
Periksa kunci partisi
Pernyataan INSERT OVERWRITE SELECT menimpa partisi. Artinya, subpartisi yang diimpor menggantikan subpartisi yang sudah ada dengan nama yang sama di tabel target. Di dalam setiap partisi hash, data diimpor ke subpartisinya masing-masing. Hindari mengimpor terlalu banyak subpartisi sekaligus. Mengimpor beberapa subpartisi secara bersamaan dapat memicu proses pengurutan eksternal, yang menurunkan kinerja impor. Untuk informasi selengkapnya tentang cara memilih kunci partisi, lihat Memilih kunci partisi.
Untuk menentukan apakah kunci partisi sesuai, pertimbangkan poin-poin berikut:
Sebelum impor, tentukan apakah kunci partisi sesuai berdasarkan kebutuhan dan distribusi data Anda. Misalnya, jika Anda membuat subpartisi pada tabel Lineitem berdasarkan kolom l_shipdate dan rentang waktu mencakup tujuh tahun, melakukan partisi berdasarkan tahun akan menghasilkan 7 subpartisi. Melakukan partisi berdasarkan hari akan menghasilkan lebih dari 2.000 subpartisi, dengan masing-masing subpartisi berisi sekitar 30 juta catatan. Dalam kasus ini, melakukan partisi berdasarkan bulan atau tahun lebih tepat.
Setelah impor, jika diagnostik pemodelan data menunjukkan bahwa subpartisi tidak masuk akal, maka kunci partisi yang dipilih tidak sesuai. Untuk informasi selengkapnya tentang cara melihat diagnostik kunci partisi, lihat Diagnostik tabel terpartisi.
Periksa indeks
Secara default, AnalyticDB for MySQL mengindeks semua kolom saat Anda membuat tabel. Membuat indeks untuk semua kolom pada tabel lebar menghabiskan sumber daya yang signifikan. Saat Anda mengimpor data ke tabel lebar, pertimbangkan untuk hanya menggunakan indeks kunci primer. Indeks kunci primer digunakan untuk menghapus duplikat. Menggunakan terlalu banyak kolom kunci primer dapat menurunkan kinerja deduplikasi. Untuk informasi selengkapnya tentang cara memilih kunci primer, lihat Memilih kunci primer.
Untuk menentukan apakah indeks sesuai, pertimbangkan poin-poin berikut:
Dalam skenario impor offline, data biasanya telah dideduplikasi oleh komputasi offline. Anda tidak perlu menentukan indeks kunci primer.
Pada tab , Anda dapat melihat jumlah data tabel, data indeks, dan data indeks kunci primer. Jika jumlah data indeks lebih besar daripada jumlah data tabel, periksa kolom-kolom yang berisi string panjang. Membuat indeks pada kolom-kolom tersebut memakan waktu lama dan menghabiskan ruang penyimpanan yang besar. Anda dapat menghapus indeks tersebut. Untuk informasi selengkapnya, lihat ALTER TABLE.
CatatanAnda tidak dapat menghapus indeks kunci primer. Anda harus membuat ulang tabel tersebut.
Tambahkan petunjuk untuk mempercepat impor
Anda dapat menambahkan petunjuk (direct_batch_load=true) sebelum tugas impor untuk mempercepatnya.
Petunjuk ini hanya didukung oleh kluster Edisi Gudang Data dalam mode elastis yang menjalankan versi 3.1.5. Jika kinerja impor tidak meningkat secara signifikan setelah Anda menggunakan petunjuk ini, Submit a ticket.
Contoh:
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;Gunakan fitur impor elastis untuk mempercepat impor
Fitur impor elastis hanya didukung pada kluster yang menjalankan kernel versi 3.1.10.0 atau lebih baru.
Fitur impor elastis didukung pada kluster Edisi Perusahaan, Edisi Dasar, dan Edisi Data Lakehouse yang telah membuat kelompok sumber daya Pekerjaan.
Impor elastis hanya mendukung impor data MaxCompute dan data OSS yang disimpan dalam format CSV, Parquet, atau ORC.
Saat menggunakan fitur impor elastis untuk mempercepat impor, pastikan kelompok sumber daya Pekerjaan memiliki sumber daya yang cukup. Hal ini membantu mencegah masalah seperti waktu tunggu yang lama, durasi tugas yang panjang, dan kegagalan tugas akibat kekurangan sumber daya.
Impor elastis mendukung menjalankan beberapa tugas impor elastis secara konkuren. Anda juga dapat mempercepat satu tugas impor elastis dengan meningkatkan alokasi sumber dayanya. Untuk informasi selengkapnya, lihat Metode impor data.
Contoh:
/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;Untuk informasi selengkapnya tentang parameter, lihat Parameter petunjuk.
Mengoptimalkan impor data dari DataWorks
Mengoptimalkan konfigurasi tugas
Optimalkan Number of records per batch insert
Parameter ini menentukan ukuran batch untuk satu impor. Nilai default adalah 2.048. Kami tidak menyarankan mengubah nilai ini.
Jika satu catatan berukuran besar, misalnya beberapa ratus KB hingga 512 KB, Anda dapat mengubah pengaturan ini menjadi 16. Perubahan ini memastikan bahwa setiap impor batch tidak melebihi 8 MB dan membantu mencegah penggunaan memori yang tinggi pada node frontend.
Optimalkan Channel Control
Kinerja sinkronisasi data sebanding dengan nilai Maximum Concurrency. Anda dapat meningkatkan nilai Maximum Concurrency sebanyak mungkin.
PentingNilai Konkurensi Maksimum yang lebih tinggi mengonsumsi lebih banyak sumber daya DataWorks. Pilih nilai berdasarkan kebutuhan Anda.
Anda dapat mengaktifkan Distributed Execution untuk kinerja sinkronisasi yang lebih baik.
FAQ dan solusi
Jika klien tidak menghasilkan beban impor yang cukup, pemanfaatan CPU kluster, pemanfaatan I/O disk, dan waktu tanggapan penulisan tetap rendah. Server database dapat segera memproses data yang dikirim oleh klien. Namun, karena jumlah total data yang dikirim kecil, transaksi penulisan per detik (TPS) mungkin tidak memenuhi ekspektasi Anda.
Solusi: Anda dapat meningkatkan nilai Jumlah catatan per penyisipan batch dan Maximum Concurrency. Kinerja impor data meningkat secara linear seiring dengan peningkatan beban impor.
Jika tabel target untuk impor mengalami kesenjangan data, beberapa node kluster menjadi kelebihan beban, sehingga menurunkan kinerja impor. Dalam kasus ini, pemanfaatan CPU dan pemanfaatan I/O disk kluster rendah, tetapi waktu tanggapan penulisan tinggi. Anda juga dapat mengidentifikasi tabel target dalam tabel diagnostik kesenjangan pada halaman .
Solusi: Anda dapat mendesain ulang skema tabel lalu mengimpor ulang data tersebut. Untuk informasi selengkapnya, lihat Desain skema tabel.
Mengoptimalkan impor data dari program JDBC
Optimasi sisi klien
Gunakan impor batch di sisi aplikasi
Saat menggunakan program JDBC untuk mengimpor data, gunakan impor batch untuk mengurangi overhead jaringan dan tautan. Kecuali jika Anda memiliki persyaratan khusus, hindari mengimpor catatan tunggal.
Kami merekomendasikan ukuran batch sebanyak 2.048 catatan. Jika satu catatan berukuran besar, misalnya beberapa ratus KB, pertahankan ukuran batch di bawah 8 MB. Anda dapat menghitung jumlah catatan per batch dengan membagi 8 MB dengan ukuran satu catatan. Batch yang terlalu besar dapat menggunakan terlalu banyak memori pada node frontend dan menurunkan kinerja impor.
Konfigurasikan konkurensi di sisi aplikasi
Saat mengimpor data dari aplikasi, gunakan beberapa thread konkuren untuk mengimpor data. Satu proses tidak dapat memanfaatkan sepenuhnya sumber daya sistem. Selain itu, klien biasanya perlu memproses data dan membuat batch, yang bisa lebih lambat daripada kecepatan impor database. Menggunakan beberapa thread konkuren dapat mempercepat impor.
Konkurensi impor dipengaruhi oleh batching, sumber data, dan beban mesin klien. Tidak ada nilai optimal tunggal. Kami merekomendasikan Anda melakukan pengujian untuk menemukan tingkat konkurensi optimal. Jika kinerja impor tidak memenuhi ekspektasi Anda, gandakan konkurensi tersebut. Jika kecepatan impor menurun, kurangi secara bertahap konkurensi tersebut untuk menemukan jumlah optimal.
FAQ dan solusi
Jika kinerja buruk saat Anda mengimpor data ke AnalyticDB for MySQL dari program, Anda harus terlebih dahulu memeriksa adanya bottleneck kinerja di sisi klien.
Pastikan sumber data dapat menghasilkan data dengan kecepatan yang cukup. Jika data berasal dari sistem lain atau file, periksa adanya bottleneck output di sisi klien.
Pastikan kecepatan pemrosesan data tinggi. Periksa apakah produksi dan konsumsi data tersinkronisasi. Pastikan data yang cukup siap untuk diimpor ke AnalyticDB for MySQL.
Periksa beban mesin klien. Pastikan sumber daya sistem, seperti pemanfaatan CPU dan pemanfaatan I/O disk, mencukupi.