Memahami performa

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

Performa untuk workload umum

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

Jenis Penyimpanan Operasi baca   Operasi tulis   Pemindaian
SSD hingga 14.000 baris per detik atau hingga 14.000 baris per detik atau hingga 220 MB/d
HDD hingga 500 baris per detik atau hingga 10.000 baris per detik atau hingga 180 MB/dtk

Estimasi ini mengasumsikan bahwa setiap baris berisi 1 KB data.

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 hanya baca atau hanya tulis.

Merencanakan kapasitas Bigtable Anda

Kompromi antara throughput tinggi dan latensi rendah

Saat merencanakan cluster Bigtable Anda, penting untuk mempertimbangkan kompromi antara throughput dan latensi. Bigtable digunakan dalam spektrum aplikasi yang luas, dan kasus penggunaan yang berbeda dapat memiliki sasaran pengoptimalan yang berbeda. Misalnya, untuk tugas pemrosesan data batch, Anda mungkin lebih memperhatikan throughput, tetapi lebih sedikit fokus pada latensi. Di sisi lain, layanan online yang melayani permintaan pengguna mungkin lebih memprioritaskan latensi yang lebih rendah daripada throughput. Karena itu, penting untuk merencanakan kapasitas dengan tepat.

Angka-angka di bagian Performa untuk workload umum dapat dicapai ketika Anda memprioritaskan throughput, tetapi latensi tail untuk Bigtable dalam beban tersebut mungkin terlalu tinggi bagi aplikasi yang sensitif latensi. Secara umum, Bigtable menawarkan latensi optimal saat beban CPU untuk cluster di bawah 70%. Namun, untuk aplikasi yang sensitif terhadap latensi, sebaiknya rencanakan setidaknya 2x kapasitas untuk kueri Bigtable per detik (QPS) maksimum aplikasi Anda. Kapasitas ini memastikan cluster Bigtable Anda berjalan pada beban CPU kurang dari 50%, sehingga dapat menawarkan latensi rendah ke layanan front-end. Kapasitas ini juga menyediakan buffer untuk lonjakan traffic atau hotspot akses kunci, yang dapat menyebabkan traffic tidak seimbang di antara node dalam cluster.

Kompromi antara penggunaan penyimpanan dan performa

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

Anda dapat menentukan penggunaan penyimpanan per node dengan membagi penggunaan penyimpanan (byte) cluster dengan jumlah node dalam cluster. Misalnya, ada 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 penggunaan penyimpanan meningkat, beban kerja dapat mengalami peningkatan latensi pemrosesan kueri meskipun cluster memiliki node yang cukup untuk memenuhi kebutuhan CPU secara keseluruhan. Hal ini karena makin tinggi penyimpanan per node, makin banyak pekerjaan latar belakang seperti pengindeksan yang diperlukan. Peningkatan pekerjaan latar belakang untuk menangani lebih banyak penyimpanan dapat menghasilkan latensi yang lebih tinggi dan throughput yang lebih rendah.

Untuk aplikasi yang sensitif latensi, sebaiknya pertahankan penggunaan penyimpanan per node di bawah 60%. Jika set data Anda bertambah, tambahkan lebih banyak node untuk mempertahankan latensi rendah.

Untuk aplikasi yang tidak sensitif terhadap latensi, Anda dapat menyimpan lebih dari 70% batas tersebut, seperti yang dijelaskan dalam Penyimpanan per node.

Menjalankan workload standar Anda terhadap Bigtable

Selalu jalankan workload standar Anda sendiri terhadap cluster Bigtable saat melakukan perencanaan kapasitas, sehingga Anda dapat mengetahui alokasi resource terbaik untuk aplikasi Anda.

PerfKit Benchmarker Google menggunakan YCSB untuk menjalankan benchmark pada layanan cloud. Anda dapat mengikuti tutorial PerfKitBenchmarker untuk Bigtable guna membuat pengujian beban kerja Anda sendiri. Saat melakukannya, Anda harus men-tuning parameter dalam file yaml konfigurasi benchmark untuk memastikan bahwa benchmark yang dihasilkan mencerminkan karakteristik berikut dalam produksi Anda:

Lihat Menguji performa dengan Bigtable untuk mengetahui praktik terbaik lainnya.

Penyebab performa lebih lambat

Ada beberapa faktor yang dapat menyebabkan Bigtable berperforma lebih lambat daripada perkiraan yang ditampilkan di atas:

  • Anda membaca banyak kunci baris atau rentang baris yang tidak berdekatan dalam satu permintaan baca. Bigtable memindai tabel dan membaca baris yang diminta secara berurutan. Berkurangnya paralelisme ini memengaruhi latensi keseluruhan, dan pembacaan apa pun yang mencapai node panas dapat meningkatkan latensi tail. Lihat Pembacaan dan performa untuk mengetahui detailnya.
  • Skema tabel Anda tidak didesain dengan benar. Untuk mendapatkan performa yang baik dari BigQuery, penting untuk mendesain skema yang memungkinkan mendistribusikan pembacaan dan penulisan secara merata di setiap tabel. Selain itu, hotspot dalam satu tabel dapat memengaruhi performa tabel lain dalam instance yang sama. Lihat Praktik terbaik desain skema untuk informasi selengkapnya.
  • Baris pada tabel Bigtable Anda berisi data dalam jumlah besar. Estimasi performa yang ditampilkan di atas mengasumsikan bahwa setiap baris berisi 1 KB data. Anda dapat membaca dan menulis data dalam jumlah besar per baris, tetapi meningkatkan jumlah data per baris juga akan mengurangi jumlah baris per detik.
  • Baris pada tabel Bigtable Anda berisi jumlah sel yang sangat besar. Bigtable membutuhkan waktu untuk memproses setiap sel secara berurutan. Selain itu, setiap sel menambahkan beberapa {i>overhead<i} ke jumlah data yang disimpan di tabel Anda dan dikirim melalui jaringan. Misalnya, jika Anda menyimpan 1 KB (1.024 byte), akan jauh lebih menghemat ruang untuk menyimpan data tersebut dalam satu sel, daripada menyebarkan data di 1.024 sel yang masing-masing berisi 1 byte. Jika membagi data di lebih banyak sel daripada yang diperlukan, Anda mungkin tidak mendapatkan performa terbaik. Jika baris berisi banyak sel karena kolom berisi beberapa versi data dengan stempel waktu, pertimbangkan untuk hanya menyimpan nilai terbaru. Opsi lain untuk tabel yang sudah ada adalah mengirim penghapusan untuk semua versi sebelumnya dengan setiap penulisan ulang.

  • Cluster tidak memiliki cukup node. Node cluster menyediakan komputasi untuk cluster agar dapat menangani pembacaan dan penulisan yang masuk, melacak penyimpanan, dan melakukan tugas pemeliharaan seperti pemadatan. Anda harus memastikan bahwa cluster Anda memiliki node yang cukup agar 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 dapat meningkatkan performa dengan mendistribusikan beban kerja ke lebih banyak node.
    • Penyimpanan - Jika penggunaan penyimpanan per node menjadi lebih tinggi dari yang direkomendasikan, Anda perlu menambahkan lebih banyak node untuk mempertahankan latensi dan throughput yang optimal, meskipun cluster memiliki CPU yang cukup untuk memproses permintaan. Hal ini karena peningkatan penyimpanan per node akan meningkatkan jumlah pekerjaan pemeliharaan latar belakang per node. Untuk mengetahui detailnya, lihat Kompromi antara penggunaan penyimpanan dan performa.

  • Cluster Bigtable telah ditingkatkan skalanya atau diturunkan skalanya baru-baru ini. Setelah jumlah node dalam cluster ditingkatkan, perlu waktu hingga 20 menit untuk memuat sebelum Anda melihat peningkatan performa cluster yang signifikan. Bigtable menskalakan node dalam cluster berdasarkan beban yang dialaminya.

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

  • Cluster Bigtable menggunakan disk HDD. Dalam sebagian besar kasus, cluster Anda harus menggunakan disk SSD, yang memiliki performa 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 serta menyebabkan pembacaan dan penulisan memerlukan waktu yang lebih lama dari biasanya. Secara khusus, 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 usang. Jika Anda mengamati peningkatan latensi setelah mengaktifkan replikasi, pastikan library klien Cloud Bigtable yang digunakan aplikasi Anda adalah yang terbaru. Library klien versi lama 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 telah mengaktifkan replikasi, tetapi tidak menambahkan lebih banyak node ke cluster Anda. Pada instance yang menggunakan replikasi, setiap cluster harus menangani pekerjaan replikasi selain beban yang diterima dari aplikasi. Cluster yang kurang disediakan dapat menyebabkan peningkatan latensi. Anda dapat memverifikasi hal ini dengan memeriksa diagram penggunaan CPU instance di Konsol Google Cloud.

Karena beban kerja yang berbeda dapat menyebabkan performa bervariasi, Anda harus melakukan pengujian dengan beban kerja Anda sendiri untuk mendapatkan tolok ukur yang paling akurat.

Cold start

Bigtable menghasilkan performa terbaik pada tabel besar yang sering diakses. Oleh karena itu, jika Anda mulai mengirim permintaan setelah periode tidak ada penggunaan, Anda mungkin melihat latensi tinggi saat Bigtable mengaktifkan kembali koneksi.

Jika mengetahui bahwa terkadang Anda akan mengirim permintaan ke tabel Bigtable setelah tidak aktif selama beberapa waktu, Anda dapat mencoba strategi berikut untuk menjaga koneksi tetap hangat dan mencegah latensi tinggi ini. Laporan ini juga dapat membantu performa selama periode QPS rendah.

Jika menggunakan versi klien Cloud Bigtable untuk Java yang lebih lama dari versi 2.18.0, Anda dapat mengaktifkan pemuatan ulang saluran. Pada versi yang lebih baru, pembuatan dasar saluran diaktifkan secara default.

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

Cara Bigtable mengoptimalkan data Anda dari waktu ke waktu

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

  1. Bigtable mencoba menyimpan jumlah data yang kurang lebih sama di setiap node Bigtable.
  2. Bigtable mencoba mendistribusikan pembacaan dan penulisan secara merata ke semua node Bigtable.

Terkadang strategi ini bertentangan satu sama lain. Misalnya, jika baris suatu tablet sangat sering dibaca, Bigtable mungkin menyimpan tablet tersebut di node-nya sendiri, meskipun hal ini menyebabkan beberapa node menyimpan lebih banyak data daripada node yang lain.

Sebagai bagian dari proses ini, Bigtable juga dapat membagi tablet menjadi dua atau lebih tablet yang lebih kecil, untuk mengurangi ukuran tablet atau untuk mengisolasi hot row dalam tablet yang ada.

Bagian berikut menjelaskan setiap strategi tersebut secara lebih mendetail.

Mendistribusikan jumlah data di seluruh {i>node<i}

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

Jika data yang Anda tulis kurang dari beberapa GB ke tabel, Bigtable akan menyimpan semua tablet di satu node dalam cluster Anda:

Cluster dengan empat tablet di satu node.

Seiring bertambahnya jumlah tablet yang terakumulasi, Bigtable memindahkan sebagian tablet ke node lain dalam cluster sehingga jumlah data akan seimbang secara lebih merata di seluruh cluster:

Tablet tambahan didistribusikan ke beberapa node.

Mendistribusikan operasi baca dan tulis secara merata di seluruh node

Jika Anda telah merancang skema dengan benar, operasi baca dan tulis harus didistribusikan secara merata di seluruh tabel. Namun, ada beberapa kasus saat Anda tidak dapat menghindari akses ke baris tertentu lebih sering daripada baris yang lain. Bigtable membantu Anda menangani kasus ini dengan memperhitungkan operasi baca dan tulis saat menyeimbangkan tablet di seluruh node.

Misalnya, 25% pembacaan dilakukan ke sejumlah kecil tablet dalam suatu cluster, dan operasi baca tersebar secara merata di semua tablet lain:

Dari 48 tablet, 25% pembacaan akan menggunakan 3 tablet.

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

Tiga tablet hot diisolasi pada node-nya sendiri.

Menguji performa dengan Bigtable

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

  • Uji dengan data yang cukup.
    • Jika tabel dalam instance produksi Anda berisi total 100 GB data atau kurang per node, uji dengan tabel yang berisi jumlah data yang sama.
    • Jika tabel berisi lebih dari 100 GB data per node, uji dengan tabel yang berisi sedikitnya 100 GB data per node. Misalnya, jika instance produksi Anda memiliki satu cluster empat node, dan tabel dalam instance berisi total 1 TB data, jalankan pengujian Anda menggunakan tabel yang berukuran minimal 400 GB.
  • Menguji dengan satu tabel.
  • Tetap di bawah penggunaan penyimpanan yang direkomendasikan per node. Untuk mengetahui detailnya, lihat Penggunaan penyimpanan per node.
  • Sebelum menguji, jalankan pra-pengujian berat selama beberapa menit. Langkah ini memberi Bigtable kesempatan untuk menyeimbangkan data di seluruh node berdasarkan pola akses yang diamati.
  • 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 cache dari memori.

Memecahkan masalah performa

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

  • Lihat pemindaian Key Visualizer untuk tabel Anda. Alat Key Visualizer untuk Bigtable menghasilkan data pemindaian baru setiap 15 menit yang menunjukkan pola penggunaan untuk setiap tabel dalam cluster. Key Visualizer memungkinkan Anda memeriksa apakah pola penggunaan menyebabkan hasil yang tidak diinginkan, seperti hotspot di baris tertentu atau penggunaan CPU yang berlebihan. Pelajari cara mulai menggunakan Key Visualizer.
  • Cobalah menjadikan kode yang melakukan pembacaan dan penulisan Bigtable sebagai komentar. Jika masalah performa menghilang, Anda mungkin menggunakan BigQuery dengan cara yang menghasilkan performa yang kurang optimal. Jika masalah performa masih berlanjut, masalahnya mungkin tidak terkait dengan Bigtable.

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

    • Jika Anda menggunakan replikasi, atau jika menggunakan profil aplikasi untuk mengidentifikasi berbagai jenis traffic ke instance, 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 ke seluruh aplikasi Anda.

    Jika menggunakan klien HBase untuk Java, Anda harus membuat objek Connection dan bukan klien, sehingga Anda harus membuat koneksi sesedikit mungkin.

  • Pastikan Anda membaca dan menulis banyak baris yang berbeda di tabel Anda. Bigtable menghasilkan performa terbaik ketika operasi baca dan tulis didistribusikan secara merata di seluruh tabel Anda, sehingga membantu Bigtable mendistribusikan beban kerja ke semua node dalam cluster Anda. Jika operasi baca dan tulis tidak dapat disebarkan ke semua node Bigtable Anda, performa akan menurun.

    Jika Anda hanya membaca dan menulis sedikit baris, Anda mungkin perlu mendesain ulang skema agar operasi baca dan tulis terdistribusi lebih merata.

  • Pastikan Anda melihat performa operasi baca dan tulis yang kurang lebih sama. Jika ternyata operasi baca jauh lebih cepat daripada operasi tulis, Anda mungkin mencoba membaca tombol baris yang tidak ada, atau berbagai kunci baris yang hanya berisi sedikit baris.

    Untuk membuat perbandingan yang valid antara operasi baca dan tulis, Anda harus menargetkan minimal 90% pembacaan untuk menampilkan hasil yang valid. Selain itu, jika Anda membaca berbagai tombol baris, ukur performa berdasarkan jumlah baris sebenarnya dalam rentang tersebut, bukan jumlah maksimum baris yang dapat ada.

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

  • Periksa latensi untuk satu baris. Jika Anda mengamati latensi yang tidak terduga saat mengirim permintaan ReadRows, Anda dapat memeriksa latensi di 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 dengan Bigtable.

    Jika menggunakan library klien Bigtable untuk Java, Anda dapat melihat metrik read_rows_first_row_latency di Metrics Explorer di Konsol Google Cloud setelah mengaktifkan metrik sisi klien.

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

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

Langkah selanjutnya