Teori dan amalan menggunakan HBase

Selamat petang Nama saya Danil Lipovoy, pasukan kami di Sbertech mula menggunakan HBase sebagai storan untuk data operasi. Semasa mempelajarinya, pengalaman telah terkumpul yang ingin saya sistematikkan dan huraikan (kami berharap ia berguna kepada ramai). Semua percubaan di bawah telah dilakukan dengan HBase versi 1.2.0-cdh5.14.2 dan 2.0.0-cdh6.0.0-beta1.

1. Seni bina umum
2. Menulis data ke HBASE
3. Membaca data daripada HBASE
4. Cache Data
5. Pemprosesan data kelompok MultiGet/MultiPut
6. Strategi untuk membahagikan jadual kepada kawasan (memisahkan)
7. Toleransi kerosakan, pemadatan dan lokaliti data
8. Tetapan dan prestasi
9. Ujian Tekanan
10. Penemuan

1. Seni bina am

Guru sandaran mendengar degupan jantung yang aktif pada nod ZooKeeper dan, sekiranya berlaku kehilangan, mengambil alih fungsi induk.

2. Tulis data kepada HBASE

Mula-mula, mari kita lihat kes paling mudah - menulis objek nilai kunci pada jadual menggunakan put(rowkey). Pelanggan mesti terlebih dahulu mengetahui di mana Pelayan Wilayah Root (RRS), yang menyimpan jadual hbase:meta, berada. Dia menerima maklumat ini daripada ZooKeeper. Selepas itu ia mengakses RRS dan membaca jadual hbase:meta, yang daripadanya ia mengekstrak maklumat tentang RegionServer (RS) yang bertanggungjawab untuk menyimpan data untuk kunci baris yang diberikan dalam jadual minat. Untuk kegunaan masa hadapan, jadual meta dicache oleh pelanggan dan oleh itu panggilan seterusnya pergi lebih pantas, terus ke RS.

Seterusnya, RS, setelah menerima permintaan, pertama sekali menulisnya ke WriteAheadLog (WAL), yang diperlukan untuk pemulihan sekiranya berlaku kemalangan. Kemudian simpan data ke MemStore. Ini ialah penimbal dalam ingatan yang mengandungi set kunci yang diisih untuk rantau tertentu. Jadual boleh dibahagikan kepada kawasan (partition), setiap satu daripadanya mengandungi set kunci yang tidak bersambung. Ini membolehkan anda meletakkan kawasan pada pelayan yang berbeza untuk mencapai prestasi yang lebih tinggi. Walau bagaimanapun, walaupun kenyataan ini jelas, kita akan melihat kemudian bahawa ini tidak berfungsi dalam semua kes.

Selepas meletakkan entri dalam MemStore, respons dikembalikan kepada pelanggan bahawa entri itu berjaya disimpan. Walau bagaimanapun, pada hakikatnya ia disimpan hanya dalam penimbal dan sampai ke cakera hanya selepas tempoh masa tertentu berlalu atau apabila ia diisi dengan data baharu.

Apabila melakukan operasi "Padam", data tidak dipadamkan secara fizikal. Ia hanya ditandakan sebagai dipadam, dan pemusnahan itu sendiri berlaku pada masa memanggil fungsi padat utama, yang diterangkan dengan lebih terperinci dalam perenggan 7.

Fail dalam format HFile terkumpul dalam HDFS dan dari semasa ke semasa proses padat kecil dilancarkan, yang hanya menggabungkan fail kecil menjadi lebih besar tanpa memadamkan apa-apa. Lama kelamaan, ini bertukar menjadi masalah yang hanya muncul apabila membaca data (kami akan kembali kepada perkara ini kemudian).

Sebagai tambahan kepada proses pemuatan yang diterangkan di atas, terdapat prosedur yang lebih berkesan, yang mungkin merupakan sisi terkuat pangkalan data ini - BulkLoad. Ia terletak pada hakikat bahawa kami secara bebas membentuk HFiles dan meletakkannya pada cakera, yang membolehkan kami membuat skala dengan sempurna dan mencapai kelajuan yang sangat baik. Sebenarnya, had di sini bukanlah HBase, tetapi keupayaan perkakasan. Di bawah ialah hasil but pada gugusan yang terdiri daripada 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 bahawa dengan meningkatkan bilangan partition (wilayah) dalam jadual, serta pelaksana Spark, kami mendapat peningkatan dalam kelajuan muat turun. Selain itu, kelajuan bergantung pada volum rakaman. Blok besar memberikan peningkatan dalam MB/saat, blok kecil dalam bilangan rekod yang dimasukkan setiap unit masa, semua perkara lain adalah sama.

Anda juga boleh mula memuatkan ke dalam dua jadual pada masa yang sama dan mendapatkan kelajuan dua kali ganda. Di bawah ini anda boleh melihat bahawa menulis blok 10 KB kepada dua jadual serentak berlaku pada kelajuan kira-kira 600 MB/saat dalam setiap satu (jumlah 1275 MB/saat), yang bertepatan dengan kelajuan menulis ke satu jadual 623 MB/saat (lihat No. 11 di atas)

Tetapi larian kedua dengan rekod 50 KB menunjukkan bahawa kelajuan muat turun meningkat sedikit, yang menunjukkan bahawa ia menghampiri nilai had. Pada masa yang sama, anda perlu ingat bahawa hampir tiada beban yang dibuat pada HBASE itu sendiri, semua yang diperlukan daripadanya ialah memberikan data terlebih dahulu daripada hbase:meta, dan selepas melapisi HFiles, tetapkan semula data BlockCache dan simpan Penampan MemStore ke cakera, jika ia tidak kosong.

3. Membaca data daripada HBASE

Jika kita mengandaikan bahawa klien sudah mempunyai semua maklumat daripada hbase:meta (lihat titik 2), maka permintaan itu pergi terus ke RS di mana kunci yang diperlukan disimpan. Pertama, carian dilakukan dalam MemCache. Tidak kira sama ada terdapat data di sana atau tidak, carian juga dijalankan dalam penimbal BlockCache dan, jika perlu, dalam HFiles. Jika data ditemui dalam fail, ia diletakkan dalam BlockCache dan akan dikembalikan dengan lebih cepat pada permintaan seterusnya. Pencarian dalam HFile agak pantas berkat penggunaan penapis Bloom, i.e. setelah membaca sejumlah kecil data, ia segera menentukan sama ada fail ini mengandungi kunci yang diperlukan dan jika tidak, kemudian beralih ke yang seterusnya.

Setelah menerima data daripada ketiga-tiga sumber ini, RS menjana respons. Khususnya, ia boleh memindahkan beberapa versi objek yang ditemui sekali gus jika pelanggan meminta versi.

4. Caching Data

Penampan MemStore dan BlockCache menduduki sehingga 80% daripada memori RS atas timbunan yang diperuntukkan (selebihnya dikhaskan untuk tugas perkhidmatan RS). Jika mod penggunaan biasa adalah sedemikian rupa sehingga proses menulis dan segera membaca data yang sama, maka masuk akal untuk mengurangkan BlockCache dan meningkatkan MemStore, kerana Apabila data menulis tidak masuk ke dalam cache untuk dibaca, BlockCache akan digunakan kurang kerap. Penampan BlockCache terdiri daripada dua bahagian: LruBlockCache (sentiasa dalam timbunan) dan BucketCache (biasanya di luar timbunan atau pada SSD). BucketCache harus digunakan apabila terdapat banyak permintaan membaca dan ia tidak sesuai dengan LruBlockCache, yang membawa kepada kerja aktif Pengumpul Sampah. Pada masa yang sama, anda tidak seharusnya mengharapkan peningkatan radikal dalam prestasi daripada menggunakan cache baca, tetapi kami akan kembali kepada perkara ini dalam perenggan 8

Terdapat satu BlockCache untuk keseluruhan RS, dan terdapat satu MemStore untuk setiap jadual (satu untuk setiap Keluarga Lajur).

bagaimana diterangkan secara teori, apabila menulis, data tidak masuk ke dalam cache dan sesungguhnya, parameter seperti CACHE_DATA_ON_WRITE untuk jadual dan "DATA Cache pada Tulis" untuk RS ditetapkan kepada palsu. Walau bagaimanapun, dalam amalan, jika kami menulis data ke MemStore, kemudian siramkannya ke cakera (dengan itu mengosongkannya), kemudian padam fail yang terhasil, kemudian dengan melaksanakan permintaan dapatkan kami akan berjaya menerima data tersebut. Lebih-lebih lagi, walaupun anda melumpuhkan sepenuhnya BlockCache dan mengisi jadual dengan data baharu, kemudian tetapkan semula MemStore ke cakera, padamkannya dan mintanya dari sesi lain, ia masih akan diambil dari suatu tempat. Jadi HBase menyimpan bukan sahaja data, tetapi juga misteri misteri.

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 "DATA Cache pada Baca" ditetapkan kepada palsu. Jika anda mempunyai sebarang idea, dialu-alukan untuk membincangkannya dalam ulasan.

5. Pemprosesan data kelompok MultiGet/MultiPut

Memproses permintaan tunggal (Dapatkan/Letak/Padam) adalah operasi yang agak mahal, jadi jika boleh, anda harus menggabungkannya ke dalam Senarai atau Senarai, yang membolehkan anda mendapat peningkatan prestasi yang ketara. Ini adalah benar terutamanya untuk operasi tulis, tetapi apabila membaca terdapat perangkap berikut. Graf di bawah menunjukkan masa untuk membaca 50 rekod daripada MemStore. Bacaan dilakukan dalam satu utas dan paksi mendatar menunjukkan bilangan kekunci dalam permintaan. Di sini anda dapat melihat bahawa apabila meningkat kepada seribu kunci dalam satu permintaan, masa pelaksanaan jatuh, i.e. kelajuan bertambah. Walau bagaimanapun, dengan mod MSLAB didayakan secara lalai, selepas ambang ini penurunan radikal dalam prestasi bermula, dan semakin besar jumlah data dalam rekod, semakin lama masa operasi.

Ujian telah dilakukan pada mesin maya, 8 teras, versi HBase 2.0.0-cdh6.0.0-beta1.

Mod MSLAB direka untuk mengurangkan pemecahan timbunan, yang berlaku disebabkan oleh pencampuran data generasi baharu dan lama. Sebagai penyelesaian, apabila MSLAB didayakan, data diletakkan ke dalam sel yang agak kecil (ketulan) dan diproses dalam ketulan. Akibatnya, apabila volum dalam paket data yang diminta melebihi saiz yang diperuntukkan, prestasi menurun dengan mendadak. Sebaliknya, mematikan mod ini juga tidak digalakkan, kerana ia akan menyebabkan pemberhentian disebabkan GC semasa pemprosesan data intensif. Penyelesaian yang baik ialah meningkatkan volum sel dalam kes penulisan aktif melalui put pada masa yang sama seperti membaca. Perlu diingat bahawa masalah tidak berlaku jika, selepas rakaman, anda menjalankan arahan flush, yang menetapkan semula MemStore ke cakera, atau jika anda memuatkan menggunakan BulkLoad. Jadual di bawah menunjukkan bahawa pertanyaan daripada MemStore untuk data yang lebih besar (dan jumlah yang sama) mengakibatkan kelembapan. Walau bagaimanapun, dengan meningkatkan saiz chunksis kami mengembalikan masa pemprosesan kepada normal.

Selain meningkatkan saiz ketulan, pemisahan data mengikut rantau membantu, i.e. pemisahan meja. Ini menyebabkan lebih sedikit permintaan yang datang ke setiap rantau dan jika ia masuk ke dalam sel, responsnya kekal baik.

6. Strategi untuk membahagikan jadual kepada kawasan (pemisahan)

Memandangkan HBase ialah storan nilai kunci dan pembahagian dijalankan oleh kunci, adalah sangat penting untuk membahagikan data secara sama rata merentas semua wilayah. Sebagai contoh, membahagikan jadual sedemikian kepada tiga bahagian akan menyebabkan data dibahagikan kepada tiga wilayah:

Ia berlaku bahawa ini membawa kepada kelembapan mendadak jika data yang dimuatkan kemudian kelihatan seperti, sebagai contoh, nilai panjang, kebanyakannya bermula dengan digit yang sama, contohnya:

1000001
1000002
...
1100003

Memandangkan kunci disimpan sebagai tatasusunan bait, semuanya akan bermula sama dan tergolong dalam rantau #1 yang sama yang menyimpan julat kunci ini. Terdapat beberapa strategi pembahagian:

HexStringSplit – Mengubah kekunci menjadi rentetan berkod perenambelasan dalam julat "00000000" => "FFFFFFFF" dan pelapik di sebelah kiri dengan sifar.

UniformSplit – Mengubah kunci menjadi tatasusunan bait dengan pengekodan perenambelasan dalam julat "00" => "FF" dan padding di sebelah kanan dengan sifar.

Di samping itu, anda boleh menentukan mana-mana julat atau set kunci untuk membelah dan mengkonfigurasi pemisahan automatik. Walau bagaimanapun, salah satu pendekatan yang paling mudah dan berkesan ialah UniformSplit dan penggunaan penggabungan cincang, contohnya pasangan bait yang paling ketara daripada menjalankan kunci melalui fungsi CRC32(rowkey) dan rowkey itu sendiri:

hash + rowkey

Kemudian semua data akan diedarkan sama rata di seluruh wilayah. Apabila membaca, dua bait pertama hanya dibuang dan kunci asal kekal. RS juga mengawal jumlah data dan kunci di rantau ini dan, jika melebihi had, secara automatik memecahkannya kepada beberapa bahagian.

7. Toleransi kerosakan dan lokaliti data

Memandangkan hanya satu rantau bertanggungjawab untuk setiap set kunci, penyelesaian kepada masalah yang berkaitan dengan ranap atau penyahtauliahan RS adalah dengan menyimpan semua data yang diperlukan dalam HDFS. Apabila RS jatuh, tuan mengesan ini melalui ketiadaan degupan jantung pada nod ZooKeeper. Kemudian ia memperuntukkan wilayah yang dihidangkan kepada RS lain dan memandangkan HFiles disimpan dalam sistem fail yang diedarkan, pemilik baharu membacanya dan terus menyampaikan data. Walau bagaimanapun, memandangkan sesetengah data mungkin berada dalam MemStore dan tidak mempunyai masa untuk masuk ke HFiles, WAL, yang juga disimpan dalam HDFS, digunakan untuk memulihkan sejarah operasi. Selepas perubahan digunakan, RS dapat bertindak balas kepada permintaan, tetapi langkah itu membawa kepada fakta bahawa beberapa data dan proses yang melayannya berakhir pada nod yang berbeza, i.e. lokaliti semakin berkurangan.

Penyelesaian masalah adalah pemadatan utama - prosedur ini memindahkan fail ke nod yang bertanggungjawab untuk mereka (di mana kawasan mereka terletak), akibatnya semasa prosedur ini beban pada rangkaian dan cakera meningkat dengan mendadak. Walau bagaimanapun, pada masa hadapan, akses kepada data akan dipercepatkan dengan ketara. Selain itu, major_compaction melaksanakan penggabungan semua HFiles ke dalam satu fail dalam rantau, dan juga membersihkan data bergantung pada tetapan jadual. Sebagai contoh, anda boleh menentukan bilangan versi objek yang mesti dikekalkan atau seumur hidup selepas objek itu dipadamkan secara fizikal.

Prosedur ini boleh memberi kesan yang sangat positif terhadap operasi HBase. Gambar di bawah menunjukkan bagaimana prestasi merosot akibat rakaman data aktif. Di sini anda boleh melihat bagaimana 40 utas menulis pada satu jadual dan 40 utas membaca data secara serentak. Menulis benang menjana lebih banyak HFiles, yang dibaca oleh utas lain. Akibatnya, semakin banyak data perlu dialih keluar dari ingatan dan akhirnya GC mula berfungsi, yang secara praktikalnya melumpuhkan semua kerja. Pelancaran pemadatan besar membawa kepada pembersihan serpihan yang terhasil dan pemulihan produktiviti.

Ujian dilakukan pada 3 Nod Data dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 benang). HBase versi 1.2.0-cdh5.14.2

Perlu diingat bahawa pemadatan besar telah dilancarkan pada jadual "langsung", di mana data ditulis dan dibaca secara aktif. Terdapat kenyataan dalam talian bahawa ini boleh menyebabkan tindak balas yang salah semasa membaca data. Untuk menyemak, satu proses telah dilancarkan yang menghasilkan data baharu dan menulisnya pada jadual. Selepas itu saya segera membaca dan menyemak sama ada nilai yang terhasil bertepatan dengan apa yang ditulis. Semasa proses ini berjalan, pemadatan besar dijalankan kira-kira 200 kali dan tiada satu pun kegagalan direkodkan. Mungkin masalah ini jarang muncul dan hanya semasa beban tinggi, jadi adalah lebih selamat untuk menghentikan proses menulis dan membaca seperti yang dirancang dan melakukan pembersihan untuk mengelakkan pengeluaran GC sedemikian.

Selain itu, pemadatan besar tidak menjejaskan keadaan MemStore; untuk mengepamnya ke cakera dan memadatkannya, anda perlu menggunakan flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Tetapan dan prestasi

Seperti yang telah disebutkan, HBase menunjukkan kejayaan terbesarnya di mana ia tidak perlu melakukan apa-apa, apabila melaksanakan BulkLoad. Walau bagaimanapun, ini terpakai kepada kebanyakan sistem dan orang. Walau bagaimanapun, alat ini lebih sesuai untuk menyimpan data secara pukal dalam blok besar, manakala jika proses memerlukan berbilang permintaan baca dan tulis yang bersaing, arahan Dapatkan dan Letakkan yang diterangkan di atas digunakan. Untuk menentukan parameter optimum, pelancaran telah dijalankan dengan pelbagai kombinasi parameter jadual dan tetapan:

• 10 utas telah dilancarkan serentak 3 kali berturut-turut (mari kita panggil ini blok benang).
• Masa operasi semua benang dalam blok dipuratakan dan merupakan hasil akhir operasi blok.
• Semua benang berfungsi dengan jadual yang sama.
• Sebelum setiap permulaan blok benang, pemadatan besar dilakukan.
• Setiap blok hanya melakukan satu daripada operasi berikut:

-Letak
—Dapatkan
—Dapatkan+Letak

• Setiap blok melakukan 50 lelaran operasinya.
• Saiz blok rekod ialah 100 bait, 1000 bait atau 10000 bait (rawak).
• Blok telah dilancarkan dengan bilangan kunci yang diminta yang berbeza (sama ada satu kunci atau 10).
• Blok dijalankan di bawah tetapan meja yang berbeza. Parameter berubah:

— BlockCache = dihidupkan atau dimatikan
— Saiz Blok = 65 KB atau 16 KB
— Pembahagian = 1, 5 atau 30
— MSLAB = didayakan atau dilumpuhkan

Jadi blok kelihatan seperti ini:

a. Mod MSLAB telah dihidupkan/dimatikan.
b. Jadual telah dibuat yang mana parameter berikut telah ditetapkan: BlockCache = benar/tiada, Saiz Blok = 65/16 Kb, Partition = 1/5/30.
c. Mampatan telah ditetapkan kepada GZ.
d. 10 utas telah dilancarkan serentak melakukan 1/10 put/get/get+put operasi ke dalam jadual ini dengan rekod 100/1000/10000 bait, melaksanakan 50 pertanyaan berturut-turut (kunci rawak).
e. Titik d diulang tiga kali.
f. Masa operasi semua rangkaian telah dipuratakan.

Semua kombinasi yang mungkin telah diuji. Adalah boleh diramalkan bahawa kelajuan akan menurun apabila saiz rekod meningkat, atau melumpuhkan caching akan menyebabkan kelembapan. Walau bagaimanapun, matlamatnya adalah untuk memahami tahap dan kepentingan pengaruh setiap parameter, jadi data yang dikumpul dimasukkan ke dalam input fungsi regresi linear, yang memungkinkan untuk menilai kepentingan menggunakan statistik-t. Di bawah ialah keputusan blok yang melakukan operasi Put. Set penuh kombinasi 2*2*3*2*3 = 144 pilihan + 72 tk. ada yang dilakukan dua kali. Oleh itu, terdapat 216 larian secara keseluruhan:

Ujian telah dijalankan pada kluster mini yang terdiri daripada 3 Nod Data dan 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 benang). HBase versi 1.2.0-cdh5.14.2.

Kelajuan sisipan tertinggi 3.7 saat diperoleh dengan mod MSLAB dimatikan, di atas meja dengan satu partition, dengan BlockCache didayakan, BlockSize = 16, rekod 100 bait, 10 keping setiap pek.
Kelajuan sisipan terendah 82.8 saat diperoleh dengan mod MSLAB didayakan, pada jadual dengan satu partition, dengan BlockCache didayakan, BlockSize = 16, rekod 10000 bait, 1 setiap satu.

Sekarang mari kita lihat modelnya. Kami melihat kualiti model yang baik berdasarkan R2, tetapi jelas sekali bahawa ekstrapolasi adalah kontraindikasi di sini. Tingkah laku sebenar sistem apabila parameter berubah tidak akan menjadi linear; model ini tidak diperlukan untuk ramalan, tetapi untuk memahami apa yang berlaku dalam parameter yang diberikan. Sebagai contoh, di sini kita melihat daripada kriteria Pelajar bahawa parameter BlockSize dan BlockCache tidak penting untuk operasi Put (yang secara umumnya boleh diramal):

Tetapi hakikat bahawa peningkatan bilangan partition membawa kepada penurunan prestasi agak tidak dijangka (kami telah melihat kesan positif daripada meningkatkan bilangan partition dengan BulkLoad), walaupun boleh difahami. Pertama, untuk pemprosesan, anda perlu menjana permintaan ke 30 wilayah dan bukannya satu, dan jumlah data tidak sedemikian sehingga ini akan menghasilkan keuntungan. Kedua, jumlah masa operasi ditentukan oleh RS paling perlahan, dan oleh kerana bilangan Nod Data adalah kurang daripada bilangan RS, sesetengah wilayah mempunyai lokaliti sifar. Baiklah, mari lihat lima teratas:

Sekarang mari kita menilai hasil melaksanakan blok Dapatkan:

Bilangan partition telah kehilangan kepentingan, yang mungkin dijelaskan oleh fakta bahawa data dicache dengan baik dan cache baca adalah parameter yang paling ketara (secara statistik). Sememangnya, meningkatkan bilangan mesej dalam permintaan juga sangat berguna untuk prestasi. Markah teratas:

Nah, akhirnya, mari kita lihat model blok yang pertama kali dilakukan get dan kemudian letakkan:

Semua parameter adalah penting di sini. Dan keputusan para pemimpin:

9. Ujian beban

Nah, akhirnya kami akan melancarkan beban yang lebih kurang baik, tetapi ia sentiasa lebih menarik apabila anda mempunyai sesuatu untuk dibandingkan. Di laman web DataStax, pembangun utama Cassandra, terdapat penemuan NT daripada beberapa storan NoSQL, termasuk versi HBase 0.98.6-1. Pemuatan dilakukan oleh 40 utas, saiz data 100 bait, cakera SSD. Keputusan ujian operasi Baca-Ubahsuai-Tulis menunjukkan keputusan berikut.

Setakat yang saya faham, pembacaan dijalankan dalam blok 100 rekod dan untuk 16 nod HBase, ujian DataStax menunjukkan prestasi 10 ribu operasi sesaat.

Adalah bernasib baik kerana kluster kami juga mempunyai 16 nod, tetapi tidaklah "bernasib baik" kerana masing-masing mempunyai 64 teras (benang), manakala dalam ujian DataStax hanya terdapat 4. Sebaliknya, mereka mempunyai pemacu SSD, manakala kami mempunyai HDD. atau lebih versi baharu HBase dan penggunaan CPU semasa beban secara praktikalnya tidak meningkat dengan ketara (secara visual sebanyak 5-10 peratus). Walau bagaimanapun, mari cuba mula menggunakan konfigurasi ini. Tetapan jadual lalai, bacaan dilakukan dalam julat kunci dari 0 hingga 50 juta secara rawak (iaitu, pada asasnya baharu setiap kali). Jadual mengandungi 50 juta rekod, dibahagikan kepada 64 partition. Kekunci dicincang menggunakan crc32. Tetapan jadual adalah lalai, MSLAB didayakan. Melancarkan 40 utas, setiap utas membaca satu set 100 kekunci rawak dan segera menulis 100 bait yang dijana kembali ke kunci ini.

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

Hasil purata lebih hampir kepada 40 ribu operasi sesaat, yang jauh lebih baik daripada ujian DataStax. Walau bagaimanapun, untuk tujuan percubaan, anda boleh mengubah sedikit syarat. Ia agak tidak mungkin bahawa semua kerja akan dijalankan secara eksklusif pada satu meja, dan juga hanya pada kunci unik. Mari kita anggap bahawa terdapat set kunci "panas" tertentu yang menjana beban utama. Oleh itu, mari cuba buat beban dengan rekod yang lebih besar (10 KB), juga dalam kelompok 100, dalam 4 jadual berbeza dan hadkan julat kunci yang diminta kepada 50 ribu. Graf di bawah menunjukkan pelancaran 40 utas, setiap utas dibaca satu set 100 kekunci dan segera menulis 10 KB secara rawak pada kekunci ini kembali.

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

Semasa beban, pemadatan utama telah dilancarkan beberapa kali, seperti yang ditunjukkan di atas, tanpa prosedur ini, prestasi secara beransur-ansur akan merosot, bagaimanapun, beban tambahan juga timbul semasa pelaksanaan. Penarikan disebabkan oleh pelbagai sebab. Kadangkala benang selesai berfungsi dan terdapat jeda semasa ia dimulakan semula, kadangkala aplikasi pihak ketiga mencipta beban pada kluster.

Membaca dan segera menulis adalah salah satu senario kerja yang paling sukar untuk HBase. Jika anda hanya membuat permintaan put kecil, contohnya 100 bait, menggabungkannya ke dalam pek 10-50 ribu keping, anda boleh mendapat ratusan ribu operasi sesaat, dan keadaannya serupa dengan permintaan baca sahaja. Perlu diingat bahawa hasilnya secara radikal lebih baik daripada yang diperoleh oleh DataStax, kebanyakannya disebabkan oleh permintaan dalam blok 50 ribu.

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

10. Kesimpulan

Sistem ini dikonfigurasikan dengan agak fleksibel, tetapi pengaruh sejumlah besar parameter masih tidak diketahui. Sebahagian daripada mereka telah diuji, tetapi tidak termasuk dalam set ujian yang dihasilkan. Sebagai contoh, percubaan awal menunjukkan kepentingan yang tidak ketara bagi parameter seperti DATA_BLOCK_ENCODING, yang mengekod maklumat menggunakan nilai ​dari sel jiran, yang boleh difahami untuk data yang dijana secara rawak. Jika anda menggunakan sejumlah besar objek pendua, keuntungan boleh menjadi ketara. Secara umum, kita boleh mengatakan bahawa HBase memberikan gambaran pangkalan data yang agak serius dan difikirkan dengan baik, yang boleh menjadi agak produktif apabila melakukan operasi dengan blok data yang besar. Terutamanya jika mungkin untuk memisahkan proses membaca dan menulis dalam masa.

Sekiranya terdapat sesuatu pada pendapat anda yang tidak cukup didedahkan, saya bersedia untuk memberitahu anda dengan lebih terperinci. Kami menjemput anda untuk berkongsi pengalaman anda atau berbincang jika anda tidak bersetuju dengan sesuatu.

Sumber: www.habr.com