Praktik terbaik pemuatan massal

Halaman ini memberikan panduan untuk memuat data dalam jumlah besar secara massal ke Spanner secara efisien.

Anda memiliki beberapa opsi untuk memuat data secara massal ke Spanner:

Meskipun Anda juga dapat menyisipkan baris menggunakan Google Cloud CLI, sebaiknya jangan gunakan gcloud CLI untuk pemuatan massal.

Pedoman performa untuk pemuatan massal

Untuk mencapai performa pemuatan massal yang optimal, maksimalkan penggunaan partisi untuk mendistribusikan penulisan data di seluruh tugas pekerja.

Spanner menggunakan pemisahan berbasis beban untuk mendistribusikan beban data Anda secara merata di seluruh resource komputasi instance. Setelah beberapa menit beban tinggi, Spanner akan memperkenalkan batas pemisahan antarbaris. Secara umum, jika beban data Anda didistribusikan dengan baik dan Anda mengikuti praktik terbaik untuk desain skema dan pemuatan massal, throughput operasi tulis akan berlipat ganda setiap beberapa menit hingga Anda memenuhi resource CPU yang tersedia di instance.

Mempartisi data menurut kunci utama

Spanner secara otomatis mempartisi tabel menjadi rentang yang lebih kecil. Kunci utama untuk baris menentukan tempat partisi.

Untuk mendapatkan throughput operasi tulis yang optimal untuk pemuatan massal, partisi data Anda menurut kunci primer dengan pola ini:

  • Setiap partisi berisi rentang baris berurutan, seperti yang ditentukan oleh kolom kunci.
  • Setiap commit hanya berisi data untuk satu partisi.

Sebaiknya jumlah partisi adalah 10 kali jumlah node di instance Spanner Anda. Untuk menetapkan baris ke partisi:

  • Urutkan data menurut kunci utama.
  • Bagi data menjadi 10 * (jumlah node) partisi terpisah dengan ukuran yang sama.
  • Buat dan tetapkan tugas pekerja terpisah ke setiap partisi. Pembuatan tugas pekerja dilakukan di aplikasi Anda. Ini bukan fitur Spanner.

Dengan mengikuti pola ini, Anda akan melihat throughput operasi tulis massal secara keseluruhan maksimum sebesar 10-20 MB per detik per node untuk beban besar.

Saat Anda memuat data, Spanner akan membuat dan memperbarui bagian untuk menyeimbangkan beban pada node di instance Anda. Selama proses ini, Anda mungkin mengalami penurunan throughput sementara.

Contoh

Anda memiliki konfigurasi regional dengan 3 node. Anda memiliki 90.000 baris dalam tabel yang tidak interleaved. Kunci utama dalam tabel berkisar dari 1 hingga 90.000.

  • Baris: 90.000 baris
  • Node: 3
  • Partisi: 10 * 3 = 30
  • Baris per partisi: 90.000 / 30 = 3.000.

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 mengirimkan operasi tulis untuk satu partisi. Dalam setiap partisi, Anda harus menulis baris secara berurutan menurut kunci utama. Menulis baris secara acak, terkait kunci utama, juga akan memberikan throughput yang cukup tinggi. Mengukur pengujian yang dijalankan akan memberi Anda 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 kumpulan baris yang berurutan dalam commit, dan kemungkinan akan menyentuh data di partisi yang berbeda. Latensi dan overhead commit lebih tinggi jika lebih banyak pemisahan yang ditulis ke dalam commit, karena peningkatan koordinasi di seluruh server. Beberapa pemisahan kemungkinan terlibat, karena setiap baris acak dapat berasal dari pemisahan yang berbeda. Dalam skenario kasus terburuk, setiap operasi tulis melibatkan setiap bagian dalam instance Spanner Anda. Seperti yang disebutkan sebelumnya, throughput operasi tulis diturunkan saat lebih banyak pemisahan dilibatkan.

Pemuatan massal tanpa partisi

Menulis kumpulan baris yang berurutan dalam commit dapat lebih cepat daripada menulis baris acak. Baris acak juga kemungkinan menyertakan data dari partisi yang berbeda.

Jika lebih banyak partisi ditulis ke dalam commit, lebih banyak koordinasi di seluruh server diperlukan, sehingga meningkatkan latensi dan overhead commit.

Beberapa partisi mungkin terlibat karena setiap baris acak dapat berasal dari partisi yang berbeda. Dalam skenario terburuk, setiap operasi tulis melibatkan setiap partisi di instance Spanner Anda. Seperti yang disebutkan sebelumnya, throughput operasi tulis akan diturunkan jika lebih banyak partisi yang terlibat.

Hindari 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 khusus tulis, Spanner akan otomatis mencoba kembali transaksi. Dalam kasus tersebut, pushback akan muncul sebagai latensi tinggi. Selama beban berat, pushback dapat berlangsung hingga satu menit. Selama beban yang sangat berat, pushback dapat berlangsung selama beberapa menit. Untuk menghindari pushback, Anda harus membatasi permintaan tulis agar penggunaan CPU tetap dalam batas yang wajar. Atau, pengguna dapat meningkatkan jumlah node agar penggunaan CPU tetap dalam batas.

Melakukan commit mutasi antara 1 MB hingga 5 MB sekaligus

Setiap operasi tulis ke Spanner berisi beberapa overhead, baik operasi tulis besar maupun kecil. Untuk memaksimalkan throughput, maksimalkan jumlah data yang disimpan per penulisan. Penulisan yang lebih besar akan menurunkan rasio overhead per penulisan. Teknik yang baik adalah setiap commit memutasi ratusan baris. Saat menulis baris yang relatif besar, ukuran commit 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, perlu diketahui 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 pada ukuran commit dan mutasi per commit.

Panduan untuk indeks sekunder

Jika database Anda 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 diselesaikan segera. Namun, setiap operasi tulis yang memengaruhi indeks memerlukan waktu lebih lama karena juga perlu memperbarui indeks. Setelah pemuatan data selesai, database akan segera dapat digunakan dengan semua indeks yang ada. 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 setiap operasi tulis akan efisien. Namun, perubahan skema untuk setiap pengisian ulang indeks dapat memerlukan waktu yang lama. Database tidak dapat digunakan sepenuhnya, dan kueri tidak dapat menggunakan indeks hingga semua perubahan skema selesai. Database masih dapat menyalurkan operasi tulis dan kueri, tetapi dengan kecepatan yang lebih lambat.

Sebaiknya tambahkan indeks yang penting bagi aplikasi bisnis Anda sebelum memuat data. Untuk semua indeks non-penting, tambahkan setelah data dimigrasikan.

Menguji dan mengukur throughput

Memprediksi throughput bisa jadi sulit. Sebaiknya uji strategi pemuatan massal Anda sebelum menjalankan pemuatan akhir. Untuk contoh mendetail tentang penggunaan pemisahan dan pemantauan performa, lihat Memaksimalkan throughput pemuatan data.

Praktik terbaik untuk pemuatan massal berkala ke database yang ada

Jika Anda memperbarui database yang ada yang berisi data, tetapi tidak memiliki indeks sekunder, rekomendasi dalam dokumen ini masih berlaku.

Jika Anda memiliki indeks sekunder, petunjuk tersebut mungkin menghasilkan performa yang wajar. Performa bergantung pada jumlah pemisahan, rata-rata, yang terlibat dalam transaksi Anda. Jika throughput turun terlalu rendah, Anda dapat mencoba hal berikut:

  • Sertakan lebih sedikit mutasi dalam setiap commit, yang dapat meningkatkan throughput.
  • Jika upload Anda lebih besar dari total ukuran tabel saat ini yang sedang diperbarui, hapus indeks sekunder, lalu tambahkan lagi setelah Anda mengupload data. Langkah ini biasanya tidak diperlukan, tetapi dapat meningkatkan throughput.