Habari za mchana Jina langu ni Danil Lipovoy, timu yetu katika Sbertech ilianza kutumia HBase kama hifadhi ya data ya uendeshaji. Wakati wa kuisoma, uzoefu umekusanya ambao nilitaka kuweka utaratibu na kuelezea (tunatumai kuwa itakuwa muhimu kwa wengi). Majaribio yote yaliyo hapa chini yalifanywa kwa matoleo ya HBase 1.2.0-cdh5.14.2 na 2.0.0-cdh6.0.0-beta1.
- Usanifu wa jumla
- Kuandika data kwa HBASE
- Kusoma data kutoka HBASE
- Uhifadhi wa Data
- Usindikaji wa data wa kundi MultiGet/MultiPut
- Mkakati wa kugawanya meza katika kanda (kugawanyika)
- Uvumilivu wa makosa, ujumuishaji na eneo la data
- Mipangilio na utendaji
- Mtihani wa Stress
- Matokeo
1. Usanifu wa jumla
Mwalimu wa chelezo husikiza mapigo ya moyo ya inayofanya kazi kwenye nodi ya ZooKeeper na, ikiwa itatoweka, huchukua kazi za bwana.
2. Andika data kwa HBASE
Kwanza, hebu tuangalie kesi rahisi zaidi - kuandika kitu cha thamani-msingi kwenye meza kwa kutumia put(rowkey). Mteja lazima kwanza ajue mahali ambapo Root Region Server (RRS), ambayo huhifadhi hbase:meta meza, iko. Anapokea habari hii kutoka kwa ZooKeeper. Baada ya hapo hufikia RRS na kusoma jedwali la hbase:meta, ambalo hutoa maelezo kuhusu ni RegionServer (RS) inayohusika na kuhifadhi data ya safu ya safu iliyopewa kwenye jedwali la vivutio. Kwa matumizi ya baadaye, jedwali la meta limehifadhiwa na mteja na kwa hivyo simu zinazofuata huenda haraka, moja kwa moja kwa RS.
Ifuatayo, RS, baada ya kupokea ombi, kwanza kabisa huiandikia AndikaAheadLog (WAL), ambayo ni muhimu kwa ajili ya kurejesha katika kesi ya ajali. Kisha huhifadhi data kwenye MemStore. Hii ni bafa katika kumbukumbu ambayo ina seti ya vitufe vilivyopangwa kwa eneo fulani. Jedwali linaweza kugawanywa katika mikoa (partitions), ambayo kila moja ina seti ya funguo zisizounganishwa. Hii hukuruhusu kuweka maeneo kwenye seva tofauti ili kufikia utendaji wa juu. Walakini, licha ya udhahiri wa taarifa hii, tutaona baadaye kwamba hii haifanyi kazi katika hali zote.
Baada ya kuweka ingizo kwenye MemStore, jibu hurejeshwa kwa mteja kwamba ingizo lilihifadhiwa kwa mafanikio. Walakini, kwa ukweli huhifadhiwa tu kwenye buffer na huingia kwenye diski tu baada ya muda fulani kupita au wakati imejazwa na data mpya.
Wakati wa kufanya operesheni ya "Futa", data haifutwa kimwili. Zimewekwa alama kama zimefutwa, na uharibifu wenyewe hutokea wakati wa kupiga kazi kuu ya kompakt, ambayo imeelezewa kwa undani zaidi katika aya ya 7.
Faili katika umbizo la HFile hukusanywa katika HDFS na mara kwa mara mchakato mdogo wa kompakt huzinduliwa, ambao huunganisha faili ndogo na kuwa kubwa bila kufuta chochote. Baada ya muda, hii inageuka kuwa shida ambayo inaonekana tu wakati wa kusoma data (tutarejea kwa hili baadaye kidogo).
Mbali na mchakato wa upakiaji ulioelezwa hapo juu, kuna utaratibu mzuri zaidi, ambao labda ni upande wenye nguvu wa hifadhidata hii - BulkLoad. Iko katika ukweli kwamba sisi hutengeneza HFiles kwa kujitegemea na kuziweka kwenye diski, ambayo inaruhusu sisi kupima kikamilifu na kufikia kasi nzuri sana. Kwa kweli, kizuizi hapa sio HBase, lakini uwezo wa vifaa. Yafuatayo ni matokeo ya kuwasha kwenye kundi linalojumuisha 16 RegionServers na 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64), toleo la HBase 1.2.0-cdh5.14.2.
Hapa unaweza kuona kwamba kwa kuongeza idadi ya partitions (mikoa) kwenye meza, pamoja na watekelezaji wa Spark, tunapata ongezeko la kasi ya kupakua. Pia, kasi inategemea kiasi cha kurekodi. Vitalu vikubwa hutoa ongezeko la MB/sekunde, vizuizi vidogo katika idadi ya rekodi zilizoingizwa kwa kila kitengo cha muda, vitu vingine vyote vikiwa sawa.
Unaweza pia kuanza kupakia kwenye meza mbili kwa wakati mmoja na kupata kasi mara mbili. Hapo chini unaweza kuona kwamba kuandika vizuizi vya KB 10 kwa meza mbili mara moja hufanyika kwa kasi ya takriban 600 MB/sec kwa kila moja (jumla ya 1275 MB/sec), ambayo inaambatana na kasi ya kuandika kwenye jedwali moja 623 MB/sec (angalia Nambari 11 hapo juu)
Lakini kukimbia kwa pili na rekodi za KB 50 inaonyesha kwamba kasi ya kupakua inakua kidogo, ambayo inaonyesha kuwa inakaribia maadili ya kikomo. Wakati huo huo, unahitaji kukumbuka kuwa hakuna mzigo wowote iliyoundwa kwenye HBASE yenyewe, kinachohitajika ni kutoa data kutoka kwa hbase:meta, na baada ya kuweka HFiles, weka upya data ya BlockCache na uhifadhi faili. Bafa ya MemStore kwenye diski, ikiwa si tupu.
3. Kusoma data kutoka HBASE
Ikiwa tunadhania kwamba mteja tayari ana taarifa zote kutoka kwa hbase:meta (angalia hatua ya 2), basi ombi huenda moja kwa moja kwa RS ambapo ufunguo unaohitajika umehifadhiwa. Kwanza, utafutaji unafanywa katika MemCache. Bila kujali kama kuna data huko au la, utafutaji pia unafanywa katika bafa ya BlockCache na, ikiwa ni lazima, katika HFiles. Ikiwa data ilipatikana kwenye faili, itawekwa kwenye BlockCache na itarejeshwa haraka zaidi kwa ombi linalofuata. Kutafuta katika HFile ni shukrani ya haraka kwa matumizi ya chujio cha Bloom, i.e. baada ya kusoma kiasi kidogo cha data, huamua mara moja ikiwa faili hii ina ufunguo unaohitajika na ikiwa sio, kisha huenda kwenye ijayo.
Baada ya kupokea data kutoka kwa vyanzo hivi vitatu, RS hutoa majibu. Hasa, inaweza kuhamisha matoleo kadhaa yaliyopatikana ya kitu mara moja ikiwa mteja aliomba toleo.
4. Uhifadhi wa data
Vihifadhi vya MemStore na BlockCache huchukua hadi 80% ya kumbukumbu ya RS iliyotengwa kwenye lundo (zilizosalia zimehifadhiwa kwa kazi za huduma za RS). Ikiwa hali ya matumizi ya kawaida ni kwamba michakato huandika na kusoma mara moja data sawa, basi ni busara kupunguza BlockCache na kuongeza MemStore, kwa sababu Wakati kuandika data haiingii kwenye kache ya kusoma, BlockCache itatumika mara chache. Bafa ya BlockCache ina sehemu mbili: LruBlockCache (daima iko kwenye lundo) na BucketCache (kawaida iko kwenye lundo au kwenye SSD). BucketCache inapaswa kutumika wakati kuna maombi mengi ya kusoma na hayaendani na LruBlockCache, ambayo husababisha kazi hai ya Ukusanyaji wa Taka. Wakati huo huo, haupaswi kutarajia ongezeko kubwa la utendaji kutoka kwa kutumia kashe iliyosomwa, lakini tutarudi kwa hii katika aya ya 8.
Kuna BlockCache moja kwa RS nzima, na kuna MemStore moja kwa kila jedwali (moja kwa kila Safu ya Familia).
Kama kwa nadharia, wakati wa kuandika, data haiingii kwenye akiba na kwa hakika, vigezo kama hivyo CACHE_DATA_ON_WRITE vya jedwali na "Cache DATA on Write" kwa RS vimewekwa kuwa sivyo. Hata hivyo, kwa mazoezi, ikiwa tunaandika data kwa MemStore, kisha tuifute kwenye diski (hivyo kuifuta), kisha ufute faili inayosababisha, kisha kwa kutekeleza ombi la kupata tutapokea data kwa ufanisi. Zaidi ya hayo, hata ukizima kabisa BlockCache na ujaze jedwali na data mpya, kisha uweke upya MemStore kwenye diski, uifute na uiombe kutoka kwenye kikao kingine, bado itarejeshwa kutoka mahali fulani. Kwa hivyo HBase huhifadhi data tu, bali pia siri za ajabu.
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
Kigezo cha "Cache DATA on Read" kimewekwa kuwa sivyo. Ikiwa una mawazo yoyote, karibu kujadili katika maoni.
5. Usindikaji wa data wa kundi MultiGet/MultiPut
Kuchakata maombi moja (Pata/Weka/Futa) ni operesheni ya gharama kubwa sana, kwa hivyo ikiwezekana, unapaswa kuyachanganya katika Orodha au Orodha, ambayo hukuruhusu kupata ongezeko kubwa la utendaji. Hii ni kweli hasa kwa uendeshaji wa kuandika, lakini wakati wa kusoma kuna shida ifuatayo. Grafu iliyo hapa chini inaonyesha muda wa kusoma rekodi 50 kutoka MemStore. Usomaji ulifanywa kwa uzi mmoja na mhimili mlalo unaonyesha idadi ya funguo katika ombi. Hapa unaweza kuona kwamba wakati wa kuongezeka kwa funguo elfu katika ombi moja, wakati wa utekelezaji unashuka, i.e. kasi inaongezeka. Hata hivyo, hali ya MSLAB ikiwa imewezeshwa kwa chaguo-msingi, baada ya kizingiti hiki kushuka kwa kiasi kikubwa kwa utendakazi huanza, na kadiri idadi ya data kwenye rekodi inavyoongezeka, ndivyo muda wa kufanya kazi unavyoongezeka.
Majaribio yalifanywa kwenye mashine pepe, cores 8, toleo la HBase 2.0.0-cdh6.0.0-beta1.
Hali ya MSLAB imeundwa ili kupunguza mgawanyiko wa lundo, ambayo hutokea kutokana na kuchanganya data ya kizazi kipya na cha zamani. Kama suluhisho, wakati MSLAB imewashwa, data huwekwa kwenye seli ndogo (chunks) na kuchakatwa katika vipande. Matokeo yake, wakati sauti katika pakiti ya data iliyoombwa inazidi ukubwa uliotengwa, utendaji hupungua kwa kasi. Kwa upande mwingine, kuzima hali hii pia haipendekezi, kwani itasababisha kusimamishwa kwa sababu ya GC wakati wa usindikaji mkubwa wa data. Suluhisho nzuri ni kuongeza kiasi cha seli katika kesi ya uandishi amilifu kupitia kuweka wakati huo huo na kusoma. Ni muhimu kuzingatia kwamba tatizo halifanyiki ikiwa, baada ya kurekodi, unaendesha amri ya flush, ambayo huweka upya MemStore kwenye diski, au ikiwa unapakia kwa kutumia BulkLoad. Jedwali lililo hapa chini linaonyesha kuwa hoja kutoka kwa MemStore za data kubwa (na kiasi sawa) husababisha kupungua kwa kasi. Hata hivyo, kwa kuongeza chunksize tunarudisha muda wa usindikaji kwa kawaida.
Mbali na kuongeza chunksize, kugawanya data kwa kanda husaidia, i.e. kugawanyika kwa meza. Hii husababisha maombi machache kuja kwa kila eneo na yakitoshea kwenye seli, majibu yanasalia kuwa mazuri.
6. Mkakati wa kugawanya meza katika kanda (kugawanyika)
Kwa kuwa HBase ni hifadhi ya thamani-msingi na ugawaji unafanywa na ufunguo, ni muhimu sana kugawanya data sawasawa katika maeneo yote. Kwa mfano, kugawa jedwali kama hilo katika sehemu tatu kutasababisha data kugawanywa katika maeneo matatu:
Inatokea kwamba hii inasababisha kushuka kwa kasi ikiwa data iliyopakiwa baadaye inaonekana kama, kwa mfano, maadili marefu, wengi wao wakianza na tarakimu sawa, kwa mfano:
1000001
1000002
...
1100003
Kwa kuwa funguo zimehifadhiwa kama safu ya baiti, zote zitaanza sawa na zitakuwa za eneo moja # 1 linalohifadhi safu hii ya funguo. Kuna mikakati kadhaa ya kugawanya:
HexStringSplit β Hugeuza ufunguo kuwa mfuatano wa heksadesimali uliosimbwa katika masafa "00000000" => "FFFFFFFF" na kuweka sufuri upande wa kushoto.
UniformSplit - Hugeuza ufunguo kuwa safu ya baiti yenye usimbaji wa heksadesimali katika masafa "00" => "FF" na kuweka sifuri upande wa kulia.
Kwa kuongeza, unaweza kutaja safu yoyote au seti ya funguo za kugawanya na kusanidi mgawanyiko wa kiotomatiki. Hata hivyo, mojawapo ya mbinu rahisi na bora zaidi ni UniformSplit na matumizi ya upatanisho wa heshi, kwa mfano jozi muhimu zaidi ya baiti kutoka kwa ufunguo kupitia kitendakazi cha CRC32(rowkey) na ufunguo wa safu yenyewe:
hash + rowkey
Kisha data zote zitasambazwa sawasawa katika mikoa yote. Wakati wa kusoma, ka mbili za kwanza hutupwa tu na ufunguo wa asili unabaki. RS pia hudhibiti kiasi cha data na funguo katika eneo na, ikiwa mipaka imepitwa, huivunja kiotomatiki katika sehemu.
7. Uvumilivu wa makosa na eneo la data
Kwa kuwa eneo moja tu ndilo linalowajibika kwa kila seti ya funguo, suluhisho la matatizo yanayohusiana na RS kuacha kufanya kazi au kughairi ni kuhifadhi data zote muhimu katika HDFS. Wakati RS inapoanguka, bwana hutambua hili kwa kutokuwepo kwa mapigo ya moyo kwenye nodi ya ZooKeeper. Kisha inapeana eneo lililohudumiwa kwa RS nyingine na kwa kuwa HFiles zimehifadhiwa katika mfumo wa faili uliosambazwa, mmiliki mpya anazisoma na anaendelea kutumikia data. Hata hivyo, kwa kuwa baadhi ya data inaweza kuwa katika MemStore na hakuwa na muda wa kuingia kwenye HFiles, WAL, ambayo pia imehifadhiwa katika HDFS, hutumiwa kurejesha historia ya uendeshaji. Baada ya mabadiliko kutumika, RS inaweza kujibu maombi, lakini hatua hiyo inaongoza kwa ukweli kwamba baadhi ya data na taratibu zinazowahudumia huishia kwenye nodes tofauti, i.e. eneo linapungua.
Suluhisho la tatizo ni compaction kubwa - utaratibu huu huhamisha faili kwa nodes hizo ambazo zinawajibika kwao (ambapo mikoa yao iko), kwa sababu hiyo wakati wa utaratibu huu mzigo kwenye mtandao na disks huongezeka kwa kasi. Walakini, katika siku zijazo, ufikiaji wa data unaharakishwa dhahiri. Kwa kuongeza, major_compaction hufanya kuunganisha HFiles zote kwenye faili moja ndani ya eneo, na pia husafisha data kulingana na mipangilio ya jedwali. Kwa mfano, unaweza kubainisha idadi ya matoleo ya kitu ambacho lazima kihifadhiwe au muda wote wa maisha ambapo kipengee kitafutwa.
Utaratibu huu unaweza kuwa na athari nzuri sana juu ya uendeshaji wa HBase. Picha iliyo hapa chini inaonyesha jinsi utendaji ulivyoharibika kwa sababu ya kurekodi data amilifu. Hapa unaweza kuona jinsi nyuzi 40 ziliandika kwa jedwali moja na nyuzi 40 wakati huo huo kusoma data. Nyuzi za uandishi huzalisha HFiles zaidi na zaidi, ambazo husomwa na nyuzi zingine. Matokeo yake, data zaidi na zaidi inahitaji kuondolewa kwenye kumbukumbu na hatimaye GC huanza kufanya kazi, ambayo inalemaza kazi zote. Uzinduzi wa ukandamizaji mkubwa ulisababisha kuondolewa kwa uchafu uliosababisha na kurejesha tija.
Jaribio lilifanywa kwenye DataNodes 3 na 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64). Toleo la HBase 1.2.0-cdh5.14.2
Inafaa kumbuka kuwa ujumuishaji mkubwa ulizinduliwa kwenye jedwali la "moja kwa moja", ambalo data iliandikwa na kusomwa kikamilifu. Kulikuwa na taarifa mtandaoni kwamba hii inaweza kusababisha jibu lisilo sahihi wakati wa kusoma data. Ili kuangalia, mchakato ulizinduliwa ambao ulitoa data mpya na kuiandika kwenye jedwali. Baada ya hapo nilisoma mara moja na kuangalia ikiwa thamani iliyosababishwa inalingana na kile kilichoandikwa. Wakati mchakato huu ukiendelea, upunguzaji mkubwa uliendeshwa takriban mara 200 na hakuna kushindwa hata moja kurekodiwa. Labda shida huonekana mara chache na wakati wa mzigo wa juu tu, kwa hivyo ni salama kusimamisha michakato ya uandishi na usomaji kama ilivyopangwa na kufanya usafishaji ili kuzuia miteremko kama hiyo ya GC.
Pia, mkato mkubwa hauathiri hali ya MemStore; ili kuivuta hadi kwenye diski na kuibana, unahitaji kutumia flush (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Mipangilio na utendaji
Kama ilivyotajwa tayari, HBase inaonyesha mafanikio yake makubwa ambapo haitaji kufanya chochote, wakati wa kutekeleza BulkLoad. Walakini, hii inatumika kwa mifumo na watu wengi. Hata hivyo, zana hii inafaa zaidi kwa kuhifadhi data kwa wingi katika vizuizi vikubwa, ambapo ikiwa mchakato unahitaji maombi mengi ya ushindani ya kusoma na kuandika, amri za Pata na Weka zilizoelezwa hapo juu hutumiwa. Ili kuamua vigezo vyema, uzinduzi ulifanyika na mchanganyiko mbalimbali wa vigezo vya meza na mipangilio:
- nyuzi 10 zilizinduliwa kwa wakati mmoja mara 3 mfululizo (wacha tuite hii kizuizi cha nyuzi).
- Muda wa uendeshaji wa nyuzi zote kwenye block ulikadiriwa na ilikuwa matokeo ya mwisho ya uendeshaji wa block.
- Nyuzi zote zilifanya kazi na meza moja.
- Kabla ya kila mwanzo wa block block, compaction kubwa ilifanyika.
- Kila block ilifanya moja tu ya shughuli zifuatazo:
-Kuweka
-Pata
-Pata+Weka
- Kila block ilifanya marudio 50 ya uendeshaji wake.
- Ukubwa wa block ya rekodi ni byte 100, byte 1000 au 10000 byte (nasibu).
- Vitalu vilizinduliwa kwa nambari tofauti za funguo zilizoombwa (ama ufunguo mmoja au 10).
- Vitalu viliendeshwa chini ya mipangilio tofauti ya jedwali. Vigezo vimebadilishwa:
β BlockCache = imewashwa au imezimwa
β BlockSize = 65 KB au 16 KB
- Sehemu = 1, 5 au 30
β MSLAB = imewezeshwa au imezimwa
Kwa hivyo block inaonekana kama hii:
a. Hali ya MSLAB iliwashwa/kuzimwa.
b. Jedwali liliundwa ambalo vigezo vifuatavyo viliwekwa: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Mfinyazo umewekwa kuwa GZ.
d. nyuzi 10 zilizinduliwa wakati huo huo kufanya 1/10 kuweka/get/get+kuweka shughuli kwenye jedwali hili na rekodi za baiti 100/1000/10000, zikifanya hoja 50 mfululizo (funguo za nasibu).
e. Pointi d ilirudiwa mara tatu.
f. Muda wa uendeshaji wa nyuzi zote ulikadiriwa.
Mchanganyiko wote unaowezekana ulijaribiwa. Inatabirika kuwa kasi itapungua kadiri ukubwa wa rekodi unavyoongezeka, au kwamba kulemaza kache kutasababisha kushuka. Walakini, lengo lilikuwa kuelewa kiwango na umuhimu wa ushawishi wa kila kigezo, kwa hivyo data iliyokusanywa iliingizwa katika ingizo la chaguo la kukokotoa la mstari, ambayo inafanya uwezekano wa kutathmini umuhimu kwa kutumia t-takwimu. Chini ni matokeo ya vitalu vinavyofanya shughuli za Put. Seti kamili ya mchanganyiko 2 * 2 * 3 * 2 * 3 = chaguzi 144 + 72 tk. zingine zilifanyika mara mbili. Kwa hivyo, kuna mbio 216 kwa jumla:
Upimaji ulifanyika kwenye kikundi kidogo kilicho na DataNodes 3 na 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64). Toleo la HBase 1.2.0-cdh5.14.2.
Kasi ya juu ya kuingiza ya sekunde 3.7 ilipatikana na hali ya MSLAB imezimwa, kwenye meza yenye sehemu moja, na BlockCache imewezeshwa, BlockSize = 16, rekodi za byte 100, vipande 10 kwa pakiti.
Kasi ya chini kabisa ya uwekaji wa sekunde 82.8 ilipatikana kwa hali ya MSLAB iliyowezeshwa, kwenye jedwali iliyo na kizigeu kimoja, ikiwa na BlockCache, BlockSize = 16, rekodi za baiti 10000, 1 kila moja.
Sasa hebu tuangalie mfano. Tunaona ubora mzuri wa mfano kulingana na R2, lakini ni wazi kabisa kwamba extrapolation ni kinyume chake hapa. Tabia halisi ya mfumo wakati vigezo vinabadilika haitakuwa mstari; mtindo huu hauhitajiki kwa utabiri, lakini kwa kuelewa kile kilichotokea ndani ya vigezo vilivyotolewa. Kwa mfano, hapa tunaona kutoka kwa kigezo cha Mwanafunzi kwamba vigezo vya BlockSize na BlockCache haijalishi kwa operesheni ya Put (ambayo kwa ujumla inaweza kutabirika):
Lakini ukweli kwamba kuongeza idadi ya partitions husababisha kupungua kwa utendaji ni jambo lisilotarajiwa (tayari tumeona athari chanya ya kuongeza idadi ya partitions na BulkLoad), ingawa inaeleweka. Kwanza, kwa usindikaji, lazima utoe maombi kwa mikoa 30 badala ya moja, na idadi ya data sio kwamba hii itatoa faida. Pili, jumla ya muda wa uendeshaji imedhamiriwa na RS polepole zaidi, na kwa kuwa idadi ya DataNodes ni chini ya idadi ya RS, baadhi ya mikoa ina eneo la sifuri. Kweli, wacha tuangalie tano bora:
Sasa hebu tutathmini matokeo ya kutekeleza Get blocks:
Idadi ya partitions imepoteza umuhimu, ambayo labda inaelezewa na ukweli kwamba data imehifadhiwa vizuri na cache iliyosomwa ni parameter muhimu zaidi (takwimu). Kwa kawaida, kuongeza idadi ya ujumbe katika ombi pia ni muhimu sana kwa utendaji. Alama za juu:
Kweli, mwishowe, wacha tuangalie mfano wa kizuizi ambacho kilifanywa kwanza kupata na kisha kuweka:
Vigezo vyote ni muhimu hapa. Na matokeo ya viongozi:
9. Upimaji wa mzigo
Naam, hatimaye tutazindua mzigo mzuri zaidi au mdogo, lakini daima huvutia zaidi unapokuwa na kitu cha kulinganisha nacho. Kwenye tovuti ya DataStax, msanidi muhimu wa Cassandra, kuna NT kati ya idadi ya hifadhi za NoSQL, ikijumuisha toleo la HBase 0.98.6-1. Upakiaji ulifanyika na nyuzi 40, ukubwa wa data 100 byte, disks za SSD. Matokeo ya kupima shughuli za Soma-Rekebisha-Andika yalionyesha matokeo yafuatayo.
Kwa kadiri ninavyoelewa, usomaji ulifanyika katika vizuizi vya rekodi 100 na kwa nodi 16 za HBase, mtihani wa DataStax ulionyesha utendaji wa shughuli elfu 10 kwa sekunde.
Ni bahati kwamba nguzo yetu pia ina nodes 16, lakini sio "bahati" sana kwamba kila mmoja ana cores 64 (nyuzi), wakati katika mtihani wa DataStax kuna 4 tu. Kwa upande mwingine, wana anatoa za SSD, wakati tuna HDD. au zaidi toleo jipya la HBase na utumiaji wa CPU wakati wa upakiaji haukuongezeka sana (kimwonekano kwa asilimia 5-10). Hata hivyo, hebu tujaribu kuanza kutumia usanidi huu. Mipangilio chaguomsingi ya jedwali, usomaji unafanywa katika safu muhimu kutoka milioni 0 hadi 50 bila mpangilio (yaani, mpya kila wakati). Jedwali lina rekodi milioni 50, zimegawanywa katika sehemu 64. Vifunguo vinaharakishwa kwa kutumia crc32. Mipangilio ya jedwali ni chaguo-msingi, MSLAB imewezeshwa. Inazindua nyuzi 40, kila uzi husoma seti ya funguo 100 bila mpangilio na mara moja huandika baiti 100 zilizotolewa kwenye funguo hizi.
Stand: 16 DataNode na 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64). Toleo la HBase 1.2.0-cdh5.14.2.
Matokeo ya wastani ni karibu na shughuli elfu 40 kwa sekunde, ambayo ni bora zaidi kuliko katika mtihani wa DataStax. Hata hivyo, kwa madhumuni ya majaribio, unaweza kubadilisha hali kidogo. Haiwezekani kwamba kazi yote itafanywa peke kwenye meza moja, na pia kwa funguo za kipekee. Wacha tufikirie kuwa kuna seti fulani ya funguo "moto" ambayo hutoa mzigo kuu. Kwa hiyo, hebu tujaribu kuunda mzigo na rekodi kubwa (10 KB), pia katika makundi ya 100, katika meza 4 tofauti na kupunguza upeo wa funguo zilizoombwa hadi elfu 50. Grafu hapa chini inaonyesha uzinduzi wa nyuzi 40, kila thread inasoma. seti ya funguo 100 na mara moja huandika KB 10 bila mpangilio kwenye funguo hizi nyuma.
Stand: 16 DataNode na 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64). Toleo la HBase 1.2.0-cdh5.14.2.
Wakati wa mzigo, ukandamizaji mkubwa ulizinduliwa mara kadhaa, kama inavyoonyeshwa hapo juu, bila utaratibu huu, utendaji utapungua polepole, hata hivyo, mzigo wa ziada pia hutokea wakati wa utekelezaji. Kushindwa husababishwa na sababu mbalimbali. Wakati mwingine nyuzi zilimaliza kufanya kazi na kulikuwa na pause zikiwashwa tena, wakati mwingine programu za wahusika wengine ziliunda mzigo kwenye nguzo.
Kusoma na kuandika mara moja ni mojawapo ya hali ngumu zaidi za kazi kwa HBase. Ikiwa unafanya maombi madogo tu, kwa mfano ka 100, kuchanganya katika pakiti za vipande 10-50, unaweza kupata mamia ya maelfu ya shughuli kwa pili, na hali ni sawa na maombi ya kusoma tu. Ni muhimu kuzingatia kwamba matokeo ni bora zaidi kuliko yale yaliyopatikana na DataStax, zaidi ya yote kutokana na maombi katika vitalu vya 50 elfu.
Stand: 16 DataNode na 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * nyuzi 64). Toleo la HBase 1.2.0-cdh5.14.2.
10. Hitimisho
Mfumo huu umeundwa kwa urahisi, lakini ushawishi wa idadi kubwa ya vigezo bado haujulikani. Baadhi yao yalijaribiwa, lakini hayakujumuishwa katika seti ya matokeo ya mtihani. Kwa mfano, majaribio ya awali yalionyesha umuhimu mdogo wa kigezo kama vile DATA_BLOCK_ENCODING, ambacho husimba maelezo kwa kutumia thamani kutoka kwa seli jirani, ambazo zinaweza kueleweka kwa data iliyotolewa bila mpangilio. Ikiwa unatumia idadi kubwa ya vitu viwili, faida inaweza kuwa muhimu. Kwa ujumla, tunaweza kusema kwamba HBase inatoa hisia ya hifadhidata kubwa na iliyofikiriwa vizuri, ambayo inaweza kuwa na tija wakati wa kufanya shughuli na data nyingi. Hasa ikiwa inawezekana kutenganisha taratibu za kusoma na kuandika kwa wakati.
Ikiwa kuna kitu kwa maoni yako ambacho hakijafunuliwa vya kutosha, niko tayari kukuambia kwa undani zaidi. Tunakualika kushiriki uzoefu wako au kujadili ikiwa hukubaliani na jambo fulani.
Chanzo: mapenzi.com