Halaman ini memberikan panduan untuk memuat data dalam jumlah besar secara efisien ke Spanner.
Anda memiliki beberapa opsi untuk memuat data secara massal ke Spanner:
- Menyisipkan baris menggunakan Data Manipulation Language (DML).
- Menyisipkan baris menggunakan mutasi.
- Mengimpor data menggunakan konektor Dataflow.
- Mengimpor database menggunakan file Avro.
- Impor data dalam format CSV.
Meskipun Anda juga dapat menyisipkan baris menggunakan Google Cloud CLI, sebaiknya jangan gunakan gcloud CLI untuk pemuatan massal.
Panduan performa untuk pemuatan massal
Untuk mencapai performa pemuatan massal yang optimal, maksimalkan penggunaan partisi untuk mendistribusikan penulisan data di berbagai tugas pekerja.
Spanner menggunakan pemisahan berbasis beban untuk mendistribusikan pemuatan data secara merata di seluruh resource komputasi instance. Setelah beberapa menit beban tinggi, Spanner memperkenalkan batas terpisah antar-baris. Secara umum, jika beban data didistribusikan dengan baik dan Anda mengikuti praktik terbaik untuk desain skema dan pemuatan massal, throughput operasi tulis akan meningkat dua kali lipat setiap beberapa menit sampai Anda menjenuhkan resource CPU yang tersedia di instance.
Mempartisi data Anda berdasarkan kunci utama
Spanner secara dinamis membagi tabel menjadi rentang yang lebih kecil. Kunci utama untuk sebuah baris menentukan di mana kunci tersebut dipartisi.
Guna mendapatkan throughput tulis yang optimal untuk pemuatan massal, partisi data Anda berdasarkan kunci utama dengan pola berikut:
- Setiap partisi berisi rentang baris berturut-turut, seperti yang ditentukan oleh kolom kunci.
- Setiap commit berisi data hanya untuk satu partisi.
Sebaiknya jumlah partisi 10 kali jumlah node di instance Spanner Anda. Untuk menetapkan baris ke partisi:
- Mengurutkan data berdasarkan kunci utama.
- Bagi data menjadi 10 * (jumlah node) partisi yang terpisah dan berukuran sama.
- Buat dan tetapkan tugas pekerja terpisah untuk setiap partisi. Pembuatan tugas pekerja terjadi di aplikasi Anda. Fitur tersebut bukan fitur Spanner.
Dengan mengikuti pola ini, Anda akan mendapatkan throughput tulis massal maksimum secara keseluruhan sebesar 10-20 MB per detik per node untuk beban besar.
Saat Anda memuat data, Spanner akan membuat dan memperbarui pemisahan untuk menyeimbangkan beban pada node dalam instance Anda. Selama proses ini, Anda mungkin mengalami penurunan throughput untuk sementara.
Contoh
Anda memiliki konfigurasi regional dengan 3 node. Anda memiliki 90.000 baris pada tabel yang tidak disisipkan. Kunci utama dalam tabel berkisar dari 1 hingga 90000.
- Baris: 90.000 baris
- Node: 3
- Partisi: 10 * 3 = 30
- Baris per partisi: 90000 / 30 = 3000.
Partisi pertama mencakup rentang kunci 1 hingga 3000. Partisi kedua mencakup rentang kunci 3001 hingga 6000. Partisi ke-30 mencakup rentang kunci 87001 hingga 90000. (Anda tidak boleh menggunakan kunci berurutan dalam tabel besar. Contoh ini hanya untuk demonstrasi.)
Setiap tugas pekerja mengirim operasi tulis untuk satu partisi. Dalam setiap partisi, Anda harus menulis baris secara berurutan berdasarkan kunci utama. Menulis baris secara acak, sehubungan dengan kunci utama, juga akan menghasilkan throughput yang cukup tinggi. Dengan mengukur pengujian yang dijalankan, Anda akan memperoleh insight tentang pendekatan mana yang memberikan performa terbaik untuk set data Anda.
Jika Anda memutuskan untuk tidak menggunakan partisi
Menulis baris acak dalam commit mungkin lebih lambat daripada menulis rangkaian baris yang berdekatan dalam commit, dan kemungkinan menyentuh data dalam partisi yang berbeda. Latensi dan overhead commit lebih tinggi ketika lebih banyak bagian ditulis ke dalam commit, karena peningkatan koordinasi di seluruh server. Beberapa pemisahan mungkin terlibat, karena setiap baris acak dapat menjadi milik bagian yang berbeda. Dalam skenario kasus terburuk, setiap penulisan melibatkan setiap bagian dalam instance Spanner Anda. Seperti yang disebutkan di atas, throughput operasi tulis akan diturunkan jika ada lebih banyak bagian yang terlibat.
Pemuatan massal tanpa partisi
Menulis kumpulan baris yang berdekatan dalam commit bisa lebih cepat daripada menulis baris acak. Baris acak juga kemungkinan mencakup data dari partisi yang berbeda.
Jika lebih banyak partisi ditulis ke dalam commit, lebih banyak koordinasi di seluruh server yang diperlukan, sehingga meningkatkan latensi dan overhead commit.
Beberapa partisi mungkin terlibat karena setiap baris acak dapat dimiliki oleh partisi yang berbeda. Dalam skenario terburuk, setiap operasi tulis melibatkan setiap partisi di instance Spanner. Seperti disebutkan di atas, throughput operasi tulis akan diturunkan jika ada lebih banyak partisi yang terlibat.
Menghindari kelebihan beban
Anda dapat mengirim lebih banyak permintaan tulis daripada yang dapat ditangani Spanner. Spanner menangani kelebihan beban dengan membatalkan transaksi, yang disebut pushback. Untuk transaksi hanya tulis, Spanner akan otomatis mencoba kembali transaksi. Dalam kasus tersebut, penolakan muncul sebagai latensi tinggi. Selama beban yang berat, pushback dapat berlangsung hingga satu menit. Selama beban yang sangat berat, penolakan dapat berlangsung selama beberapa menit. Untuk menghindari penolakan, Anda harus membatasi permintaan tulis agar penggunaan CPU tetap dalam batas yang wajar. Atau, pengguna dapat meningkatkan jumlah node sehingga penggunaan CPU tetap dalam batas.
Lakukan mutasi antara 1 MB hingga 5 MB sekaligus
Setiap penulisan ke Spanner berisi beberapa overhead, baik penulisannya besar maupun kecil. Untuk memaksimalkan throughput, maksimalkan jumlah data yang disimpan per operasi tulis. Penulisan yang lebih besar menurunkan rasio overhead per penulisan. Teknik yang baik adalah agar setiap baris berkomitmen untuk mengubah ratusan baris. Saat menulis baris yang relatif besar, ukuran commit sebesar 1 MB hingga 5 MB biasanya memberikan performa terbaik. Saat menulis nilai kecil, atau nilai yang diindeks, sebaiknya tulis maksimal beberapa ratus baris dalam satu commit. Terlepas dari ukuran commit dan jumlah baris, perhatikan bahwa ada batasan 80.000 mutasi per commit. Untuk menentukan performa yang optimal, Anda harus menguji dan mengukur throughput.
Commit yang lebih besar dari 5 MB atau lebih dari beberapa ratus baris tidak memberikan manfaat tambahan, dan berisiko melebihi batas Spanner terkait ukuran commit dan mutasi per commit.
Panduan untuk indeks sekunder
Jika database memiliki indeks sekunder, Anda harus memilih antara menambahkan indeks ke skema database sebelum atau setelah memuat data tabel.
Menambahkan indeks sebelum data dimuat memungkinkan perubahan skema untuk segera selesai. Namun, setiap penulisan yang memengaruhi indeks memerlukan waktu lebih lama karena juga perlu mengupdate indeks. Setelah pemuatan data selesai, database dapat segera digunakan dengan semua indeks tersedia. Untuk membuat tabel dan indeksnya secara bersamaan, kirim pernyataan DDL untuk tabel baru dan indeks baru dalam satu permintaan ke Spanner.
Menambahkan indeks setelah memuat data berarti bahwa setiap penulisan bersifat efisien. Namun, perubahan skema untuk setiap pengisian ulang indeks dapat memerlukan waktu lama. Database tidak sepenuhnya dapat digunakan, dan kueri tidak dapat menggunakan indeks sampai semua perubahan skema selesai. Database masih dapat melayani penulisan dan kueri, tetapi dengan kecepatan yang lebih lambat.
Sebaiknya tambahkan indeks yang penting bagi aplikasi bisnis Anda sebelum memuat data. Untuk semua indeks non-kritis, tambahkan indeks tersebut setelah data dimigrasikan.
Menguji dan mengukur throughput
Memprediksi throughput bisa jadi sulit. Sebaiknya uji strategi pemuatan massal sebelum menjalankan pemuatan akhir. Untuk contoh mendetail penggunaan partisi dan pemantauan performa, lihat Memaksimalkan throughput pemuatan data.
Praktik terbaik untuk pemuatan massal secara berkala ke database yang ada
Jika Anda memperbarui database yang sudah ada yang berisi data tetapi tidak memiliki indeks sekunder, rekomendasi dalam topik ini tetap berlaku.
Jika Anda memiliki indeks sekunder, petunjuknya dapat menghasilkan performa yang wajar. Performa bergantung pada rata-rata jumlah pemisahan yang terlibat dalam transaksi Anda. Jika throughput turun terlalu rendah, Anda dapat mencoba hal berikut:
- Sertakan lebih sedikit mutasi di setiap commit, yang dapat meningkatkan throughput.
- Jika upload Anda lebih besar dari ukuran total tabel yang sedang diperbarui saat ini, hapus indeks sekunder, lalu tambahkan lagi setelah Anda mengupload data. Langkah ini biasanya tidak diperlukan, tetapi dapat meningkatkan throughput.