Selamat siang Nama saya Danil Lipova, tim kami di Sbertech mulai menggunakan HBase sebagai repositori data operasional. Selama studinya, pengalaman diperoleh bahwa saya ingin mensistematisasikan dan menggambarkan (kami berharap itu akan bermanfaat bagi banyak orang). Semua percobaan di bawah ini dilakukan dengan versi HBase 1.2.0-cdh5.14.2 dan 2.0.0-cdh6.0.0-beta1.
- Arsitektur umum
- Menulis data ke HBASE
- Membaca data dari HBASE
- Caching data
- Pemrosesan Batch MultiGet / MultiPut
- Strategi memecah meja menjadi daerah (tumpah)
- Toleransi kesalahan, pemadatan dan lokalitas data
- Pengaturan dan kinerja
- Uji beban
- Kesimpulan
1. Arsitektur umum
Master siaga mendengarkan detak jantung aktif pada simpul ZooKeeper dan, jika menghilang, mengambil alih fungsi master.
2. Menulis data ke HBASE
Pertama, pertimbangkan case paling sederhana - menulis objek nilai kunci ke tabel tertentu menggunakan put (rowkey). Klien pertama-tama harus mencari tahu di mana root region server (RRS) yang menyimpan tabel hbase: meta berada. Dia menerima informasi ini dari ZooKeeper. Kemudian dia beralih ke RRS dan membaca tabel hbase: meta, dari mana dia mengambil informasi yang RegionServer (RS) bertanggung jawab untuk menyimpan data untuk kunci baris yang diberikan dalam tabel yang menarik baginya. Untuk penggunaan di masa mendatang, tabel meta di-cache oleh klien dan oleh karena itu panggilan selanjutnya menjadi lebih cepat, langsung ke RS.
Kemudian RS, setelah menerima permintaan tersebut, pertama-tama menulisnya ke WriteAheadLog (WAL), yang diperlukan untuk pemulihan jika terjadi kerusakan. Kemudian menyimpan data di MemStore. Ini adalah buffer dalam memori yang berisi sekumpulan tombol yang diurutkan untuk wilayah tertentu. Tabel dapat dibagi menjadi daerah (partisi), yang masing-masing berisi sekumpulan kunci yang terpisah. Ini memungkinkan penempatan wilayah pada server yang berbeda untuk mendapatkan kinerja yang lebih tinggi. Namun, meskipun pernyataan ini jelas, kita akan melihat nanti bahwa ini tidak berfungsi dalam semua kasus.
Setelah menempatkan catatan di MemStore, klien menerima respons bahwa catatan berhasil disimpan. Pada saat yang sama, itu benar-benar disimpan hanya dalam buffer dan sampai ke disk hanya setelah periode waktu tertentu berlalu atau ketika diisi dengan data baru.
Saat melakukan operasi "Hapus", penghapusan data fisik tidak terjadi. Mereka hanya ditandai sebagai dihapus, dan kehancuran itu sendiri terjadi ketika fungsi kompak utama disebut, yang dijelaskan secara lebih rinci dalam Bagian 7.
File dalam format HFile diakumulasikan dalam HDFS dan dari waktu ke waktu proses compact minor dimulai, yang hanya menempelkan file kecil menjadi yang lebih besar tanpa menghapus apa pun. Seiring waktu, ini berubah menjadi masalah yang memanifestasikan dirinya hanya ketika membaca data (kami akan kembali ke sini nanti).
Selain proses boot yang dijelaskan di atas, ada prosedur yang jauh lebih efisien, yang mungkin merupakan sisi paling kuat dari database ini - BulkLoad. Terdiri dari fakta bahwa kami secara mandiri membuat HFiles dan meletakkannya di disk, yang memungkinkan kami untuk menskala dengan sempurna dan mencapai kecepatan yang sangat baik. Faktanya, batasan di sini bukanlah HBase, tetapi kemungkinan zat besi. Di bawah ini adalah hasil memuat pada sebuah cluster yang terdiri dari 16 RegionServers dan 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 utas), versi HBase 1.2.0-cdh5.14.2.
Dapat dilihat bahwa dengan meningkatkan jumlah partisi (wilayah) dalam tabel, serta Spark yang dapat dieksekusi, kami memperoleh peningkatan kecepatan pengunduhan. Selain itu, kecepatan tergantung pada jumlah rekaman. Blok besar memberikan peningkatan dalam pengukuran MB / detik, yang kecil dalam jumlah catatan yang dimasukkan per satuan waktu, semua hal lain dianggap sama.
Anda juga dapat mulai memuat ke dalam dua tabel sekaligus dan mendapatkan kecepatan dua kali lipat. Dapat dilihat di bawah ini bahwa 10 blok KB ditulis ke dua tabel sekaligus dengan kecepatan masing-masing sekitar 600 Mb / s (total 1275 Mb / s), yang bertepatan dengan kecepatan tulis 623 MB / s ke satu tabel (lihat No. 11 di atas)
Tetapi peluncuran kedua dengan catatan 50 KB menunjukkan bahwa kecepatan unduh sudah sedikit tumbuh, yang menunjukkan perkiraan terhadap nilai batas. Harus diingat bahwa praktis tidak ada beban pada HBASE itu sendiri, yang diperlukan hanyalah memberikan data dari hbase: meta, dan setelah melapisi HFiles, siram data BlockCache dan simpan buffer MemStore ke disk jika tidak kosong
3. Membaca data dari HBASE
Jika kami mengasumsikan bahwa semua informasi dari hbase: meta sudah memiliki klien (lihat bagian 2), maka permintaan segera dikirim ke RS tempat kunci yang diinginkan disimpan. Pertama pencarian dilakukan di MemCache. Terlepas dari apakah ada data di sana atau tidak, pencarian juga dilakukan dalam buffer BlockCache dan, jika perlu, di HFiles. Jika data ditemukan dalam file, maka itu ditempatkan di BlockCache dan akan dikembalikan lebih cepat pada permintaan berikutnya. Pencarian HFile relatif cepat karena penggunaan filter Bloom, mis. Setelah membaca sejumlah kecil data, ia segera menentukan apakah file ini berisi kunci yang diinginkan dan, jika tidak, kemudian melanjutkan ke yang berikutnya.
Setelah menerima data dari ketiga sumber ini, RS membentuk tanggapan. Secara khusus, itu dapat mentransfer beberapa versi objek yang ditemukan sekaligus jika klien meminta versi.
4. Caching data
Buffer MemStore dan BlockCache menempati hingga 80% dari memori RS on-heap yang dialokasikan (sisanya dicadangkan untuk tugas layanan RS). Jika mode penggunaan khas sedemikian sehingga proses menulis dan segera membaca data yang sama, maka masuk akal untuk mengurangi BlockCache dan meningkatkan MemStore, karena ketika menulis data ke cache baca tidak jatuh, maka penggunaan BlockCache akan terjadi lebih jarang. Buffer BlockCache terdiri dari dua bagian: LruBlockCache (selalu on-heap) dan BucketCache (biasanya off-heap atau pada SSD). BucketCache harus digunakan ketika ada banyak permintaan baca dan mereka tidak cocok dengan LruBlockCache, yang mengarah ke pekerjaan aktif Pengumpul Sampah. Pada saat yang sama, Anda seharusnya tidak mengharapkan peningkatan radikal dalam kinerja dari menggunakan cache baca, tetapi kami akan kembali ke ini di Bagian 8
BlockCache adalah satu untuk seluruh RS, dan MemStore memiliki sendiri untuk setiap tabel (satu untuk setiap Keluarga Kolom).
Seperti yang
dijelaskan dalam teori, ketika menulis data tidak masuk ke cache, dan memang, parameter tersebut CACHE_DATA_ON_WRITE untuk tabel dan "Cache DATA on Write" untuk RS disetel ke false. Namun, dalam praktiknya, jika Anda menulis data ke MemStore, lalu menggelontorkannya ke disk (membersihkannya dengan cara ini), lalu hapus file yang dihasilkan, kemudian dengan menjalankan permintaan get, kami akan berhasil menerima data. Dan bahkan jika Anda sepenuhnya menonaktifkan BlockCache dan mengisi tabel dengan data baru, kemudian mendapatkan MemStore ke disk, hapus mereka dan minta dari sesi lain, mereka masih akan diambil dari suatu tempat. Jadi HBase tidak hanya menyimpan data, tetapi juga teka-teki misterius.
hbase(main):001:0> create 'ns:magic', 'cf' Created table ns:magic Took 1.1533 seconds hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me' Took 0.2610 seconds hbase(main):003:0> flush 'ns:magic' Took 0.6161 seconds hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash hbase(main):002:0> get 'ns:magic', 'key1' cf:c timestamp=1534440690218, value=try_to_delete_me
Cache DATA on Read diatur ke false. Jika Anda punya ide, selamat datang untuk membahas ini di komentar.
5. Pemrosesan Batch Data MultiGet / MultiPut
Memproses permintaan tunggal (Get / Put / Delete) adalah operasi yang agak mahal, jadi Anda harus menggabungkannya sebanyak mungkin dalam Daftar atau Daftar, yang memungkinkan Anda untuk mendapatkan peningkatan kinerja yang signifikan. Ini terutama berlaku untuk operasi penulisan, tetapi ketika membaca ada jebakan berikut. Grafik di bawah ini menunjukkan waktu pembacaan 50.000 catatan dari MemStore. Membaca dibuat dalam satu aliran dan sumbu horizontal menunjukkan jumlah tombol dalam permintaan. Dapat dilihat bahwa saat Anda menambah hingga seribu kunci dalam satu permintaan, waktu eksekusi turun, mis. kecepatan meningkat. Namun, ketika mode MSLAB dihidupkan secara default, setelah ambang ini, penurunan dramatis dalam kinerja dimulai, dan semakin besar jumlah data dalam catatan, semakin lama waktunya.
Pengujian dilakukan pada mesin virtual, 8 core, HBase versi 2.0.0-cdh6.0.0-beta1.
Mode MSLAB dirancang untuk mengurangi fragmentasi tumpukan, yang terjadi karena pencampuran data generasi baru dan lama. Sebagai solusi untuk masalah ketika MSLAB diaktifkan, data ditempatkan dalam sel yang relatif kecil (chunk) dan diproses dalam batch. Akibatnya, ketika volume dalam paket data yang diminta melebihi ukuran yang dialokasikan, kinerja turun tajam. Di sisi lain, mematikan mode ini juga tidak disarankan, karena akan menyebabkan berhenti karena GC selama saat-saat kerja intensif dengan data. Jalan keluar yang baik adalah meningkatkan volume sel, dalam hal penulisan aktif via put bersamaan dengan membaca. Perlu dicatat bahwa masalah tidak terjadi jika, setelah merekam, jalankan perintah flush yang mem-flush MemStore ke disk atau jika pemuatan dilakukan menggunakan BulkLoad. Tabel di bawah ini menunjukkan bahwa permintaan dari data MemStore dengan volume yang lebih besar (dan jumlah yang sama) menyebabkan perlambatan. Namun, meningkatkan chunksize mengembalikan waktu pemrosesan menjadi normal.
Selain meningkatkan chunksize, fragmentasi data menurut wilayah membantu, yaitu membelah meja. Ini mengarah pada fakta bahwa lebih sedikit permintaan datang ke masing-masing daerah dan jika mereka ditempatkan di sel, responsnya tetap baik.
6. Strategi membagi meja menjadi daerah (pemotongan)
Karena HBase adalah penyimpanan nilai-kunci dan partisi dilakukan oleh kunci, sangat penting untuk berbagi data secara merata di semua wilayah. Misalnya, mempartisi tabel seperti itu menjadi tiga bagian akan menghasilkan data yang dibagi menjadi tiga wilayah:
Kebetulan ini mengarah ke pelambatan tajam jika data yang dimuat di masa depan akan terlihat seperti, misalnya, nilai-nilai panjang, yang sebagian besar dimulai dengan angka yang sama, misalnya:
1000001
1000002
...
1100003
Karena kunci disimpan sebagai array byte, semuanya akan memulai dengan cara yang sama dan termasuk ke wilayah yang sama # 1 yang menyimpan rentang kunci ini. Ada beberapa strategi split:
HexStringSplit - Mengubah kunci menjadi string dengan pengkodean heksadesimal dalam kisaran "00000000" => "FFFFFFFF" dan mengisinya dengan nol di sebelah kiri.
UniformSplit - Mengubah kunci menjadi array byte dengan pengkodean heksadesimal dalam rentang "00" => "FF" dan mengisinya dengan nol di sebelah kanan.
Selain itu, Anda dapat menentukan rentang atau set kunci apa saja untuk dipisah dan mengatur pemisahan otomatis. Namun, salah satu pendekatan paling sederhana dan paling efektif adalah UniformSplit dan penggunaan gabungan hash, misalnya, sepasang byte tinggi dari menjalankan kunci melalui fungsi CRC32 (rowkey) dan rowkey itu sendiri:
hash + rowkey
Kemudian semua data akan didistribusikan secara merata di seluruh wilayah. Saat membaca, dua byte pertama dibuang begitu saja dan kunci aslinya tetap ada. RS juga mengontrol jumlah data dan kunci di wilayah tersebut dan ketika batas terlampaui, secara otomatis memecahnya menjadi beberapa bagian.
7. Toleransi kesalahan dan lokalitas data
Karena hanya satu wilayah yang bertanggung jawab untuk setiap rangkaian kunci, solusi untuk masalah yang terkait dengan crash atau decommissioning RS adalah dengan menyimpan semua data yang diperlukan dalam HDFS. Ketika RS crash, master mendeteksi ini melalui tidak adanya detak jantung pada node ZooKeeper. Kemudian ia menugaskan wilayah yang dilayani ke RS lain dan karena HFiles disimpan dalam sistem file terdistribusi, host baru membacanya dan terus melayani data. Namun, karena beberapa data mungkin ada di MemStore dan tidak punya waktu untuk masuk ke HFiles, WAL, yang juga disimpan dalam HDFS, digunakan untuk memulihkan sejarah operasi. Setelah roll-over dari perubahan, RS mampu menanggapi permintaan, namun, langkah itu mengarah pada fakta bahwa bagian dari data dan proses mereka berada pada node yang berbeda, yaitu. penurunan lokalitas.
Solusi untuk masalah ini adalah pemadatan besar - prosedur ini memindahkan file ke node yang bertanggung jawab untuk mereka (di mana wilayah mereka berada), sebagai akibatnya beban pada jaringan dan disk meningkat tajam selama prosedur ini. Namun, di masa depan, akses ke data terasa dipercepat. Selain itu, major_compaction menggabungkan semua HFiles ke dalam satu file di kawasan, dan juga membersihkan data tergantung pada pengaturan tabel. Misalnya, Anda dapat menentukan jumlah versi dari objek yang ingin Anda simpan atau masa pakainya, setelah itu objek dihapus secara fisik.
Prosedur ini dapat memiliki efek yang sangat positif pada HBase. Gambar di bawah ini menunjukkan bagaimana kinerja menurun akibat perekaman data aktif. Di sini Anda dapat melihat bagaimana 40 stream ditulis ke satu tabel dan 40 stream membaca data pada saat yang sama. Menulis stream membentuk semakin banyak HFiles, yang dibaca oleh stream lain. Akibatnya, semakin banyak data yang perlu dihapus dari memori dan pada akhirnya GC mulai bekerja, yang secara praktis melumpuhkan semua pekerjaan. Peluncuran pemadatan besar menyebabkan pembersihan penyumbatan yang dihasilkan dan pemulihan kinerja.
Pengujian dilakukan pada 3 DataNode dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase Versi 1.2.0-cdh5.14.2
Perlu dicatat bahwa peluncuran pemadatan besar dilakukan pada tabel “langsung”, di mana data ditulis dan dibaca secara aktif. Ada pernyataan di jaringan bahwa ini dapat menyebabkan jawaban yang salah saat membaca data. Untuk memeriksa, sebuah proses diluncurkan yang menghasilkan data baru dan menulisnya di atas meja. Setelah itu saya langsung membaca dan memverifikasi apakah nilai yang didapat sesuai dengan yang dicatat. Selama proses ini, pemadatan besar diluncurkan sekitar 200 kali dan tidak ada satu kegagalan pun yang tercatat. Mungkin masalah jarang muncul dan hanya selama beban tinggi, jadi lebih aman untuk tetap menghentikan proses penulisan dan baca secara terjadwal dan melakukan pembersihan tanpa mengizinkan penarikan GC seperti itu.
Selain itu, pemadatan besar tidak memengaruhi status MemStore, untuk mem-flush-nya ke disk dan memadat, Anda perlu menggunakan flush (connection.getAdmin (). Flush (TableName.valueOf (tblName)))).
8. Pengaturan dan kinerja
Seperti yang telah disebutkan, HBase menunjukkan keberhasilan terbesar di mana ia tidak perlu melakukan apa pun ketika menjalankan BulkLoad. Namun, ini berlaku untuk sebagian besar sistem dan orang. Namun, alat ini lebih cocok untuk penumpukan massal data dalam blok besar, sedangkan jika prosesnya membutuhkan banyak permintaan baca dan tulis yang bersaing, perintah Get and Put yang dijelaskan di atas digunakan. Untuk menentukan parameter optimal, peluncuran dilakukan dengan berbagai kombinasi parameter tabel dan pengaturan:
- 10 utas dimulai pada waktu yang sama 3 kali berturut-turut (sebut saja blok utas).
- Waktu operasi semua aliran di blok adalah rata-rata dan merupakan hasil akhir dari operasi blok.
- Semua utas bekerja dengan tabel yang sama.
- Sebelum setiap dimulainya blok utas, pemadatan besar dilakukan.
- Setiap blok hanya melakukan satu dari operasi berikut:
- Taruh
- dapatkan
- Dapatkan + Pasang
- Setiap blok melakukan 50.000 pengulangan operasinya.
- Ukuran rekaman dalam blok adalah 100 byte, 1000 byte atau 10.000 byte (acak).
- Blok diluncurkan dengan jumlah berbeda dari kunci yang diminta (baik satu kunci atau 10).
- Blok diluncurkan pada berbagai pengaturan tabel. Parameter berubah:
- BlockCache = dihidupkan atau dimatikan
- BlockSize = 65 Kb atau 16 Kb
- Partisi = 1, 5 atau 30
- MSLAB = hidup atau mati
Jadi, bloknya terlihat seperti ini:
a. Mode MSLAB dihidupkan / dimatikan.
b. Tabel dibuat dengan parameter yang ditetapkan: BlockCache = true / none, BlockSize = 65/16 Kb, Partitions = 1/5/30.
c. Atur kompresi GZ.
d. 10 utas diluncurkan secara bersamaan melakukan 1/10 operasi put / get / get + put di tabel ini dengan catatan 100/1000/10000 byte, mengeksekusi 50.000 kueri berturut-turut (kunci acak).
e. Poin d diulang tiga kali.
f. Waktu operasi semua utas adalah rata-rata.
Semua kemungkinan kombinasi diperiksa. Dapat diprediksi bahwa seiring dengan meningkatnya ukuran perekaman, kecepatan akan turun atau penonaktifan caching akan melambat. Namun, tujuannya adalah untuk memahami tingkat dan signifikansi pengaruh masing-masing parameter, oleh karena itu, data yang dikumpulkan diumpankan ke input fungsi regresi linier, yang memungkinkan untuk mengevaluasi keandalan menggunakan t-statistik. Di bawah ini adalah hasil dari blok yang melakukan operasi Put. Seperangkat kombinasi lengkap 2 * 2 * 3 * 2 * 3 = 144 opsi + 72 sejak beberapa dilakukan dua kali. Oleh karena itu, total 216 peluncuran:
Pengujian dilakukan pada mini-cluster yang terdiri dari 3 DataNode dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 stream). HBase versi 1.2.0-cdh5.14.2.
Kecepatan penyisipan tertinggi 3,7 detik diperoleh ketika mode MSLAB dimatikan, di atas meja dengan satu partisi, dengan BlockCache diaktifkan, BlockSize = 16, catatan 100 byte dari 10 buah per paket.
Kecepatan penyisipan terendah 82,8 detik diperoleh ketika mode MSLAB diaktifkan, di atas meja dengan satu partisi, dengan BlockCache diaktifkan, BlockSize = 16, catatan masing-masing 10.000 byte.
Sekarang mari kita lihat modelnya. Kami melihat model kualitas yang baik untuk R2, tetapi jelas bahwa ekstrapolasi dikontraindikasikan di sini. Perilaku aktual sistem ketika mengubah parameter tidak akan linier, model ini tidak diperlukan untuk perkiraan, tetapi untuk memahami apa yang terjadi dalam parameter yang diberikan. Sebagai contoh, di sini kita melihat dengan kriteria Siswa bahwa untuk operasi Put, parameter BlockSize dan BlockCache tidak masalah (yang umumnya dapat diprediksi):
Tetapi fakta bahwa peningkatan jumlah partisi menyebabkan penurunan kinerja agak tak terduga (kita telah melihat efek positif dari peningkatan jumlah partisi dengan BulkLoad), meskipun hal itu dapat dimengerti. Pertama, untuk pemrosesan, perlu untuk membentuk kueri ke 30 wilayah, bukan satu, dan jumlah data tidak sedemikian sehingga memberikan keuntungan. Kedua, total waktu operasi ditentukan oleh RS paling lambat, dan karena jumlah DataNode kurang dari jumlah RS, beberapa daerah memiliki nol lokalitas. Baiklah, mari kita lihat lima besar:
Sekarang mari kita mengevaluasi hasil dari pelaksanaan blok Dapatkan:
Jumlah partisi telah kehilangan signifikansi, yang mungkin disebabkan oleh fakta bahwa data di-cache dengan baik dan cache baca adalah parameter yang paling signifikan (secara statistik). Secara alami, meningkatkan jumlah pesan dalam permintaan juga sangat berguna untuk kinerja. Hasil terbaik:
Nah, akhirnya, lihat model blok yang dieksekusi get first, lalu taruh:
Di sini semua parameter signifikan. Dan hasil dari para pemimpin:
9. Memuat pengujian
Yah, akhirnya, kami akan meluncurkan muatan yang lebih atau kurang layak, tetapi selalu lebih menarik ketika ada sesuatu untuk dibandingkan. Situs DataStax, pengembang kunci Cassandra, memiliki
hasil NT dari sejumlah repositori NoSQL, termasuk HBase versi 0.98.6-1. Pemuatan dilakukan oleh 40 stream, ukuran data 100 byte, disk SSD. Hasil pengujian operasi Baca-Ubah-Tulis menunjukkan hasil ini.
Seperti yang saya pahami, pembacaan dilakukan dalam blok 100 catatan dan selama 16 node HBase, tes DataStax menunjukkan kinerja 10 ribu operasi per detik.
Sangat beruntung bahwa cluster kami juga memiliki 16 node, tetapi tidak terlalu "beruntung" yang masing-masing memiliki 64 core (utas), sedangkan uji DataStax hanya memiliki 4. Di sisi lain, mereka memiliki disk SSD, dan kami memiliki HDD dan lebih banyak lagi versi baru pemanfaatan HBase dan CPU selama pemuatan praktis tidak meningkat secara signifikan (secara visual sebesar 5-10 persen). Namun demikian, kami akan mencoba memulai konfigurasi ini. Pengaturan tabel secara default, pembacaan dilakukan dalam rentang tombol dari 0 hingga 50 juta secara acak (mis., Pada kenyataannya, setiap kali yang baru). Dalam tabel, 50 juta entri dibagi menjadi 64 partisi. Kunci hash crc32. Pengaturan tabel default, MSLAB diaktifkan. Mulai 40 utas, setiap utas membaca satu set 100 kunci acak dan segera menulis 100 byte yang dihasilkan pada kunci ini kembali.
Stand: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 stream). HBase versi 1.2.0-cdh5.14.2.
Hasil rata-rata lebih dekat dengan 40 ribu operasi per detik, yang secara signifikan lebih baik daripada dalam tes DataStax. Namun, untuk keperluan percobaan, kondisinya dapat sedikit berubah. Sangat tidak mungkin bahwa semua pekerjaan akan dilakukan secara eksklusif dengan satu meja, serta hanya dengan kunci yang unik. Misalkan ada set kunci "panas" tertentu yang menghasilkan beban utama. Oleh karena itu, kami akan mencoba membuat beban dengan catatan lebih besar (10 KB), juga dalam paket masing-masing 100, dalam 4 tabel yang berbeda dan membatasi rentang kunci yang diminta hingga 50 ribu. Grafik di bawah ini menunjukkan awal dari 40 utas, setiap aliran membaca satu set 100 kunci dan segera menulis secara acak 10 KB pada tombol ini kembali.
Stand: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 stream). HBase versi 1.2.0-cdh5.14.2.
Selama pemuatan, pemadatan besar diluncurkan beberapa kali, seperti yang ditunjukkan di atas tanpa prosedur ini, kinerja akan berangsur-angsur menurun, namun, beban tambahan juga terjadi selama eksekusi. Penarikan disebabkan oleh berbagai alasan. Kadang-kadang utas dihentikan dan sementara mereka memulai kembali ada jeda, kadang-kadang aplikasi pihak ketiga membuat beban pada kluster.
Membaca dan menulis segera adalah salah satu skenario pekerjaan yang paling sulit untuk HBase. Jika Anda hanya menaruh permintaan berukuran kecil, misalnya, masing-masing 100 byte, menggabungkannya menjadi 10 hingga 10 ribu lembar, Anda bisa mendapatkan ratusan ribu operasi per detik dan situasinya mirip dengan permintaan hanya baca. Perlu dicatat bahwa hasilnya secara radikal lebih baik daripada yang diperoleh di DataStax terutama karena permintaan dalam blok 50 ribu.
Stand: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 stream). HBase versi 1.2.0-cdh5.14.2.
10. Kesimpulan
Sistem ini cukup fleksibel untuk dikonfigurasi, tetapi efek dari sejumlah besar parameter masih belum diketahui. Beberapa dari mereka diuji, tetapi tidak termasuk dalam suite tes yang dihasilkan. Misalnya, percobaan awal menunjukkan tidak signifikannya parameter seperti DATA_BLOCK_ENCODING, yang menyandikan informasi menggunakan nilai dari sel tetangga, yang cukup dapat dimengerti untuk data yang dihasilkan secara acak. Dalam hal menggunakan sejumlah besar objek berulang, gain bisa signifikan. Secara umum, kita dapat mengatakan bahwa HBase memberi kesan database yang agak serius dan dipikirkan dengan matang, yang bisa sangat produktif ketika berhadapan dengan blok data besar. Terutama jika memungkinkan untuk menyebarkan proses membaca dan menulis dalam waktu.
Jika sesuatu menurut Anda tidak cukup diungkapkan, saya siap untuk memberi tahu secara lebih rinci. Kami sarankan untuk berbagi pengalaman atau berdebat jika Anda tidak setuju dengan sesuatu.