Téori sareng prakték ngagunakeun HBase

Wilujeng sonten Nami abdi Danil Lipovoy, tim kami di Sbertech mimiti nganggo HBase salaku panyimpen data operasional. Dina kursus diajar éta, pangalaman akumulasi anu kuring hoyong sistematis sareng ngajelaskeun (kami ngarepkeun éta bakal mangpaat pikeun seueur). Sadaya percobaan di handap ieu dipigawé ku HBase versi 1.2.0-cdh5.14.2 jeung 2.0.0-cdh6.0.0-beta1.

1. Arsitéktur umum
2. Nulis data ka HBASE
3. Maca data tina HBASE
4. Cache data
5. Ngolah data bets MultiGet / MultiPut
6. Stratégi pikeun ngabagi tabel kana daérah (meulah)
7. Kasabaran kasalahan, kompakifikasi sareng lokasi data
8. Setélan jeung kinerja
9. Uji Stress
10. papanggihan

1. Arsitéktur umum

Master cadangan ngadangukeun denyut jantung anu aktip dina titik ZooKeeper sareng, upami leungit, nyandak alih fungsi master.

2. Nulis data kana HBASE

Kahiji, hayu urang nempo kasus pangbasajanna - nulis obyék konci-nilai kana tabel maké put(rowkey). Klién kedah milarian heula dimana Root Region Server (RRS), anu nyimpen hbase: méja meta, ayana. Anjeunna nampi inpormasi ieu ti ZooKeeper. Sanggeus éta aksés RRS jeung maca hbase: tabel meta, ti mana eta extracts informasi ngeunaan nu RegionServer (RS) tanggung jawab pikeun nyimpen data pikeun rowkey dibikeun dina tabel dipikaresep. Pikeun pamakéan nu bakal datang, tabel meta ieu sindangan ku klien tur ku kituna panggero saterusna leuwih gancang, langsung ka RS.

Salajengna, RS, sanggeus narima pamenta, mimitina nulis ka WriteAheadLog (WAL), nu dipikabutuh pikeun recovery bisi tina kacilakaan. Lajeng nyimpen data ka MemStore. Ieu mangrupikeun panyangga dina mémori anu ngandung sakumpulan konci anu diurutkeun pikeun daérah anu dipasihkeun. Méja bisa dibagi kana wewengkon (partitions), nu masing-masing ngandung hiji set disjoint konci. Ieu ngamungkinkeun anjeun pikeun nempatkeun daérah dina server anu béda pikeun ngahontal prestasi anu langkung luhur. Nanging, sanaos kajelasan pernyataan ieu, urang bakal ningali engké yén ieu henteu tiasa dianggo dina sadaya kasus.

Saatos nempatkeun éntri dina MemStore, réspon dipulangkeun ka klien yén éntri éta suksés disimpen. Nanging, dina kanyataanana disimpen ngan ukur dina panyangga sareng dugi ka disk ngan saatos sababaraha waktos atanapi nalika ngeusi data énggal.

Nalika ngajalankeun operasi "Pupus", data henteu dihapus sacara fisik. Éta ngan saukur ditandaan salaku dihapus, sareng karusakan sorangan lumangsung dina waktos nelepon fungsi kompak utama, anu dijelaskeun sacara langkung rinci dina paragraf 7.

File dina format HFile diakumulasi dina HDFS sareng ti waktos ka waktos prosés kompak leutik diluncurkeun, anu ngan saukur ngahijikeun file alit kana file anu langkung ageung tanpa ngahapus nanaon. Kana waktosna, ieu janten masalah anu ngan ukur muncul nalika maca data (urang bakal uih deui engké).

Salian prosés loading ditétélakeun di luhur, aya prosedur leuwih éféktif, nu meureun sisi neneng tina database ieu - BulkLoad. Éta perenahna di kanyataan yén urang bebas ngabentuk HFiles sarta nempatkeun eta dina disk, anu ngamungkinkeun urang pikeun skala sampurna sarta ngahontal speeds pisan santun. Kanyataanna, watesan di dieu sanes HBase, tapi kamampuan hardware. Di handap ieu hasil boot dina klaster diwangun ku 16 RegionServers jeung 16 NodeManager BENANG (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase Vérsi 1.2.0-cdh5.14.2.

Di dieu anjeun tiasa ningali yén ku cara ningkatkeun jumlah partisi (wilayah) dina tabél, ogé pelaksana Spark, urang nampi kanaékan kagancangan download. Ogé, laju gumantung kana volume rekaman. Blok badag masihan kanaékan MB / detik, blok leutik dina jumlah rékaman diselapkeun per unit waktu, sagala hal séjén sarua.

Anjeun oge bisa ngamimitian loading kana dua tabel dina waktos anu sareng tur meunang dua kali laju. Di handap anjeun tiasa ningali yén tulisan 10 KB blok kana dua tabel sakaligus lumangsung dina laju kira-kira 600 MB/detik dina unggal (total 1275 MB/detik), nu saluyu jeung laju nulis ka hiji méja 623 MB/detik (tingali No. 11 di luhur)

Tapi ngajalankeun kadua kalayan rékaman 50 KB nunjukkeun yén laju download rada ningkat, anu nunjukkeun yén éta ngadeukeutan nilai wates. Dina waktos anu sami, anjeun kedah émut yén praktis henteu aya beban anu didamel dina HBASE nyalira, sadaya anu diperyogikeun nyaéta pikeun masihan data heula tina hbase:meta, sareng saatos ngajajar HFiles, reset data BlockCache sareng simpen MemStore panyangga ka disk, lamun teu kosong.

3. Maca data tina HBASE

Lamun urang nganggap yen klien nu geus boga sagala informasi ti hbase: meta (tingali titik 2), lajeng pamundut mana langsung ka RS dimana konci diperlukeun disimpen. Kahiji, pilarian dipigawé dina MemCache. Henteu paduli naha aya data atanapi henteu, panéangan ogé dilaksanakeun dina panyangga BlockCache sareng, upami diperyogikeun, dina HFiles. Upami data kapanggih dina file, éta disimpen dina BlockCache sareng bakal dipulangkeun langkung gancang dina pamundut salajengna. Pilarian di HFile relatif gancang berkat pamakéan filter Bloom, i.e. sanggeus maca jumlah leutik data, éta geuwat nangtukeun naha file ieu ngandung konci diperlukeun tur lamun henteu, lajeng ngalir ka nu salajengna.

Sanggeus narima data ti tilu sumber ieu, RS ngahasilkeun respon. Khususna, éta tiasa nransferkeun sababaraha versi obyék anu kapendak sakaligus upami klien naroskeun versi.

4. Data cache

Panyangga MemStore sareng BlockCache nempatan nepi ka 80% tina mémori RS on-numpuk anu dialokasikeun (sésana ditangtayungan pikeun tugas layanan RS). Upami modeu pamakean khas nyaéta prosés nyerat sareng langsung maca data anu sami, maka masuk akal pikeun ngirangan BlockCache sareng ningkatkeun MemStore, sabab Nalika nulis data henteu asup kana cache pikeun maca, BlockCache bakal dianggo kirang sering. BlockCache panyangga diwangun ku dua bagian: LruBlockCache (salawasna on-numpuk) jeung BucketCache (biasana off-numpuk atawa dina SSD). BucketCache kudu dipake lamun aya loba requests bacaan sarta aranjeunna teu cocog kana LruBlockCache, nu ngakibatkeun karya aktip ti Kolektor Sampah. Dina waktos anu sami, anjeun henteu kedah ngarep-ngarep kanaékan radikal dina pagelaran tina ngagunakeun cache anu dibaca, tapi urang bakal uih deui kana paragraf 8.

Aya hiji BlockCache pikeun sakabéh RS, tur aya hiji MemStore pikeun tiap méja (hiji pikeun tiap kulawarga Kolom).

kumaha digambarkeun dina tiori, nalika nulis, data teu lebet kana cache sarta memang, parameter sapertos CACHE_DATA_ON_WRITE pikeun tabel sarta "Cache DATA on Tulis" pikeun RS disetel ka palsu. Nanging, dina prakna, upami urang nyerat data ka MemStore, teras siram kana disk (sahingga ngabersihan), teras ngahapus file anu hasilna, teras ku ngalaksanakeun pamundut get kami bakal suksés nampi data. Leuwih ti éta, sanajan anjeun sagemblengna nganonaktipkeun BlockCache sarta eusian tabel kalawan data anyar, lajeng ngareset MemStore ka disk, ngahapus aranjeunna sarta ménta aranjeunna ti sési sejen, aranjeunna tetep bakal dipulut ti mana. Janten HBase nyimpen henteu ngan ukur data, tapi ogé misteri anu 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 on Read" disetel ka palsu. Upami anjeun ngagaduhan ideu, wilujeng ngabahas éta dina koméntar.

5. Angkatan ngolah data MultiGet / MultiPut

Ngolah requests tunggal (Meunangkeun / Pasang / Pupus) operasi cukup mahal, jadi lamun mungkin, anjeun kudu ngagabungkeun kana Daptar atawa Daptar, nu ngidinan Anjeun pikeun meunang hiji dorongan kinerja signifikan. Ieu hususna leres pikeun operasi nulis, tapi nalika maca aya pitfall handap. Grafik di handap nembongkeun waktu maca 50 rékaman ti MemStore. Bacaan ieu dilakukeun dina hiji benang sareng sumbu horizontal nunjukkeun jumlah konci dina pamundut. Di dieu anjeun tiasa ningali yén nalika ningkat kana sarébu konci dina hiji pamundut, waktos palaksanaan turun, i.e. laju nambahan. Sanajan kitu, kalawan modeu MSLAB diaktipkeun sacara standar, sanggeus bangbarung ieu serelek radikal dina kinerja dimimitian, sarta jumlah badag data dina catetan, beuki lila waktu operasi.

Tés anu dipigawé dina mesin virtual, 8 cores, Vérsi HBase 2.0.0-cdh6.0.0-beta1.

Modeu MSLAB dirancang pikeun ngurangan fragméntasi numpuk, nu lumangsung alatan campur data generasi anyar jeung heubeul. Salaku workaround a, nalika MSLAB diaktipkeun, data disimpen kana sél relatif leutik (sapotong) jeung diolah dina sakumpulan. Hasilna, nalika volume dina pakét data anu dipénta ngaleuwihan ukuran anu dialokasikeun, kinerja turun drastis. Di sisi anu sanésna, mareuman modeu ieu ogé henteu disarankeun, sabab éta bakal nyababkeun lirén kusabab GC nalika ngolah data anu intensif. Hiji leyuran alus nyaéta pikeun ngaronjatkeun volume sél dina kasus tulisan aktip via nempatkeun sakaligus kalawan bacaan. Perlu dicatet yén masalahna henteu lumangsung upami, saatos ngarékam, anjeun ngajalankeun paréntah siram, anu ngareset MemStore kana disk, atanapi upami anjeun ngamuat nganggo BulkLoad. Tabel di handap ieu nunjukkeun yén pamundut ti MemStore pikeun data anu langkung ageung (sareng jumlah anu sami) nyababkeun kalambatan. Sanajan kitu, ku cara ningkatkeun chunksize urang balikkeun waktu processing ka normal.

Salian ngaronjatna chunksize, ngabagi data dumasar wewengkon mantuan, i.e. méja pamisah. Ieu nyababkeun pangsaeutikna paménta anu datang ka unggal daérah sareng upami aranjeunna pas kana sél, résponna tetep saé.

6. Stratégi pikeun ngabagi tabel kana daérah (splitting)

Kusabab HBase mangrupikeun panyimpen nilai konci sareng pamisahan dilaksanakeun ku konci, penting pisan pikeun ngabagi data sacara merata ka sadaya daérah. Salaku conto, ngabagi méja sapertos kana tilu bagian bakal nyababkeun data dibagi kana tilu daérah:

Ieu kajadian yén ieu ngabalukarkeun slowdown seukeut lamun data dimuat engké kasampak kawas, contona, nilai panjang, lolobana aranjeunna dimimitian ku angka nu sami, contona:

1000001
1000002
...
1100003

Kusabab kenop nu disimpen salaku Asép Sunandar Sunarya bait, aranjeunna sadayana bakal ngamimitian sarua jeung milik wewengkon sarua # 1 nyimpen rentang ieu konci. Aya sababaraha strategi partisi:

HexStringSplit - Ngarobih konci janten senar anu disandikeun heksadesimal dina rentang "00000000" => "FFFFFFFF" sareng padding kénca sareng nol.

UniformSplit - Ngahurungkeun konci kana Asép Sunandar Sunarya bait kalawan encoding héksadesimal dina rentang "00" => "FF" jeung padding di katuhu jeung nol.

Salaku tambahan, anjeun tiasa netepkeun rentang atanapi set konci pikeun ngabagi sareng ngonpigurasikeun pamisah otomatis. Tapi, salah sahiji pendekatan anu pangbasajanna sareng paling efektif nyaéta UniformSplit sareng panggunaan panyambungan hash, contona pasangan bait anu paling penting tina ngajalankeun konci ngaliwatan fungsi CRC32(rowkey) sareng rowkey sorangan:

hash + rowkey

Lajeng sadaya data bakal disebarkeun merata sakuliah wewengkon. Nalika maca, dua bait munggaran ngan saukur dipiceun sareng konci aslina tetep. RS ogé ngatur jumlah data sareng konci di daérah sareng, upami watesna ngaleuwihan, otomatis ngarecah kana sababaraha bagian.

7. Kasabaran sesar jeung data locality

Kusabab ngan ukur hiji daérah anu tanggung jawab pikeun unggal set konci, solusi pikeun masalah anu aya hubunganana sareng kacilakaan RS atanapi decommissioning nyaéta pikeun nyimpen sadaya data anu diperyogikeun dina HDFS. Nalika RS ragrag, master ngadeteksi ieu kusabab henteuna denyut jantung dina titik ZooKeeper. Teras napelkeun daérah anu dilayanan ka RS anu sanés sareng saprak HFiles disimpen dina sistem file anu disebarkeun, pamilik énggal maca aranjeunna sareng teras nyayogikeun data. Nanging, sabab sababaraha data tiasa aya dina MemStore sareng henteu gaduh waktos pikeun asup kana HFiles, WAL, anu ogé disimpen dina HDFS, dianggo pikeun mulangkeun sajarah operasi. Saatos parobihan diterapkeun, RS tiasa ngabales pamenta, tapi gerakanna nyababkeun kanyataan yén sababaraha data sareng prosés ngalayanan aranjeunna ditungtungan dina titik anu béda, i.e. lokalitas nurun.

Solusi pikeun masalahna nyaéta compaction utama - prosedur ieu mindahkeun file ka titik-titik anu tanggung jawab aranjeunna (dimana daérahna aya), salaku akibat tina prosedur ieu beban dina jaringan sareng disk ningkat sacara signifikan. Sanajan kitu, dina mangsa nu bakal datang, aksés ka data ieu noticeably gancangan. Sajaba ti éta, major_compaction ngalakukeun merging sadaya HFiles kana hiji file dina hiji wewengkon, sarta ogé cleans up data gumantung kana setélan méja. Contona, Anjeun bisa nangtukeun jumlah versi hiji obyék nu kudu dipikagaduh atawa hirupna sanggeus obyék ieu dihapus sacara fisik.

Prosedur ieu tiasa gaduh pangaruh anu positip dina operasi HBase. Gambar di handap nembongkeun kumaha kinerja didegradasi salaku hasil tina rekaman data aktip. Di dieu anjeun tiasa ningali kumaha 40 benang nyerat kana hiji méja sareng 40 benang sakaligus maca data. Nulis threads ngahasilkeun beuki loba HFiles, nu dibaca ku threads séjén. Hasilna, beuki loba data kudu dipiceun tina mémori sarta ahirna GC mimiti jalan, nu praktis lumpuh sadaya karya. Peluncuran compaction utama nyababkeun ngabersihkeun lebu anu hasilna sareng pamulihan produktivitas.

Tés dilaksanakeun dina 3 DataNodes sareng 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 benang). Vérsi HBase 1.2.0-cdh5.14.2

Perlu dicatet yén compaction utama diluncurkeun dina tabel "live", dimana data aktip ditulis sareng dibaca. Aya pernyataan online yén ieu tiasa nyababkeun réspon anu salah nalika maca data. Pikeun pariksa, diluncurkeun prosés anu ngahasilkeun data énggal sareng nyerat kana méja. Saatos éta kuring langsung maca sareng pariksa naha nilai anu hasilna cocog sareng anu diserat. Nalika prosés ieu dijalankeun, kompaksi utama dijalankeun sakitar 200 kali sareng henteu aya gagalna tunggal anu kacatet. Panginten masalahna jarang muncul sareng ngan ukur dina beban anu luhur, janten langkung aman pikeun ngeureunkeun prosés nyerat sareng maca sakumaha anu direncanakeun sareng ngalaksanakeun beberesih pikeun nyegah drawdowns GC sapertos kitu.

Ogé, compaction utama henteu mangaruhan kaayaan MemStore; pikeun siram kana disk jeung compactify eta, anjeun kudu make siram (connection.getAdmin ().flush (TableName.valueOf (tblName))).

8. Setélan jeung kinerja

Sakumaha anu parantos disebatkeun, HBase nunjukkeun kasuksésan anu paling hébat dimana éta henteu kedah ngalakukeun nanaon, nalika ngalaksanakeun BulkLoad. Nanging, ieu manglaku ka kalolobaan sistem sareng jalma. Sanajan kitu, alat ieu leuwih cocog pikeun nyimpen data dina bulk dina blok badag, sedengkeun lamun prosés merlukeun sababaraha competing maca jeung nulis requests, nu Get and Put paréntah ditétélakeun di luhur dipaké. Pikeun nangtoskeun parameter optimal, peluncuran dilaksanakeun kalayan sababaraha kombinasi parameter sareng setélan tabel:

• 10 benang diluncurkeun sakaligus 3 kali berturut-turut (nyaéta ieu blok benang).
• Waktu operasi sadaya benang dina blok dirata-rata sareng mangrupikeun hasil ahir tina operasi blok.
• Sadaya benang damel sareng méja anu sami.
• Sateuacan unggal ngamimitian blok thread, compaction utama dilaksanakeun.
• Unggal blok ngan ukur ngalaksanakeun salah sahiji operasi di handap ieu:

— Nempatkeun
— Kéngingkeun
— Kéngingkeun + Pasang

• Unggal blok ngalaksanakeun 50 iterasi operasina.
• Ukuran blok rékaman nyaéta 100 bait, 1000 bait atanapi 10000 bait (acak).
• Blok diluncurkeun kalayan nomer anu béda-béda konci anu dipénta (boh hiji konci atanapi 10).
• Blok dijalankeun dina setélan méja anu béda. Parameter robah:

— BlockCache = dihurungkeun atawa pareum
- Ukuran Blok = 65 KB atanapi 16 KB
- Partisi = 1, 5 atanapi 30
- MSLAB = diaktipkeun atawa ditumpurkeun

Janten blokna sapertos kieu:

a. Modeu MSLAB dihurungkeun/pareum.
b. A tabel dijieun pikeun nu parameter di handap ieu diatur: BlockCache = leres / taya, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Komprési disetel ka GZ.
d. 10 threads diluncurkeun sakaligus ngalakukeun 1/10 put / get / get + put operasi kana tabél ieu kalayan rékaman 100/1000/10000 byte, ngajalankeun 50 queries dina urutan (konci acak).
e. Titik d diulang tilu kali.
f. Waktu operasi sadaya benang dirata-rata.

Sadaya kombinasi anu mungkin diuji. Bisa diprediksi yén laju bakal turun nalika ukuran catetan naék, atanapi nganonaktipkeun cache bakal nyababkeun slowdown. Sanajan kitu, tujuanana nya éta pikeun ngarti darajat jeung significance tina pangaruh unggal parameter, jadi data dikumpulkeun ieu fed kana input fungsi régrési linier, nu ngamungkinkeun pikeun assess signifikansi ngagunakeun t-statistika. Di handap ieu hasil tina blok ngajalankeun operasi Put. set pinuh ku kombinasi 2 * 2 * 3 * 2 * 3 = 144 pilihan + 72 tk. sababaraha dipigawé dua kali. Ku kituna, jumlahna aya 216:

Uji coba dilaksanakeun dina klaster mini anu diwangun ku 3 DataNodes sareng 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 benang). Vérsi HBase 1.2.0-cdh5.14.2.

Laju sisipan pangluhurna 3.7 detik dicandak ku modeu MSLAB dipareuman, dina méja kalayan hiji partisi, sareng BlockCache diaktipkeun, BlockSize = 16, rékaman 100 bait, 10 potongan per pak.
Laju sisipan panghandapna 82.8 detik dicandak ku mode MSLAB diaktipkeun, dina méja kalayan hiji partisi, sareng BlockCache diaktipkeun, BlockSize = 16, rékaman 10000 bait, 1 unggal.

Ayeuna hayu urang nempo model. Simkuring ningali kualitas alus model dumasar kana R2, tapi jelas pisan yén extrapolation ieu contraindicated dieu. Paripolah sabenerna sistem nalika parameter robah moal linier; model ieu diperlukeun henteu keur prediksi, tapi pikeun pamahaman naon anu lumangsung dina parameter dibikeun. Salaku conto, di dieu urang ningali tina kriteria Siswa yén parameter BlockSize sareng BlockCache henteu masalah pikeun operasi Put (anu umumna tiasa diprediksi):

Tapi kanyataan yén ngaronjatna jumlah partisi ngabalukarkeun panurunan dina kinerja rada teu kaduga (urang geus katempo dampak positif ngaronjatna jumlah partisi jeung BulkLoad), sanajan kaharti. Firstly, pikeun ngolah, anjeun kudu ngahasilkeun requests ka 30 wewengkon tinimbang hiji, sarta volume data henteu sapertos nu ieu bakal ngahasilkeun gain. Bréh, total waktu operasi ditangtukeun ku RS slowest, sarta saprak jumlah DataNodes kirang ti jumlah RS, sababaraha wewengkon boga nol locality. Nya, hayu urang tingali lima luhur:

Ayeuna hayu urang evaluasi hasil tina palaksanaan blok Get:

Jumlah partisi geus leungit significance, nu meureun dipedar ku kanyataan yén data ieu sindangan ogé sarta cache dibaca teh parameter paling signifikan (statistik). Alami, nambahan jumlah pesen dina pamundut ogé pohara kapaké pikeun kinerja. Skor pangluhurna:

Nya, tungtungna, hayu urang tingali modél blok anu mimiti dilaksanakeun get teras pasang:

Sadaya parameter penting di dieu. Jeung hasil pamingpin:

9. nguji beban

Nya, tungtungna urang bakal ngaluncurkeun beban anu langkung saé, tapi éta langkung narik nalika anjeun gaduh anu dibandingkeun. Dina situs wéb DataStax, pamekar konci Cassandra, aya hasil NT tina sababaraha gudang NoSQL, kaasup versi HBase 0.98.6-1. Loading dilaksanakeun ku 40 threads, ukuran data 100 bait, disk SSD. Hasil nguji operasi Baca-Modifikasi-Tulis némbongkeun hasil di handap ieu.

Sajauh anu kuring ngartos, bacaan dilaksanakeun dina blok 100 rékaman sareng pikeun 16 titik HBase, uji DataStax nunjukkeun pagelaran 10 rébu operasi per detik.

Untungna klaster urang ogé 16 titik, tapi teu pisan "untung" nu masing-masing boga 64 cores (threads), bari di test DataStax aya ngan 4. Di sisi séjén, maranéhna boga drive SSD, bari urang boga HDDs. atawa leuwih versi anyar HBase na CPU utilization salila beban praktis teu ngaronjat sacara signifikan (visually ku 5-10 persen). Nanging, hayu urang cobian ngamimitian nganggo konfigurasi ieu. Setélan tabel standar, bacaan dipigawé dina rentang konci ti 0 nepi ka 50 juta acak (ie, dasarna anyar unggal waktu). tabél ngandung 50 juta rékaman, dibagi kana 64 partitions. Koncina di-hashed nganggo crc32. Setélan méja standar, MSLAB diaktipkeun. Ngaluncurkeun 40 utas, unggal utas maca sakumpulan 100 konci acak sareng langsung nyerat 100 bait anu dihasilkeun deui kana konci ieu.

Nangtung: 16 DataNode jeung 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Vérsi HBase 1.2.0-cdh5.14.2.

Hasil rata-rata langkung caket kana 40 rébu operasi per detik, anu langkung saé tibatan dina uji DataStax. Nanging, pikeun tujuan ékspérimén, anjeun tiasa rada ngarobih kaayaan. Ieu rada saperti teu mirip yen sakabeh pagawean bakal dilumangsungkeun éksklusif dina hiji méja, sarta ogé ngan dina kenop unik. Hayu urang nganggap yén aya sababaraha set konci "panas" anu ngahasilkeun beban utama. Ku alatan éta, hayu urang cobaan nyieun beban kalawan rékaman gedé (10 KB), ogé dina bets 100, dina 4 tabel béda jeung ngawatesan rentang konci dipénta nepi ka 50 sarébu. Grafik di handap nembongkeun peluncuran 40 threads, unggal thread maca. susunan 100 kenop jeung geura nulis acak 10 KB on kenop ieu balik.

Nangtung: 16 DataNode jeung 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Vérsi HBase 1.2.0-cdh5.14.2.

Salila beban, compaction utama diluncurkeun sababaraha kali, sapertos anu dipidangkeun di luhur, tanpa prosedur ieu, kinerja laun-laun bakal nguraikeun, tapi beban tambahan ogé timbul nalika palaksanaan. Drawdowns disababkeun ku sababaraha alesan. Kadang-kadang utas réngsé damel sareng aya jeda nalika di-restart, sakapeung aplikasi pihak katilu nyiptakeun beban dina kluster.

Maca sareng langsung nyerat mangrupikeun salah sahiji skenario padamelan anu paling hese pikeun HBase. Upami anjeun ngan ukur ngadamel pamundut anu leutik, contona 100 bait, ngagabungkeun kana bungkus 10-50 rébu potongan, anjeun tiasa nampi ratusan rébu operasi per detik, sareng kaayaanna sami sareng pamundut anu dibaca wungkul. Perlu dicatet yén hasilna sacara radikal langkung saé tibatan anu diala ku DataStax, kalolobaanana kusabab pamenta dina blok 50 rébu.

Nangtung: 16 DataNode jeung 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Vérsi HBase 1.2.0-cdh5.14.2.

10. Kacindekan

Sistim ieu rada flexibly ngonpigurasi, tapi pangaruh angka nu gede ngarupakeun parameter tetep kanyahoan. Sababaraha di antarana anu diuji, tapi teu kaasup dina set test hasilna. Contona, percobaan awal némbongkeun significance teu signifikan tina parameter kayaning DATA_BLOCK_ENCODING, nu encode informasi ngagunakeun nilai ti sél tatangga, nu kaharti pikeun data dihasilkeun acak. Lamun make angka nu gede ngarupakeun duplikat objék, gain bisa jadi signifikan. Sacara umum, urang tiasa nyebatkeun yén HBase masihan gambaran ngeunaan database anu cukup serius sareng panginten-kaluar, anu tiasa rada produktif nalika ngalaksanakeun operasi kalayan blok data anu ageung. Utamana upami tiasa misahkeun prosés maca sareng nyerat dina waktosna.

Lamun aya hal dina pamadegan anjeun anu teu cukup diungkabkeun, Kami siap ngabejaan Anjeun leuwih jéntré. Kami ngajak anjeun ngabagi pangalaman atanapi ngabahas upami anjeun teu satuju sareng hiji hal.

sumber: www.habr.com