Saat menjalankan alat benchmark kinerja apa pun di cluster Anda, keputusan penting selalu adalah ukuran kumpulan data apa yang harus digunakan untuk pengujian kinerja, dan di sini kami menunjukkan mengapa penting untuk memilih ukuran kumpulan data yang "cocok" saat menjalankan kinerja HBase uji di cluster Anda.
Konfigurasi klaster HBase dan ukuran kumpulan data dapat memvariasikan kinerja beban kerja Anda dan hasil pengujian pada klaster yang sama. Anda harus memilih ukuran kumpulan data ini berdasarkan apa yang Anda coba pahami tentang kinerja cluster Anda. Untuk menunjukkan perbedaan antara set kerja yang sesuai dengan cache memori yang tersedia dan yang harus dibaca dari penyimpanan yang mendasarinya, kami menjalankan 2 pengujian beban kerja YCSB dengan ukuran set data yang dipilih secara tepat pada CDP Private Cloud Base 7.2.2 Operation Database cluster yang sama. Kami menggunakan ukuran kumpulan data 40 GB vs 1 TB dan throughput untuk beban kerja YCSB yang berbeda dibandingkan di bawah, di bagan semakin tinggi bilah semakin baik throughput.
Catatan:Throughput =Operasi per detik
Saat aplikasi mencoba membaca dari cluster HBase, Server Wilayah yang menangani permintaan terlebih dahulu memeriksa apakah hasil yang diperlukan berada dalam blok data yang sudah lokal untuk prosesnya melalui cache bloknya. Jika blok data ada maka permintaan klien dapat dilayani langsung dari cache dan ini dihitung sebagai hit cache. Namun, jika blok saat ini tidak lokal ke proses Server Wilayah maka itu dihitung sebagai kehilangan cache dan harus dibaca dari HFile di penyimpanan HDFS. Bergantung pada pemanfaatan cache, blok itu kemudian akan disimpan dalam cache untuk permintaan di masa mendatang.
Seperti yang diharapkan dan terlihat di bagan ringkasan, beban kerja di mana sebagian besar kumpulan data muat dalam cache memiliki latensi yang lebih rendah dan throughput jauh lebih tinggi vs beban kerja yang dijalankan di mana data diakses dari HFiles dalam penyimpanan hdfs.
Untuk memilih ukuran kumpulan data beban kerja agar dapat memenuhi sasaran pengujian dengan baik, penting untuk memeriksa ukuran heap RegionServer, cache L1 dan L2, cache buffer OS, lalu menyetel ukuran kumpulan data yang sesuai. Setelah menjalankan beban kerja YCSB telah menyelesaikan parameter yang baik untuk diperiksa sebagai cara untuk memverifikasi bahwa segala sesuatunya berjalan seperti yang diharapkan adalah berapa banyak data yang dilayani dari cache (cache hit) dan berapa banyak yang diakses dari penyimpanan hdfs. Rasio hit cache Server Wilayah ini terhadap total permintaan baca adalah rasio hit cache.
Anda dapat menemukan info ini dari konfigurasi rasio hit cache L1 "l1CacheHitRatio". Jika Anda memiliki cache L1 dan L2 yang ditetapkan di cluster Anda, maka cache L1 melayani blok indeks dan cache L2 melayani blok data, dan Anda dapat merekam konfigurasi L1 "l1CacheHitRatio" dan L2 "l2CacheHitRatio" untuk referensi.
Sisa dari entri blog ini akan membahas detail penyiapan pengujian kami, memilih ukuran kumpulan data, dan kemudian menjalankan YCSB dengan ukuran kumpulan data tersebut.
Konfigurasi cluster HBase digunakan untuk pengujian ini:
- Kluster yang digunakan : 6 node cluster (1 master + 5 server wilayah)
- Deskripsi: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2.2Ghz, Ram 128GB, disk 4-2TB
- Keamanan: Tidak ada yang dikonfigurasi (Tanpa Kerberos)
- versi CDP: CDP Private Cloud Base 7.2.2 6 node HBase cluster dengan 1 Master + 5 Server Wilayah
- JDK menggunakan jdk1.8_232
- Server Wilayah HBase dikonfigurasi dengan heap 32 GB
- Master HBase dikonfigurasi dengan tumpukan 4GB
- Cache L1 dengan LruBlockCache digunakan dengan ukuran cache 12,3 GB
- Total L1 cache dalam cluster adalah 61 GB (12,3 * 5 =61 GB)
- L2 off heap cache tidak dikonfigurasi di cluster
Sizing Case 1:Data benar-benar cocok dengan cache yang tersedia di cluster
Di cluster HBase kami, kami mengonfigurasi total 61GB (12,3GB *5) di 5 server wilayah yang dialokasikan untuk cache blok L1. Untuk kumpulan data yang sepenuhnya sesuai dengan cache, kami memilih kumpulan data yang berukuran 40GB dalam ukuran.
Sizing Case 2:Kumpulan data lebih besar dari cache yang tersedia di cluster
Untuk skenario kedua kami ingin data menjadi jauh lebih besar dari cache yang tersedia. Untuk memilih ukuran kumpulan data yang sesuai, kami melihat cache blok HBase yang dikonfigurasi dan cache buffer OS di cluster. Dalam cluster HBase kami yang diberikan, cache blok L1 yang dikonfigurasi adalah 61G ketika dikumpulkan di seluruh RegionServers. Node server memiliki total 128G RAM masing-masing dan memori apa pun yang tidak didedikasikan untuk proses server dapat digunakan oleh OS untuk secara efektif men-cache blok HDFS yang mendasarinya dan meningkatkan throughput secara keseluruhan. Dalam konfigurasi pengujian kami, ada sekitar 96G OS cache yang tersedia di setiap node server wilayah untuk tujuan ini (mengabaikan memori yang digunakan oleh DataNode atau proses OS untuk menyederhanakan banyak hal). Menggabungkan ini di 5 server wilayah, kami memiliki potensi hampir 500G untuk buffer (server wilayah 96G * 5). Jadi kami memilih ukuran kumpulan data 1 TB, melebihi cache blok yang dikonfigurasi dan cache buffer OS yang tersedia.
Mengubah Ukuran Data Target menjadi parameter YCSB
Di YCSB, satu baris secara default berukuran 1KB, jadi tergantung pada berapa banyak baris yang Anda muat ke dalam 'tabel pengguna' YCSB, Anda dapat dengan mudah memperkirakan ukuran data tabel 'dapat digunakan' YCSB Anda. Jadi, jika Anda mengupload 1 juta baris, Anda telah mengupload 1.000.000 * 1KB =1GB data ke dalam 'usertable' YCSB.
Ukuran kumpulan data yang digunakan untuk dua pengujian kami adalah:
- Data 40 GB dengan 40 juta baris
- Data 1 TB dengan 1 miliar baris
Metodologi Tes
CDP Private Cloud Base 7.2.2 diinstal pada kluster 6 node dan data beban kerja dengan 40 juta baris (ukuran kumpulan data total => 40 GB ) dihasilkan dan beban kerja YCSB dijalankan. Setelah memuat, kami menunggu semua operasi pemadatan selesai sebelum memulai pengujian beban kerja.
Beban kerja YCSB yang dijalankan pada HBase adalah
- Beban Kerja A:50% Baca dan 50% Pembaruan
- Beban Kerja C:100% Dibaca
- Beban Kerja F:50% Baca dan 50% Perbarui/Baca-Ubah-Tulis rasio:50/50
- Beban kerja Khusus Pembaruan Khusus:Pembaruan 100%
Setiap beban kerja YCSB (A, C, F dan UpdateOnly) dijalankan masing-masing selama 15 menit, dan proses lengkap diulang 5 kali tanpa dimulai ulang di antara proses untuk mengukur throughput YCSB*. Hasil yang ditampilkan adalah rata-rata yang diambil untuk 3 run terakhir dari 5 run. 2 uji coba pertama diabaikan untuk menghindari penalti lari pertama dan kedua.
Setelah proses 40 GB selesai, kami menghapus tabel pengguna dan membuat ulang 1 miliar baris untuk membuat ukuran kumpulan data 1 TB dan menjalankan ulang pengujian dengan metodologi yang sama pada cluster yang sama.
Hasil Tes
Hasil YCSB dengan 40GB
Dalam kasus 40GB, data dapat sepenuhnya masuk ke dalam cache L1 61GB di cluster. Rasio hit cache L1 yang diamati di cluster selama pengujian mendekati 99%.
Kiat: Untuk kumpulan data yang lebih kecil di mana data dapat masuk ke dalam cache, kami juga dapat menggunakan opsi cache saat memuat dan melakukan pemanasan awal cache untuk mendapatkan rasio hit cache 100% menggunakan opsi tabel PREFETCH_BLOCKS_ON_OPEN
Kami menjalankan setiap beban kerja YCSB selama 15 menit setiap 5 kali dan mengambil rata-rata dari 3 putaran terakhir untuk menghindari penalti putaran pertama.
Hasil terlihat dengan 40G L1 cache hit ratio 99% pada server wilayah ditunjukkan di bawah dalam tabel:
| Operasi | Num Ops | Troughput | Latensi Rata-Rata | 95 Latensi | 99 Latensi |
| (Jumlah operasi/detik) | (md) | (md) | (md) | ||
| Beban Kerja C | 148558364 | 165063 | 0,24 | 0,30 | 0,48 |
| Hanya Pembaruan | 56727908 | 63030 | 0.63 | 0,78 | 1,57 |
| Beban Kerja A | 35745710 | 79439 | 0,40 | 0,54 | 0,66 |
| Beban Kerja F | 24823285 | 55157 | 0,58 | 0,70 | 0,96 |
Hasil YCSB dengan kumpulan data 1 TB
Dalam kasus 1TB, data tidak sesuai dengan cache L1 61GB di cluster atau cache buffer OS 500GB. Rasio hit cache L1 di cluster yang diamati selama pengujian adalah 82-84%.
Kami menjalankan setiap beban kerja selama 15 menit setiap 5 kali, dan mengambil rata-rata dari 3 putaran terakhir untuk menghindari penalti putaran pertama.
Hasil terlihat dengan 1 TB Rasio hit cache L1 82-84% pada server wilayah ditunjukkan di bawah dalam tabel:
| Operasi | Num Ops | Troughput | Latensi Rata-Rata | 95 Latensi | 99 Latensi |
| (Jumlah operasi/detik) | (md) | (md) | (md) | ||
| Beban Kerja C | 2727037 | 3030 | 13.19 | 55,50 | 110,85 |
| Hanya Pembaruan | 56345498 | 62605 | 0,64 | 0,78 | 1,58 |
| Beban Kerja A | 3085135 | 6855 | 10,88 | 48,34 | 97,70 |
| Beban Kerja F | 3333982 | 3704 | 10,45 | 47,78 | 98,62 |
*Throughput (ops/sec) =Jumlah operasi per detik
Analisis:
Membandingkan hasil pengujian untuk dua ukuran kumpulan data yang berbeda di atas, kita dapat melihat bagaimana throughput beban kerja yang sama dapat bervariasi dari 3K operasi per detik hingga 165K operasi per detik saat data diakses lebih cepat dari kumpulan data 40G dengan cache yang dihangatkan vs dari penyimpanan hdfs.
Bagan di bawah ini menunjukkan throughput dan membandingkan bagaimana throughput berubah untuk beban kerja yang berbeda saat dijalankan dengan 2 set data ukuran berbeda. Di bagan, semakin tinggi bilah semakin baik throughputnya.
Catatan:Throughput =Operasi per detik
Seperti yang terlihat pada bagan, beban kerja YCSB yang membaca data seperti Beban Kerja A, Beban Kerja C, dan Beban Kerja F memiliki throughput yang jauh lebih baik dalam kasus 40G di mana data dengan mudah masuk ke dalam cache vs kasus ukuran data 1TB di mana data HFile harus disimpan. diakses dari HDFS
Melihat rasio hit cache, set data 40G memiliki rasio hit cache mendekati 99%, dan set data 1TB memiliki rasio hit cache sekitar 85%, jadi 15% data dalam kasus 1TB diakses dari penyimpanan hdfs .
Beban kerja khusus pembaruan khusus YCSB yang kami jalankan memiliki throughput yang sama di kedua kasus karena hanya melakukan pembaruan dan tidak membaca.
Selama kinerja HBase, kami mengamati secara dekat latensi persentil ke-95 dan ke-99. Latensi rata-rata hanyalah throughput total dibagi dengan total waktu namun persentil ke-95 dan persentil ke-99 menunjukkan outlier nyata yang memengaruhi total throughput beban kerja. Dalam kasus 1 TB, outlier latensi tinggi di persentil ke-95 dan ke-99 menyebabkan throughput melambat, dan dalam kasus 40 GB cache latensi rendah mencapai persentil ke-99 menyebabkan peningkatan total throughput.
Bagan di bawah menunjukkan perbandingan latensi untuk latensi rata-rata, latensi persentil ke-95, dan latensi persentil ke-99 serta perbedaannya untuk beban kerja yang berbeda saat dijalankan dengan kumpulan data ukuran yang berbeda.
Pada diagram di atas, sulit untuk melihat bilah yang menunjukkan latensi untuk kumpulan data 40 GB karena sangat rendah dibandingkan dengan latensi yang diamati untuk kumpulan data 1 TB yang mengakses data dari hdfs.
Kami memplot grafik latency menggunakan log dari nilai latency untuk menunjukkan perbedaan pada grafik di bawah
Seperti yang terlihat di atas, latensi jauh lebih rendah dalam kasus 40GB di mana rasio hit cache mendekati 99% dan sebagian besar data beban kerja tersedia di cache. Sebagai perbandingan untuk kumpulan data 1TB, rasio cache hit sekitar 85% karena data HFile harus diakses dari penyimpanan HDFS.
Rata-rata dan 99 latensi untuk Beban Kerja C dalam kasus 40G di mana 99% data dikembalikan dari cache yang dihangatkan adalah sekitar 2 – 4 ms. Latensi persentil ke-99 untuk Beban Kerja C yang sama dalam kasus 1 TB adalah sekitar 100 md untuk Beban Kerja C (beban kerja hanya baca).
Ini menunjukkan bahwa cache hit dari cache blok on-heap mengembalikan pembacaan dalam waktu sekitar 2 mdtk dan kehilangan cache serta mendapatkan catatan dari HDFS dapat memakan waktu sekitar 100 mdtk pada cluster ini.
Rekomendasi:
Saat menjalankan uji pembandingan YCSB, ukuran kumpulan data membuat perbedaan substansial dalam hasil kinerja, dan oleh karena itu menentukan ukuran uji dengan tepat sangat penting. Pada saat yang sama, melihat rasio cache hit dan perbedaan latensi antara latensi min dan ke-99 akan membantu Anda menemukan latensi cache-hit dibandingkan dengan saat data diakses dari penyimpanan dasar di cluster.
Kiat:
Untuk memeriksa rasio hit cache dari beban kerja Anda di server wilayah, Anda dapat menggunakan perintah di bawah ini
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
Anda juga dapat melihat rasio Cache Hit dari UI Web HBase dengan mengikuti langkah-langkah di bawah ini:
- Dari UI Web HBase, klik server wilayah
- Di bawah bagian Blokir cache, pilih L1 (dan L2 jika L2 dikonfigurasi) untuk meninjau rasio hit cache.
Tangkapan layar yang menunjukkan rasio hit cache dari cache blok L1 ditunjukkan di bawah ini:
Berikut ini tautan ke info lebih lanjut seputar tangkapan layar HBase yang ditunjukkan di atas dan blokir cache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
Tentang YCSB
YCSB adalah spesifikasi sumber terbuka dan rangkaian program untuk mengevaluasi kemampuan pengambilan dan pemeliharaan program komputer. Ini adalah alat yang sangat populer digunakan untuk membandingkan kinerja relatif sistem manajemen basis data NoSQL.
Untuk menggunakan YCSB guna menguji kinerja Database Operasional, lihat blog Cara Menjalankan YCSB untuk HBase
