Memahami performa

Halaman ini menjelaskan perkiraan performa yang dapat diberikan Bigtable dalam kondisi optimal, faktor-faktor yang dapat memengaruhi performa, dan tips untuk menguji serta memecahkan masalah performa Bigtable.

Performa untuk workload umum

Bigtable memberikan performa yang sangat dapat diprediksi dan dapat diskalakan secara linear. Jika Anda menghindari penyebab performa yang lebih lambat yang dijelaskan di halaman ini, setiap node Bigtable dapat memberikan perkiraan throughput berikut, bergantung pada jenis penyimpanan yang digunakan cluster:

Jenis Penyimpanan Baca   Tulis   Pemindaian
SSD hingga 17.000 baris per detik atau hingga 14.000 baris per detik atau hingga 220 MBps
HDD hingga 500 baris per detik atau hingga 10.000 baris per detik atau hingga 180 MBps
Penyimpanan akses jarang hingga 100 baris per detik atau hingga 10.000 baris per detik atau hingga 36 MBps

Estimasi ini mengasumsikan setiap baris berisi 1 KB.

Secara umum, performa cluster diskalakan secara linear saat Anda menambahkan node ke cluster. Misalnya, jika Anda membuat cluster SSD dengan 10 node, cluster tersebut dapat mendukung hingga 140.000 baris per detik untuk workload baca saja atau tulis saja yang umum.

Merencanakan kapasitas Bigtable

Saat merencanakan cluster Bigtable, tentukan apakah Anda ingin mengoptimalkan latensi atau throughput. Misalnya, untuk tugas pemrosesan data batch, Anda mungkin lebih mementingkan throughput dan kurang mementingkan latensi. Sebaliknya, untuk layanan online yang melayani permintaan pengguna, Anda mungkin memprioritaskan latensi yang lebih rendah daripada throughput. Anda dapat mencapai angka di bagian Performa untuk beban kerja umum jika Anda mengoptimalkan throughput.

Pemakaian CPU

Di hampir semua kasus, sebaiknya gunakan penskalaan otomatis, yang memungkinkan Bigtable menambahkan atau menghapus node berdasarkan penggunaan. Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis.

Gunakan panduan berikut saat mengonfigurasi target penskalaan otomatis atau jika Anda memilih alokasi node manual. Pedoman ini berlaku terlepas dari jumlah cluster yang dimiliki instance Anda. Untuk cluster dengan alokasi node manual, Anda harus memantau pemanfaatan CPU cluster dengan tujuan menjaga pemanfaatan CPU di bawah nilai ini untuk performa yang optimal.

Sasaran pengoptimalan Penggunaan CPU maksimum
Throughput 90%
Latensi 60%

Untuk mengetahui informasi selengkapnya tentang pemantauan, lihat Pemantauan.

Pemanfaatan penyimpanan

Penyimpanan adalah pertimbangan lain dalam perencanaan kapasitas. Kapasitas penyimpanan cluster ditentukan oleh jenis penyimpanan dan jumlah node dalam cluster. Saat jumlah data yang disimpan dalam cluster meningkat, Bigtable mengoptimalkan penyimpanan dengan mendistribusikan data di semua node dalam cluster.

Anda dapat menentukan penggunaan penyimpanan per node dengan membagi pemanfaatan penyimpanan (byte) cluster dengan jumlah node dalam cluster. Misalnya, pertimbangkan cluster yang memiliki tiga node HDD dan data sebesar 9 TB. Setiap node menyimpan sekitar 3 TB, yang merupakan 18,75% dari batas penyimpanan HDD per node sebesar 16 TB.

Saat pemakaian penyimpanan meningkat, workload dapat mengalami peningkatan latensi pemrosesan kueri meskipun cluster memiliki cukup node untuk memenuhi kebutuhan CPU secara keseluruhan. Hal ini karena makin tinggi penyimpanan per node, makin banyak pekerjaan latar belakang seperti pengindeksan yang diperlukan. Peningkatan tugas latar belakang untuk menangani lebih banyak penyimpanan dapat menyebabkan latensi yang lebih tinggi dan throughput yang lebih rendah.

Mulai dengan langkah-langkah berikut saat mengonfigurasi setelan penskalaan otomatis. Jika Anda memilih alokasi node manual, pantau penggunaan penyimpanan cluster dan tambahkan atau hapus node untuk mempertahankan hal berikut.

Sasaran pengoptimalan Penggunaan penyimpanan maksimum
Throughput 70%
Latensi 60%

Untuk mengetahui informasi selengkapnya, lihat Penyimpanan per node.

Menjalankan workload terhadap Bigtable

Selalu jalankan workload Anda terhadap cluster Bigtable saat melakukan perencanaan kapasitas untuk menentukan alokasi resource terbaik bagi aplikasi Anda.

PerfKit Benchmarker Google menggunakan YCSB untuk membandingkan layanan cloud. Anda dapat mengikuti tutorial PerfKitBenchmarker untuk Bigtable guna membuat pengujian untuk beban kerja Anda. Saat melakukannya, sesuaikan parameter dalam file YAML konfigurasi tolok ukur untuk memastikan tolok ukur yang dihasilkan mencerminkan karakteristik produksi berikut:

Lihat Menguji performa dengan Bigtable untuk mengetahui praktik terbaik lainnya.

Penyebab performa yang lebih lambat

Faktor berikut dapat menyebabkan Bigtable berjalan lebih lambat dari perkiraan:

  • Anda membaca sejumlah besar row key atau rentang baris yang tidak berdekatan dalam satu permintaan baca. Bigtable memindai tabel dan membaca baris yang diminta secara berurutan. Kurangnya paralelisme ini memengaruhi latensi keseluruhan, dan pembacaan yang mencapai node panas dapat meningkatkan latensi ekor. Lihat Pembacaan dan performa untuk mengetahui detailnya.
  • Skema tabel Anda tidak didesain dengan benar. Untuk mendapatkan performa yang baik dari Bigtable, Anda harus mendesain skema yang memungkinkan operasi baca dan tulis didistribusikan secara merata di setiap tabel. Selain itu, titik masalah dalam satu tabel dapat memengaruhi performa tabel lain dalam instance yang sama. Lihat Praktik terbaik desain skema untuk mengetahui informasi selengkapnya.
  • Baris dalam tabel Bigtable Anda berisi data dalam jumlah besar. Estimasi performa mengasumsikan bahwa setiap baris berisi 1 KB data. Anda dapat membaca dan menulis data dalam jumlah yang lebih besar per baris, tetapi meningkatkan jumlah data per baris juga akan mengurangi jumlah baris per detik.
  • Baris dalam tabel Bigtable Anda berisi sangat banyak sel. Bigtable memerlukan waktu untuk memproses setiap sel dalam baris. Selain itu, setiap sel menambahkan beberapa overhead ke jumlah data yang disimpan dalam tabel Anda dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan data sebesar 1 KB (1.024 byte), akan jauh lebih efisien untuk menyimpan data tersebut dalam satu sel, daripada menyebarkan data ke 1.024 sel yang masing-masing berisi 1 byte. Jika Anda memisahkan data di lebih banyak sel daripada yang diperlukan, Anda mungkin tidak mendapatkan performa terbaik. Jika baris berisi sejumlah besar sel karena kolom berisi beberapa versi data dengan stempel waktu, pertimbangkan untuk hanya menyimpan nilai terbaru. Opsi lain untuk tabel yang ada adalah mengirim penghapusan untuk semua versi sebelumnya dengan setiap penulisan ulang.

  • Cluster tidak memiliki cukup node. Node cluster menyediakan komputasi untuk cluster dalam menangani pembacaan dan penulisan yang masuk, melacak penyimpanan, dan melakukan tugas pemeliharaan seperti pemadatan. Anda harus memastikan bahwa cluster Anda memiliki node yang cukup untuk memenuhi batas yang direkomendasikan untuk komputasi dan penyimpanan. Gunakan alat pemantauan untuk memeriksa apakah cluster kelebihan beban.

    • Komputasi - Jika CPU cluster Bigtable Anda kelebihan beban, menambahkan lebih banyak node akan meningkatkan performa dengan menyebarkan workload ke lebih banyak node.
    • Penyimpanan - Jika penggunaan penyimpanan per node lebih tinggi daripada yang direkomendasikan, tambahkan lebih banyak node untuk mempertahankan latensi dan throughput yang optimal, meskipun cluster memiliki CPU yang cukup untuk memproses permintaan. Hal ini terjadi karena peningkatan jumlah penyimpanan per node akan meningkatkan jumlah pekerjaan pemeliharaan latar belakang per node. Untuk mengetahui informasi selengkapnya, lihat Trade-off antara penggunaan dan performa penyimpanan.

  • Cluster Bigtable baru-baru ini di-scale up atau di-scale down. Setelah penskalaan otomatis meningkatkan jumlah node dalam cluster, perlu waktu hingga 20 menit dalam pemuatan sebelum performa meningkat secara signifikan. Bigtable menskalakan node cluster berdasarkan beban yang dialaminya.

    Saat Anda mengurangi jumlah node dalam cluster untuk menurunkan skala, usahakan untuk tidak mengurangi ukuran cluster lebih dari 10% dalam jangka waktu 10 menit untuk meminimalkan lonjakan latensi.

  • Cluster Bigtable menggunakan disk HDD. Dalam sebagian besar kasus, cluster Anda harus menggunakan disk SSD, yang memiliki performa yang jauh lebih baik daripada disk HDD. Lihat Memilih antara penyimpanan SSD dan HDD untuk mengetahui detailnya.

  • Ada masalah dengan koneksi jaringan. Masalah jaringan dapat mengurangi throughput dan menyebabkan operasi baca dan tulis memerlukan waktu yang lebih lama dari biasanya. Khususnya, Anda mungkin melihat masalah jika klien Anda tidak berjalan di zona yang sama dengan cluster Bigtable Anda, atau jika klien Anda berjalan di luar Google Cloud.

  • Anda menggunakan replikasi, tetapi aplikasi Anda menggunakan library klien yang sudah tidak berlaku. Jika Anda mengamati peningkatan latensi setelah mengaktifkan replikasi, pastikan library klien Cloud Bigtable yang digunakan aplikasi Anda sudah diperbarui. Library klien versi sebelumnya mungkin tidak dioptimalkan untuk mendukung replikasi. Lihat library klien Cloud Bigtable untuk menemukan repositori GitHub library klien Anda, tempat Anda dapat memeriksa versi dan mengupgrade jika perlu.

  • Anda mengaktifkan replikasi, tetapi tidak menambahkan lebih banyak node ke cluster. Dalam instance yang menggunakan replikasi, setiap cluster harus menangani pekerjaan replikasi selain beban yang diterimanya dari aplikasi. Cluster yang kurang disediakan dapat menyebabkan peningkatan latensi. Anda dapat memverifikasinya dengan memeriksa diagram penggunaan CPU instance di konsol Google Cloud .

Karena workload yang berbeda dapat menyebabkan performa bervariasi, lakukan pengujian dengan workload Anda untuk mendapatkan tolok ukur yang paling akurat.

Cold start dan QPS rendah

Cold start dan QPS rendah dapat meningkatkan latensi. Bigtable berperforma paling baik dengan tabel besar yang sering diakses. Oleh karena itu, jika Anda mulai mengirim permintaan setelah tidak digunakan selama beberapa waktu (cold start), Anda mungkin melihat latensi yang tinggi saat Bigtable membangun kembali koneksi. Latensi juga lebih tinggi saat QPS rendah.

Jika QPS Anda rendah, atau jika Anda tahu bahwa terkadang Anda akan mengirim permintaan ke tabel Bigtable setelah periode tidak aktif, coba strategi berikut untuk menjaga koneksi Anda tetap aktif dan mencegah latensi tinggi.

Selama periode QPS rendah, jumlah error yang ditampilkan Bigtable lebih relevan daripada persentase operasi yang menampilkan error.

Cold start pada waktu inisialisasi klien. Jika Anda menggunakan klien Cloud Bigtable untuk Java versi yang lebih lama dari versi 2.18.0, Anda dapat mengaktifkan penggantian saluran. Pada versi yang lebih baru, pemuatan ulang saluran diaktifkan secara default. Penyegaran channel melakukan dua hal:

  • Saat melakukan inisialisasi, klien akan menyiapkan channel sebelum mengirim permintaan pertama.
  • Server akan memutuskan koneksi yang berjalan lama setiap jam. Pengoptimalan channel menggantikan channel yang akan segera berakhir secara preventif.

Namun, cara ini tidak membuat channel tetap aktif saat ada periode tidak aktif.

Cara Bigtable mengoptimalkan data Anda dari waktu ke waktu

Untuk menyimpan data pokok setiap tabel, Bigtable memecah data menjadi beberapa tablet, yang dapat dipindahkan antar-node di cluster Bigtable Anda. Metode penyimpanan ini memungkinkan Bigtable menggunakan dua strategi untuk mengoptimalkan data dari waktu ke waktu:

  1. Bigtable menyimpan jumlah data yang hampir sama di setiap node Bigtable.
  2. Bigtable mendistribusikan operasi baca dan tulis secara merata di semua node Bigtable.

Terkadang, strategi ini bertentangan. Misalnya, jika baris tablet dibaca sangat sering, Bigtable dapat menyimpan tablet tersebut di nodenya sendiri, meskipun hal ini menyebabkan beberapa node menyimpan lebih banyak data daripada yang lain.

Sebagai bagian dari proses ini, Bigtable dapat membagi tablet menjadi dua atau lebih tablet yang lebih kecil untuk mengurangi ukurannya atau mengisolasi baris panas dalam tablet yang ada.

Bagian berikut menjelaskan setiap strategi ini secara lebih mendetail.

Mendistribusikan jumlah data di seluruh node

Saat Anda menulis data ke tabel Bigtable, Bigtable akan memecah data tabel menjadi tablet. Setiap tablet berisi rentang baris yang berdekatan dalam tabel.

Jika Anda telah menulis kurang dari beberapa GB data ke tabel, Bigtable menyimpan semua tablet pada satu node dalam cluster Anda:

Cluster dengan empat tablet pada satu node.

Seiring bertambahnya jumlah tablet, Bigtable memindahkan beberapa tablet ke node lain dalam cluster untuk menyeimbangkan jumlah data secara lebih merata di seluruh cluster:

Tablet tambahan didistribusikan di beberapa node.

Mendistribusikan operasi baca dan tulis secara merata di seluruh node

Jika Anda telah mendesain skema dengan benar, maka operasi baca dan tulis akan didistribusikan secara cukup merata di seluruh tabel Anda. Namun, ada beberapa kasus di mana Anda tidak dapat menghindari akses ke baris tertentu lebih sering daripada baris lainnya. Bigtable membantu Anda mengatasi kasus ini dengan mempertimbangkan pembacaan dan penulisan saat menyeimbangkan tablet di seluruh node.

Misalnya, anggaplah 25% pembacaan dilakukan pada sejumlah kecil tablet dalam cluster, dan pembacaan tersebar secara merata di semua tablet lainnya:

Dari 48 tablet, 25% pembacaan akan dilakukan pada 3 tablet.

Bigtable akan mendistribusikan ulang tablet yang ada sehingga operasi baca didistribusikan secara merata di seluruh cluster:

Tiga tablet yang sering digunakan diisolasi pada nodenya sendiri.

Menguji performa dengan Bigtable

Jika Anda menjalankan uji performa untuk aplikasi yang bergantung pada Bigtable, ikuti panduan berikut saat Anda merencanakan dan menjalankan pengujian:

  • Lakukan pengujian dengan data yang memadai.
    • Jika tabel di instance produksi Anda berisi total data 100 GB atau kurang per node, lakukan pengujian dengan tabel yang memiliki jumlah data yang sama.
    • Jika tabel berisi lebih dari 100 GB data per node, lakukan pengujian dengan tabel yang berisi minimal 100 GB data per node. Misalnya, jika instance produksi Anda memiliki satu cluster empat node, dan tabel dalam instance tersebut berisi total data sebesar 1 TB, jalankan pengujian menggunakan tabel berukuran minimal 400 GB.
  • Uji dengan satu tabel.
  • Tetap di bawah pemanfaatan penyimpanan yang direkomendasikan per node. Untuk mengetahui detailnya, lihat Penggunaan penyimpanan per node.
  • Sebelum melakukan pengujian, jalankan pra-pengujian berat selama beberapa menit. Langkah ini memungkinkan Bigtable menyeimbangkan data di seluruh node berdasarkan pola akses yang diamatinya.
  • Jalankan pengujian minimal selama 10 menit. Langkah ini memungkinkan Bigtable mengoptimalkan data Anda lebih lanjut, dan membantu memastikan bahwa Anda akan menguji pembacaan dari disk serta pembacaan yang di-cache dari memori.

Memecahkan masalah performa

Jika Anda merasa bahwa Bigtable mungkin menyebabkan hambatan performa dalam aplikasi Anda, pastikan untuk memeriksa semua hal berikut:

  • Periksa hasil pemindaian Key Visualizer untuk tabel Anda. Alat Key Visualizer untuk Bigtable membuat data pemindaian baru setiap 15 menit yang menunjukkan pola penggunaan untuk setiap tabel dalam cluster. Visualisasi Kunci memungkinkan Anda memeriksa apakah pola penggunaan Anda menyebabkan hasil yang tidak diinginkan, seperti hotspot pada baris tertentu atau penggunaan CPU yang berlebihan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Key Visualizer.
  • Beri komentar pada kode yang melakukan operasi baca dan tulis Bigtable. Jika masalah performa hilang, berarti Anda mungkin menggunakan Bigtable dengan cara yang menghasilkan performa yang kurang optimal. Jika masalah performa berlanjut, kemungkinan masalah tersebut tidak terkait dengan Bigtable.

  • Pastikan Anda membuat sesedikit mungkin klien. Membuat klien untuk Bigtable adalah operasi yang relatif mahal. Oleh karena itu, Anda harus membuat jumlah klien sekecil mungkin:

    • Jika Anda menggunakan replikasi, atau jika Anda menggunakan profil aplikasi untuk mengidentifikasi berbagai jenis traffic ke instance Anda, buat satu klien per profil aplikasi dan bagikan klien di seluruh aplikasi Anda.
    • Jika Anda tidak menggunakan replikasi atau profil aplikasi, buat satu klien dan bagikan di seluruh aplikasi Anda.

    Jika Anda menggunakan klien HBase untuk Java, Anda membuat objek Connection bukan klien, jadi buat sesedikit mungkin koneksi.

  • Pastikan Anda membaca dan menulis banyak baris yang berbeda dalam tabel. Bigtable berfungsi paling baik saat pembacaan dan penulisan didistribusikan secara merata di seluruh tabel Anda, yang membantu Bigtable mendistribusikan beban kerja di semua node dalam cluster Anda. Jika operasi baca dan tulis tidak dapat disebarkan ke semua node Bigtable, performa akan terganggu.

    Jika Anda mendapati bahwa Anda hanya membaca dan menulis sejumlah kecil baris, Anda mungkin perlu mendesain ulang skema agar pembacaan dan penulisan didistribusikan secara lebih merata.

  • Verifikasi bahwa Anda melihat performa yang hampir sama untuk operasi baca dan tulis. Jika mendapati bahwa operasi baca jauh lebih cepat daripada operasi tulis, Anda mungkin mencoba membaca row key yang tidak ada, atau rentang besar row key yang hanya berisi sejumlah kecil baris.

    Untuk membuat perbandingan yang valid antara pembacaan dan penulisan, usahakan agar setidaknya 90% pembacaan Anda menampilkan hasil yang valid. Selain itu, jika Anda membaca rentang besar kunci baris, ukur performa berdasarkan jumlah baris sebenarnya dalam rentang tersebut, bukan jumlah maksimum baris yang dapat ada.

  • Gunakan jenis permintaan penulisan yang tepat untuk data Anda. Memilih cara optimal untuk menulis data akan membantu mempertahankan performa tinggi.

  • Periksa latensi untuk satu baris. Jika Anda mengamati latensi yang tidak terduga saat mengirim permintaan ReadRows, Anda dapat memeriksa latensi baris pertama permintaan untuk mempersempit penyebabnya. Secara default, latensi keseluruhan untuk permintaan ReadRows mencakup latensi untuk setiap baris dalam permintaan serta waktu pemrosesan antar-baris. Jika latensi keseluruhan tinggi, tetapi latensi baris pertama rendah, hal ini menunjukkan bahwa latensi disebabkan oleh jumlah permintaan atau waktu pemrosesan, bukan oleh masalah pada Bigtable.

    Jika Anda menggunakan [Bigtable client library for Java] [java-client], Anda dapat melihat metrik read_rows_first_row_latency di Metrics Explorer konsolGoogle Cloud setelah mengaktifkan metrik sisi klien.

  • Gunakan profil aplikasi terpisah untuk setiap workload. Jika Anda mengalami masalah performa setelah menambahkan workload baru, buat profil aplikasi baru untuk workload baru. Kemudian, Anda dapat memantau metrik untuk profil aplikasi secara terpisah guna memecahkan masalah lebih lanjut. Lihat Cara kerja profil aplikasi untuk mengetahui detail tentang alasan penggunaan beberapa profil aplikasi merupakan praktik terbaik.

  • Aktifkan metrik sisi klien. Anda dapat menyiapkan metrik sisi klien untuk membantu mengoptimalkan dan memecahkan masalah performa. Misalnya, karena Bigtable berfungsi paling baik dengan QPS tinggi yang didistribusikan secara merata, peningkatan latensi P100 (maks.) untuk sebagian kecil permintaan tidak selalu menunjukkan masalah performa yang lebih besar dengan Bigtable. Metrik sisi klien dapat memberi Anda insight tentang bagian siklus proses permintaan yang mungkin menyebabkan latensi.

  • Pastikan aplikasi Anda menggunakan permintaan baca sebelum waktu tunggu habis. Jika aplikasi Anda memproses data selama aliran baca, Anda berisiko permintaan kehabisan waktu sebelum Anda menerima semua respons dari panggilan. Hal ini menghasilkan pesan ABORTED. Jika Anda melihat error ini, kurangi jumlah pemrosesan selama aliran baca.

Langkah berikutnya