Teori dan praktek penggunaan HBase

Selamat siang Nama saya Danil Lipovoy, tim kami di Sbertech mulai menggunakan HBase sebagai penyimpanan data operasional. Selama mempelajarinya, telah terkumpul pengalaman yang ingin saya sistematiskan dan uraikan (semoga bermanfaat bagi banyak orang). Semua percobaan di bawah ini dilakukan dengan HBase versi 1.2.0-cdh5.14.2 dan 2.0.0-cdh6.0.0-beta1.

1. Arsitektur umum
2. Menulis data ke HBASE
3. Membaca data dari HBASE
4. Caching data
5. Pemrosesan data batch MultiGet/MultiPut
6. Strategi pemisahan tabel menjadi beberapa wilayah (splitting)
7. Toleransi kesalahan, pemadatan, dan lokalitas data
8. Pengaturan dan kinerja
9. Pengujian Stres
10. Temuan

1. Arsitektur umum

Master cadangan mendengarkan detak jantung yang aktif di node ZooKeeper dan, jika hilang, mengambil alih fungsi master.

2. Tulis data ke HBASE

Pertama, mari kita lihat kasus paling sederhana - menulis objek nilai kunci ke tabel menggunakan put(rowkey). Klien harus terlebih dahulu mencari tahu di mana Root Region Server (RRS), yang menyimpan tabel hbase:meta, berada. Dia menerima informasi ini dari ZooKeeper. Setelah itu ia mengakses RRS dan membaca tabel hbase:meta, yang darinya ia mengekstrak informasi tentang RegionServer (RS) mana yang bertanggung jawab untuk menyimpan data untuk kunci baris tertentu dalam tabel yang diinginkan. Untuk penggunaan di masa depan, tabel meta di-cache oleh klien dan oleh karena itu panggilan berikutnya berjalan lebih cepat, langsung ke RS.

Selanjutnya, RS, setelah menerima permintaan, pertama-tama menulisnya ke WriteAheadLog (WAL), yang diperlukan untuk pemulihan jika terjadi kegagalan. Kemudian menyimpan data ke MemStore. Ini adalah buffer di memori yang berisi sekumpulan kunci yang diurutkan untuk wilayah tertentu. Sebuah tabel dapat dibagi menjadi beberapa wilayah (partisi), yang masing-masing berisi sekumpulan kunci yang terpisah-pisah. Ini memungkinkan Anda menempatkan wilayah di server berbeda untuk mencapai kinerja yang lebih tinggi. Namun, terlepas dari pernyataan ini yang jelas, nanti kita akan melihat bahwa hal ini tidak berhasil di semua kasus.

Setelah menempatkan entri di MemStore, respons dikembalikan ke klien bahwa entri berhasil disimpan. Namun pada kenyataannya hanya disimpan dalam buffer dan sampai ke disk hanya setelah jangka waktu tertentu berlalu atau ketika diisi dengan data baru.

Saat melakukan operasi “Hapus”, data tidak dihapus secara fisik. Mereka hanya ditandai sebagai dihapus, dan penghancuran itu sendiri terjadi pada saat fungsi kompak utama dipanggil, yang dijelaskan lebih rinci di paragraf 7.

File dalam format HFile diakumulasikan dalam HDFS dan dari waktu ke waktu proses pemadatan kecil diluncurkan, yang hanya menggabungkan file kecil menjadi file yang lebih besar tanpa menghapus apa pun. Seiring waktu, ini berubah menjadi masalah yang hanya muncul saat membaca data (kita akan membahasnya nanti).

Selain proses pemuatan yang dijelaskan di atas, ada prosedur yang jauh lebih efektif, yang mungkin merupakan keunggulan database ini - BulkLoad. Itu terletak pada kenyataan bahwa kami secara mandiri membentuk HFiles dan menaruhnya di disk, yang memungkinkan kami untuk menskalakan dengan sempurna dan mencapai kecepatan yang sangat baik. Sebenarnya yang menjadi batasan di sini bukanlah HBase, melainkan kemampuan hardwarenya. Di bawah ini adalah hasil booting pada cluster yang terdiri dari 16 RegionServers dan 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread), HBase versi 1.2.0-cdh5.14.2.

Di sini Anda dapat melihat bahwa dengan menambah jumlah partisi (wilayah) dalam tabel, serta eksekutor Spark, kami memperoleh peningkatan kecepatan pengunduhan. Selain itu, kecepatannya tergantung pada volume rekaman. Blok besar memberikan peningkatan dalam MB/detik, blok kecil dalam jumlah catatan yang disisipkan per unit waktu, semua hal lain dianggap sama.

Anda juga dapat mulai memuat ke dalam dua tabel secara bersamaan dan mendapatkan kecepatan dua kali lipat. Di bawah ini Anda dapat melihat bahwa penulisan blok 10 KB ke dua tabel sekaligus terjadi pada kecepatan masing-masing sekitar 600 MB/detik (total 1275 MB/detik), yang bertepatan dengan kecepatan penulisan ke satu tabel 623 MB/detik (lihat No. 11 di atas)

Namun proses kedua dengan catatan 50 KB menunjukkan bahwa kecepatan unduh sedikit meningkat, yang menandakan mendekati nilai batas. Pada saat yang sama, Anda harus ingat bahwa praktis tidak ada beban yang dibuat pada HBASE itu sendiri, yang diperlukan hanyalah memberikan data dari hbase:meta terlebih dahulu, dan setelah melapisi HFiles, setel ulang data BlockCache dan simpan Buffer MemStore ke disk, jika tidak kosong.

3. Membaca data dari HBASE

Jika kita berasumsi bahwa klien sudah memiliki semua informasi dari hbase:meta (lihat poin 2), maka permintaan langsung menuju ke RS tempat kunci yang diperlukan disimpan. Pertama, pencarian dilakukan di MemCache. Terlepas dari apakah ada data di sana atau tidak, pencarian juga dilakukan di buffer BlockCache dan, jika perlu, di HFiles. Jika data ditemukan dalam file, data tersebut ditempatkan di BlockCache dan akan dikembalikan lebih cepat pada permintaan berikutnya. Pencarian di HFile relatif cepat berkat penggunaan filter Bloom, mis. setelah membaca sejumlah kecil data, ia segera menentukan apakah file ini berisi kunci yang diperlukan dan jika tidak, maka lanjutkan ke yang berikutnya.

Setelah menerima data dari ketiga sumber tersebut, RS menghasilkan respon. Secara khusus, ia dapat mentransfer beberapa versi objek yang ditemukan sekaligus jika klien meminta pembuatan versi.

4. Penyimpanan Data

Buffer MemStore dan BlockCache menempati hingga 80% dari alokasi memori RS di heap (sisanya dicadangkan untuk tugas layanan RS). Jika mode penggunaan tipikal adalah proses menulis dan segera membaca data yang sama, maka masuk akal untuk mengurangi BlockCache dan meningkatkan MemStore, karena Ketika penulisan data tidak masuk ke cache untuk dibaca, BlockCache akan lebih jarang digunakan. 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 membaca dan tidak sesuai dengan LruBlockCache, yang menyebabkan kerja aktif Pengumpul Sampah. Pada saat yang sama, Anda seharusnya tidak mengharapkan peningkatan kinerja yang radikal dari penggunaan cache baca, tetapi kami akan kembali ke sini di paragraf 8

Ada satu BlockCache untuk seluruh RS, dan ada satu MemStore untuk setiap tabel (satu untuk setiap Keluarga Kolom).

Как dijelaskan secara teori, saat menulis, data tidak masuk ke cache dan memang, parameter CACHE_DATA_ON_WRITE untuk tabel dan “Cache DATA on Write” untuk RS disetel ke false. Namun, dalam praktiknya, jika kita menulis data ke MemStore, lalu membuangnya ke disk (sehingga menghapusnya), lalu menghapus file yang dihasilkan, kemudian dengan menjalankan permintaan get kita akan berhasil menerima data tersebut. Selain itu, bahkan jika Anda menonaktifkan BlockCache sepenuhnya dan mengisi tabel dengan data baru, kemudian mengatur ulang MemStore ke disk, menghapusnya dan memintanya dari sesi lain, data tersebut masih akan diambil dari suatu tempat. Jadi HBase tidak hanya menyimpan data, tetapi juga misteri 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

Parameter "Cache DATA saat Dibaca" disetel ke false. Jika Anda punya ide, silakan mendiskusikannya di komentar.

5. Pemrosesan data batch MultiGet/MultiPut

Memproses permintaan tunggal (Dapatkan/Put/Hapus) adalah operasi yang cukup mahal, jadi jika memungkinkan, Anda harus menggabungkannya ke dalam Daftar atau Daftar, yang memungkinkan Anda mendapatkan peningkatan kinerja yang signifikan. Hal ini terutama berlaku untuk operasi tulis, tetapi saat membaca ada kendala berikut. Grafik di bawah menunjukkan waktu untuk membaca 50 catatan dari MemStore. Pembacaan dilakukan dalam satu thread dan sumbu horizontal menunjukkan jumlah kunci dalam permintaan. Di sini Anda dapat melihat bahwa ketika satu permintaan ditingkatkan menjadi seribu kunci, waktu eksekusi berkurang, yaitu. kecepatan meningkat. Namun, dengan mode MSLAB yang diaktifkan secara default, setelah ambang batas ini, penurunan kinerja secara radikal dimulai, dan semakin besar jumlah data dalam catatan, semakin lama waktu pengoperasian.

Pengujian dilakukan pada mesin virtual, 8 core, versi HBase 2.0.0-cdh6.0.0-beta1.

Mode MSLAB dirancang untuk mengurangi fragmentasi heap yang terjadi karena pencampuran data generasi baru dan lama. Sebagai solusinya, ketika MSLAB diaktifkan, data ditempatkan ke dalam sel yang relatif kecil (potongan) dan diproses dalam potongan. Akibatnya, ketika volume paket data yang diminta melebihi ukuran yang dialokasikan, kinerja turun tajam. Di sisi lain, mematikan mode ini juga tidak disarankan, karena akan mengakibatkan terhentinya GC pada saat pemrosesan data intensif. Solusi yang baik adalah dengan meningkatkan volume sel dalam kasus penulisan aktif melalui put bersamaan dengan membaca. Perlu dicatat bahwa masalah tidak terjadi jika, setelah merekam, Anda menjalankan perintah flush, yang mengatur ulang MemStore ke disk, atau jika Anda memuat menggunakan BulkLoad. Tabel di bawah menunjukkan bahwa kueri dari MemStore untuk data yang lebih besar (dan jumlah yang sama) mengakibatkan pelambatan. Namun, dengan meningkatkan ukuran potongan, kami mengembalikan waktu pemrosesan ke normal.

Selain meningkatkan ukuran potongan, membagi data berdasarkan wilayah juga membantu, mis. pemisahan meja. Hal ini mengakibatkan lebih sedikit permintaan yang masuk ke setiap wilayah dan jika masuk ke dalam sel, responsnya tetap baik.

6. Strategi pemisahan tabel menjadi beberapa wilayah (splitting)

Karena HBase adalah penyimpanan nilai kunci dan partisi dilakukan berdasarkan kunci, sangat penting untuk membagi data secara merata di seluruh wilayah. Misalnya, mempartisi tabel seperti itu menjadi tiga bagian akan mengakibatkan data dibagi menjadi tiga wilayah:

Hal ini terjadi sehingga menyebabkan perlambatan tajam jika data yang dimuat kemudian terlihat seperti, misalnya, nilai yang panjang, sebagian besar dimulai dengan angka yang sama, misalnya:

1000001
1000002
...
1100003

Karena kunci disimpan sebagai array byte, semuanya akan dimulai dengan cara yang sama dan termasuk dalam wilayah #1 yang sama yang menyimpan rentang kunci ini. Ada beberapa strategi partisi:

HexStringSplit – Mengubah kunci menjadi string berkode hex dalam rentang "00000000" => "FFFFFFFF" dan mengisi bagian kiri dengan nol.

UniformSplit – Mengubah kunci menjadi array byte dengan pengkodean heksadesimal dalam rentang "00" => "FF" dan diisi di sebelah kanan dengan nol.

Selain itu, Anda dapat menentukan rentang atau kumpulan kunci apa pun untuk pemisahan dan mengonfigurasi pemisahan otomatis. Namun, salah satu pendekatan paling sederhana dan efektif adalah UniformSplit dan penggunaan rangkaian hash, misalnya pasangan byte paling signifikan dari menjalankan kunci melalui fungsi CRC32(rowkey) dan rowkey itu sendiri:

hash + kunci baris

Kemudian seluruh data akan tersebar merata ke 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, jika batasnya terlampaui, secara otomatis memecahnya menjadi beberapa bagian.

7. Toleransi kesalahan dan lokalitas data

Karena hanya satu wilayah yang bertanggung jawab atas setiap rangkaian kunci, solusi untuk masalah yang terkait dengan kerusakan atau penonaktifan RS adalah dengan menyimpan semua data yang diperlukan di HDFS. Ketika RS jatuh, master mendeteksinya melalui tidak adanya detak jantung pada node ZooKeeper. Kemudian ia menetapkan wilayah yang dilayani ke RS lain dan karena HFiles disimpan dalam sistem file terdistribusi, pemilik baru membacanya dan terus menyajikan datanya. Namun, karena beberapa data mungkin ada di MemStore dan tidak sempat masuk ke HFiles, WAL, yang juga disimpan di HDFS, digunakan untuk memulihkan riwayat operasi. Setelah perubahan diterapkan, RS dapat merespons permintaan, tetapi perpindahan tersebut mengarah pada fakta bahwa beberapa data dan proses yang melayaninya berakhir di node yang berbeda, mis. lokalitas semakin berkurang.

Solusi untuk masalah ini adalah pemadatan besar-besaran - prosedur ini memindahkan file ke node yang bertanggung jawab atas file tersebut (di mana wilayahnya berada), akibatnya selama prosedur ini beban pada jaringan dan disk meningkat tajam. Namun, di masa depan, akses terhadap data semakin dipercepat. Selain itu, mayor_compaction melakukan penggabungan semua HFiles menjadi satu file dalam suatu wilayah, dan juga membersihkan data bergantung pada pengaturan tabel. Misalnya, Anda dapat menentukan jumlah versi objek yang harus dipertahankan atau jangka waktu setelah objek tersebut dihapus secara fisik.

Prosedur ini dapat memberikan efek yang sangat positif pada kerja HBase. Gambar di bawah menunjukkan bagaimana kinerja menurun akibat perekaman data aktif. Di sini Anda dapat melihat bagaimana 40 thread menulis ke satu tabel dan 40 thread membaca data secara bersamaan. Menulis thread menghasilkan lebih banyak HFiles, yang dibaca oleh thread lain. Akibatnya, semakin banyak data yang perlu dihapus dari memori dan akhirnya GC mulai bekerja, yang secara praktis melumpuhkan semua pekerjaan. Peluncuran pemadatan besar-besaran menghasilkan pembersihan puing-puing yang dihasilkan dan pemulihan produktivitas.

Pengujian dilakukan pada 3 DataNodes dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase versi 1.2.0-cdh5.14.2

Perlu dicatat bahwa pemadatan besar-besaran diluncurkan pada tabel “langsung”, di mana data ditulis dan dibaca secara aktif. Ada pernyataan online bahwa hal ini dapat menyebabkan respons yang salah saat membaca data. Untuk memeriksanya, sebuah proses diluncurkan yang menghasilkan data baru dan menuliskannya ke dalam tabel. Setelah itu saya langsung membaca dan mengecek apakah nilai yang dihasilkan sesuai dengan yang tertulis. Selama proses ini berjalan, pemadatan besar-besaran dilakukan sekitar 200 kali dan tidak ada satu pun kegagalan yang tercatat. Mungkin masalahnya jarang muncul dan hanya pada saat beban tinggi, jadi lebih aman untuk menghentikan proses penulisan dan membaca seperti yang direncanakan dan melakukan pembersihan untuk mencegah penarikan GC seperti itu.

Selain itu, pemadatan besar tidak mempengaruhi keadaan MemStore; untuk membuangnya ke disk dan memadatkannya, Anda perlu menggunakan flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Pengaturan dan kinerja

Seperti yang telah disebutkan, HBase menunjukkan kesuksesan terbesarnya di mana ia tidak perlu melakukan apa pun, saat menjalankan BulkLoad. Namun, ini berlaku untuk sebagian besar sistem dan manusia. Namun, alat ini lebih cocok untuk menyimpan data secara massal dalam blok besar, sedangkan jika prosesnya memerlukan beberapa permintaan baca dan tulis yang bersaing, maka perintah Get dan Put yang dijelaskan di atas akan digunakan. Untuk menentukan parameter optimal, peluncuran dilakukan dengan berbagai kombinasi parameter dan pengaturan tabel:

• 10 thread diluncurkan secara bersamaan 3 kali berturut-turut (sebut saja ini blok thread).
• Waktu pengoperasian semua thread dalam suatu blok dirata-ratakan dan merupakan hasil akhir dari pengoperasian blok tersebut.
• Semua utas bekerja dengan tabel yang sama.
• Sebelum setiap blok ulir dimulai, pemadatan besar-besaran dilakukan.
• Setiap blok hanya melakukan satu operasi berikut:

-Meletakkan
-Mendapatkan
—Dapatkan+Masukkan

• Setiap blok melakukan 50 iterasi operasinya.
• Ukuran blok suatu record adalah 100 byte, 1000 byte atau 10000 byte (acak).
• Blok diluncurkan dengan jumlah kunci yang diminta berbeda (satu kunci atau 10).
• Blok dijalankan di bawah pengaturan tabel yang berbeda. Parameter berubah:

— BlockCache = dihidupkan atau dimatikan
— Ukuran Blok = 65 KB atau 16 KB
— Partisi = 1, 5 atau 30
— MSLAB = diaktifkan atau dinonaktifkan

Jadi bloknya terlihat seperti ini:

A. Mode MSLAB dihidupkan/dimatikan.
B. Sebuah tabel telah dibuat dengan parameter berikut ditetapkan: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
C. Kompresi diatur ke GZ.
D. 10 utas diluncurkan secara bersamaan melakukan operasi put/get/get+put 1/10 ke dalam tabel ini dengan catatan 100/1000/10000 byte, melakukan 50 kueri berturut-turut (kunci acak).
e. Poin d diulang sebanyak tiga kali.
F. Waktu pengoperasian semua thread dirata-ratakan.

Semua kemungkinan kombinasi diuji. Dapat diprediksi bahwa kecepatan akan menurun seiring bertambahnya ukuran rekaman, atau menonaktifkan caching akan menyebabkan perlambatan. Namun, tujuannya adalah untuk memahami derajat dan signifikansi pengaruh setiap parameter, sehingga data yang dikumpulkan dimasukkan ke dalam masukan fungsi regresi linier, yang memungkinkan untuk menilai signifikansi menggunakan t-statistik. Di bawah ini adalah hasil dari blok yang melakukan operasi Put. Kombinasi lengkap 2*2*3*2*3 = 144 pilihan + 72 tk. beberapa dilakukan dua kali. Oleh karena itu, total ada 216 proses:

Pengujian dilakukan pada mini-cluster yang terdiri dari 3 DataNodes dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase versi 1.2.0-cdh5.14.2.

Kecepatan penyisipan tertinggi 3.7 detik diperoleh dengan mode MSLAB dimatikan, pada tabel dengan satu partisi, dengan BlockCache diaktifkan, BlockSize = 16, catatan 100 byte, 10 buah per paket.
Kecepatan penyisipan terendah 82.8 detik diperoleh dengan mode MSLAB diaktifkan, pada tabel dengan satu partisi, dengan BlockCache diaktifkan, BlockSize = 16, catatan 10000 byte, masing-masing 1.

Sekarang mari kita lihat modelnya. Kami melihat kualitas model berdasarkan R2 yang baik, tetapi sangat jelas bahwa ekstrapolasi merupakan kontraindikasi di sini. Perilaku sebenarnya dari sistem ketika parameter berubah tidak akan linier; model ini tidak diperlukan untuk prediksi, namun untuk memahami apa yang terjadi dalam parameter yang diberikan. Misalnya, di sini kita melihat dari kriteria Student bahwa untuk operasi Put, parameter BlockSize dan BlockCache tidak menjadi masalah (yang umumnya cukup dapat diprediksi):

Namun fakta bahwa peningkatan jumlah partisi menyebabkan penurunan kinerja agak tidak terduga (kita telah melihat dampak positif dari peningkatan jumlah partisi dengan BulkLoad), meskipun dapat dimengerti. Pertama, untuk pemrosesan, Anda harus membuat permintaan ke 30 wilayah, bukan satu wilayah, dan volume datanya tidak sedemikian rupa sehingga akan menghasilkan keuntungan. Kedua, total waktu pengoperasian ditentukan oleh RS yang paling lambat, dan karena jumlah DataNodes lebih sedikit daripada jumlah RS, beberapa wilayah tidak memiliki lokalitas. Baiklah, mari kita lihat lima besarnya:

Sekarang mari kita evaluasi hasil eksekusi blok Get:

Jumlah partisi telah kehilangan signifikansinya, yang mungkin disebabkan oleh fakta bahwa data di-cache dengan baik dan cache baca adalah parameter yang paling signifikan (secara statistik). Tentu saja, menambah jumlah pesan dalam permintaan juga sangat berguna untuk kinerja. Skor teratas:

Terakhir, mari kita lihat model blok yang pertama kali melakukan get dan kemudian put:

Semua parameter penting di sini. Dan hasil dari para pemimpin:

9. Pengujian beban

Akhirnya kami akan meluncurkan muatan yang kurang lebih layak, tetapi akan selalu lebih menarik jika Anda memiliki sesuatu untuk dibandingkan. Di situs web DataStax, pengembang utama Cassandra, terdapat Temuan NT dari sejumlah penyimpanan NoSQL, termasuk HBase versi 0.98.6-1. Pemuatan dilakukan oleh 40 thread, ukuran data 100 byte, disk SSD. Hasil pengujian operasi Read-Modify-Write menunjukkan hasil sebagai berikut.

Sejauh yang saya pahami, pembacaan dilakukan dalam blok yang terdiri dari 100 catatan dan untuk 16 node HBase, pengujian DataStax menunjukkan kinerja 10 ribu operasi per detik.

Untung cluster kita juga punya 16 node, tapi kurang “beruntung” masing-masing node punya 64 core (thread), sedangkan pada pengujian DataStax hanya ada 4. Sebaliknya, mereka punya drive SSD, sedangkan kita punya HDD atau lebih versi baru penggunaan HBase dan CPU selama pemuatan praktis tidak meningkat secara signifikan (secara visual sebesar 5-10 persen). Namun, mari kita coba mulai menggunakan konfigurasi ini. Pengaturan tabel default, pembacaan dilakukan dalam rentang kunci dari 0 hingga 50 juta secara acak (yaitu, pada dasarnya baru setiap saat). Tabel tersebut berisi 50 juta catatan, dibagi menjadi 64 partisi. Kuncinya di-hash menggunakan crc32. Pengaturan tabel adalah default, MSLAB diaktifkan. Meluncurkan 40 thread, setiap thread membaca satu set 100 kunci acak dan segera menulis 100 byte yang dihasilkan kembali ke kunci ini.

Dudukan: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase versi 1.2.0-cdh5.14.2.

Hasil rata-ratanya mendekati 40 ribu operasi per detik, yang jauh lebih baik dibandingkan pengujian DataStax. Namun, untuk tujuan percobaan, Anda dapat sedikit mengubah kondisinya. Sangat tidak mungkin semua pekerjaan akan dilakukan secara eksklusif pada satu tabel, dan juga hanya pada kunci unik. Mari kita asumsikan bahwa ada sekumpulan tombol "panas" tertentu yang menghasilkan beban utama. Oleh karena itu, mari kita coba membuat beban dengan catatan yang lebih besar (10 KB), juga dalam batch 100, dalam 4 tabel berbeda dan membatasi rentang kunci yang diminta hingga 50 ribu Grafik di bawah ini menunjukkan peluncuran 40 utas, setiap utas terbaca satu set 100 kunci dan segera menulis 10 KB acak pada kunci ini kembali.

Dudukan: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase versi 1.2.0-cdh5.14.2.

Selama pemuatan, pemadatan besar-besaran diluncurkan beberapa kali, seperti yang ditunjukkan di atas, tanpa prosedur ini, kinerja akan menurun secara bertahap, namun, beban tambahan juga muncul selama pelaksanaan. Penarikan disebabkan oleh berbagai alasan. Terkadang thread selesai bekerja dan ada jeda saat dimulai ulang, terkadang aplikasi pihak ketiga membuat beban pada cluster.

Membaca dan segera menulis adalah salah satu skenario kerja tersulit bagi HBase. Jika Anda hanya membuat permintaan put kecil, misalnya 100 byte, menggabungkannya ke dalam paket berisi 10-50 ribu keping, Anda bisa mendapatkan ratusan ribu operasi per detik, dan situasinya serupa dengan permintaan hanya-baca. Perlu dicatat bahwa hasilnya jauh lebih baik daripada yang diperoleh DataStax, terutama karena permintaan dalam blok sebanyak 50 ribu.

Dudukan: 16 DataNode dan 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase versi 1.2.0-cdh5.14.2.

10. Kesimpulan

Sistem ini dikonfigurasi dengan cukup fleksibel, namun pengaruh sejumlah besar parameter masih belum diketahui. Beberapa di antaranya telah diuji, tetapi tidak disertakan dalam set pengujian yang dihasilkan. Misalnya, percobaan pendahuluan menunjukkan signifikansi yang tidak signifikan dari parameter seperti DATA_BLOCK_ENCODING, yang mengkodekan informasi menggunakan nilai dari sel tetangga, yang dapat dimengerti untuk data yang dihasilkan secara acak. Jika Anda menggunakan objek duplikat dalam jumlah besar, keuntungannya bisa signifikan. Secara umum, kita dapat mengatakan bahwa HBase memberikan kesan database yang cukup serius dan dipikirkan dengan matang, yang bisa sangat produktif ketika melakukan operasi dengan blok data yang besar. Apalagi jika proses membaca dan menulis bisa dipisahkan pada waktunya.

Jika ada yang menurut Anda kurang diungkapkan, saya siap memberi tahu Anda lebih detail. Kami mengundang Anda untuk berbagi pengalaman atau berdiskusi jika Anda tidak setuju dengan sesuatu.

Sumber: www.habr.com