Բարի օր Ես Դանիլ Լիպովոյն եմ, Sbertech-ի մեր թիմը սկսեց օգտագործել HBase-ը որպես օպերատիվ տվյալների պահեստ: Այն ուսումնասիրելու ընթացքում կուտակվել է փորձ, որը ցանկացա համակարգել և նկարագրել (հուսով ենք, որ այն օգտակար կլինի շատերին): Ստորև բերված բոլոր փորձերն իրականացվել են HBase 1.2.0-cdh5.14.2 և 2.0.0-cdh6.0.0-beta1 տարբերակներով:
- Ընդհանուր ճարտարապետություն
- Տվյալներ գրել HBASE-ում
- Տվյալների ընթերցում HBASE-ից
- Տվյալների քեշավորում
- Տվյալների խմբաքանակի մշակում MultiGet/MultiPut
- Աղյուսակները տարածաշրջանների բաժանելու ռազմավարություն (բաժանում)
- Սխալների հանդուրժողականություն, կոմպակտացում և տվյալների տեղայնություն
- Կարգավորումներ և կատարում
- Սթրեսի թեստավորում
- Արդյունքները
1. Ընդհանուր ճարտարապետություն
Պահուստային Master-ը լսում է ZooKeeper հանգույցի ակտիվի սրտի բաբախյունը և անհետանալու դեպքում ստանձնում է վարպետի գործառույթները։
2. Գրեք տվյալները HBASE-ում
Նախ, եկեք նայենք ամենապարզ դեպքին` աղյուսակում առանցքային արժեքի օբյեկտ գրելը` օգտագործելով put(rowkey): Հաճախորդը նախ պետք է պարզի, թե որտեղ է գտնվում Root Region Server-ը (RRS), որը պահում է hbase:meta աղյուսակը: Այս տեղեկությունը նա ստանում է ZooKeeper-ից։ Այնուհետև նա մուտք է գործում RRS և կարդում է hbase:meta աղյուսակը, որտեղից քաղում է տեղեկատվություն այն մասին, թե որ RegionServer-ը (RS) է պատասխանատու տվյալ անընդմեջ ստեղնի համար հետաքրքրված աղյուսակում տվյալների պահպանման համար: Հետագա օգտագործման համար մետա աղյուսակը պահվում է հաճախորդի կողմից և հետևաբար հետագա զանգերն ավելի արագ են գնում՝ անմիջապես դեպի RS:
Այնուհետև RS-ը, ստանալով հարցումը, այն առաջին հերթին գրում է WriteAheadLog (WAL), որն անհրաժեշտ է վթարի դեպքում վերականգնման համար։ Այնուհետև տվյալները պահում է MemStore-ում: Սա հիշողության բուֆեր է, որը պարունակում է ստեղների տեսակավորված հավաքածու տվյալ տարածաշրջանի համար: Աղյուսակը կարելի է բաժանել ռեգիոնների (բաժանմունքների), որոնցից յուրաքանչյուրը պարունակում է ստեղների անջատված հավաքածու: Սա թույլ է տալիս տարածաշրջաններ տեղադրել տարբեր սերվերների վրա՝ ավելի բարձր կատարողականության հասնելու համար: Սակայն, չնայած այս հայտարարության ակնհայտությանը, մենք հետագայում կտեսնենք, որ դա ոչ բոլոր դեպքերում է գործում։
MemStore-ում գրառում տեղադրելուց հետո հաճախորդին պատասխան է վերադարձվում, որ գրառումը հաջողությամբ պահպանվել է: Սակայն իրականում այն պահվում է միայն բուֆերում և սկավառակ է հասնում միայն որոշակի ժամանակահատված անցնելուց հետո կամ երբ այն լրացվում է նոր տվյալներով։
«Ջնջել» գործողությունը կատարելիս տվյալները ֆիզիկապես չեն ջնջվում: Նրանք պարզապես նշվում են որպես ջնջված, և ոչնչացումն ինքնին տեղի է ունենում հիմնական կոմպակտ գործառույթը կանչելու պահին, որն ավելի մանրամասն նկարագրված է 7-րդ պարբերությունում:
HFile ֆորմատով ֆայլերը կուտակվում են HDFS-ում և ժամանակ առ ժամանակ գործարկվում է աննշան կոմպակտ գործընթացը, որը պարզապես միաձուլում է փոքր ֆայլերը մեծերի մեջ՝ առանց որևէ բան ջնջելու: Ժամանակի ընթացքում դա վերածվում է խնդրի, որն ի հայտ է գալիս միայն տվյալների ընթերցման ժամանակ (սրան կանդրադառնանք մի փոքր ավելի ուշ):
Բացի վերը նկարագրված բեռնման գործընթացից, կա շատ ավելի արդյունավետ ընթացակարգ, որը, թերեւս, այս տվյալների բազայի ամենաուժեղ կողմն է՝ BulkLoad: Դա կայանում է նրանում, որ մենք ինքնուրույն ձևավորում ենք HFiles և տեղադրում դրանք սկավառակի վրա, ինչը մեզ թույլ է տալիս կատարելապես մասշտաբել և հասնել շատ արժանապատիվ արագությունների: Փաստորեն, այստեղ սահմանափակումը ոչ թե HBase-ն է, այլ սարքավորման հնարավորությունները: Ստորև բերված են բեռնման արդյունքները կլաստերի վրա, որը բաղկացած է 16 RegionServers-ից և 16 NodeManager YARN-ից (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase տարբերակ 1.2.0-cdh5.14.2:
Այստեղ դուք կարող եք տեսնել, որ ավելացնելով աղյուսակի միջնորմների (տարածաշրջանների), ինչպես նաև Spark կատարողների թիվը, մենք ստանում ենք ներբեռնման արագության աճ։ Բացի այդ, արագությունը կախված է ձայնագրման ծավալից: Խոշոր բլոկները տալիս են ՄԲ/վրկ-ի աճ, փոքր բլոկները՝ զետեղված գրառումների քանակի մեկ միավորի ժամանակ, մյուս բոլոր բաները հավասար են:
Կարող եք նաև սկսել բեռնել միաժամանակ երկու աղյուսակների մեջ և ստանալ կրկնակի արագություն: Ստորև կարող եք տեսնել, որ 10 ԿԲ բլոկները միանգամից երկու աղյուսակում գրելը տեղի է ունենում յուրաքանչյուրում մոտ 600 ՄԲ/վ արագությամբ (ընդհանուր 1275 ՄԲ/վրկ), որը համընկնում է մեկ աղյուսակի վրա գրելու արագության հետ՝ 623 ՄԲ/վրկ (տես. Թիվ 11 վերևում)
Բայց 50 ԿԲ գրառումներով երկրորդ վազքը ցույց է տալիս, որ ներբեռնման արագությունը փոքր-ինչ աճում է, ինչը ցույց է տալիս, որ այն մոտենում է սահմանային արժեքներին: Միևնույն ժամանակ, պետք է նկատի ունենալ, որ բուն HBASE-ի վրա գործնականում ոչ մի բեռ չի ստեղծվել, դրանից պահանջվում է միայն նախ տվյալներ տալ hbase:meta-ից, իսկ HFiles-ը շարելուց հետո վերականգնել BlockCache-ի տվյալները և պահպանել MemStore բուֆեր սկավառակի վրա, եթե այն դատարկ չէ:
3. HBASE-ից տվյալների ընթերցում
Եթե ենթադրենք, որ հաճախորդն արդեն ունի ամբողջ տեղեկատվությունը hbase:meta-ից (տես կետ 2), ապա հարցումն ուղղակիորեն գնում է դեպի RS, որտեղ պահվում է պահանջվող բանալին: Նախ, որոնումը կատարվում է MemCache-ում: Անկախ նրանից՝ այնտեղ տվյալներ կան, թե ոչ, որոնումն իրականացվում է նաև BlockCache բուֆերում և անհրաժեշտության դեպքում՝ HFiles-ում։ Եթե ֆայլում տվյալներ են հայտնաբերվել, այն տեղադրվում է BlockCache-ում և հաջորդ հարցման դեպքում կվերադարձվի ավելի արագ: HFile-ում որոնումը համեմատաբար արագ է Bloom ֆիլտրի օգտագործման շնորհիվ, այսինքն. կարդալով փոքր քանակությամբ տվյալներ, այն անմիջապես որոշում է, թե արդյոք այս ֆայլը պարունակում է անհրաժեշտ բանալին, և եթե ոչ, ապա անցնում է հաջորդին:
Ստանալով տվյալներ այս երեք աղբյուրներից՝ RS-ն առաջացնում է պատասխան: Մասնավորապես, այն կարող է միանգամից փոխանցել օբյեկտի մի քանի հայտնաբերված տարբերակներ, եթե հաճախորդը պահանջել է տարբերակում:
4. Տվյալների քեշավորում
MemStore-ի և BlockCache-ի բուֆերները զբաղեցնում են հատկացված on-heap RS հիշողության մինչև 80%-ը (մնացածը վերապահված է RS ծառայության առաջադրանքների համար): Եթե սովորական օգտագործման ռեժիմն այնպիսին է, որ գործընթացները գրում և անմիջապես կարդում են նույն տվյալները, ապա իմաստ ունի նվազեցնել BlockCache-ը և մեծացնել MemStore-ը, քանի որ Երբ տվյալները գրելու համար քեշը չի մտնում ընթերցման համար, BlockCache-ը կօգտագործվի ավելի հազվադեպ: BlockCache բուֆերը բաղկացած է երկու մասից՝ LruBlockCache (միշտ կույտով) և BucketCache (սովորաբար անջատված կամ SSD-ով): BucketCache-ը պետք է օգտագործվի, երբ կան բազմաթիվ ընթերցման հարցումներ, և դրանք չեն տեղավորվում LruBlockCache-ի մեջ, ինչը հանգեցնում է աղբահավաքի ակտիվ աշխատանքին: Միևնույն ժամանակ, դուք չպետք է ակնկալեք կատարողականի արմատական աճ ընթերցված քեշի օգտագործումից, բայց մենք կանդրադառնանք դրան 8-րդ պարբերությունում:
Ամբողջ RS-ի համար կա մեկ BlockCache, և յուրաքանչյուր սեղանի համար կա մեկ MemStore (մեկը յուրաքանչյուր Սյունակի ընտանիքի համար):
Ինչպես Տեսականորեն, երբ գրելիս տվյալները չեն մտնում քեշ և իսկապես, CACHE_DATA_ON_WRITE աղյուսակի համար և «Cache DATA on Write» RS-ի համար սահմանված են false պարամետրերը: Այնուամենայնիվ, գործնականում, եթե մենք տվյալները գրում ենք MemStore-ում, այնուհետև դրանք լցնում ենք սկավառակի վրա (այդպիսով մաքրում ենք), ապա ջնջում ստացված ֆայլը, այնուհետև կատարելով ստանալ հարցումը մենք հաջողությամբ կստանանք տվյալները։ Ավելին, եթե նույնիսկ ամբողջությամբ անջատեք BlockCache-ը և աղյուսակը լցնեք նոր տվյալներով, այնուհետև վերակայեք MemStore-ը սկավառակի վրա, ջնջեք դրանք և խնդրեք դրանք մեկ այլ սեսիայից, այնուամենայնիվ, դրանք ինչ-որ տեղից կվերցվեն: Այսպիսով, HBase-ը պահպանում է ոչ միայն տվյալներ, այլև առեղծվածային առեղծվածներ:
hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
cf:c timestamp=1534440690218, value=try_to_delete_me
«Cache DATA on Read» պարամետրը սահմանվել է false: Եթե ունեք որևէ գաղափար, համեցեք քննարկել այն մեկնաբանություններում:
5. Տվյալների խմբաքանակի մշակում MultiGet/MultiPut
Միայնակ հարցումների մշակումը (Get/Put/Delete) բավականին թանկ գործողություն է, այնպես որ, հնարավորության դեպքում, դուք պետք է դրանք համատեղեք Ցուցակի կամ Ցուցակի մեջ, ինչը թույլ է տալիս զգալի կատարելագործում ստանալ: Սա հատկապես ճիշտ է գրելու գործողության համար, բայց կարդալիս կա հետևյալ որոգայթը. Ստորև բերված գրաֆիկը ցույց է տալիս MemStore-ից 50 գրառում կարդալու ժամանակը: Ընթերցումն իրականացվել է մեկ թելով, իսկ հորիզոնական առանցքը ցույց է տալիս հարցումի ստեղների քանակը։ Այստեղ դուք կարող եք տեսնել, որ մեկ հարցումով հազար ստեղն ավելացնելու դեպքում կատարման ժամանակը նվազում է, այսինքն. արագությունը մեծանում է. Այնուամենայնիվ, երբ MSLAB ռեժիմը լռելյայն միացված է, այս շեմից հետո սկսվում է կատարողականի արմատական անկում, և որքան մեծ է տվյալների քանակը գրառումներում, այնքան երկար է գործելու ժամանակը:
Փորձարկումները կատարվել են վիրտուալ մեքենայի վրա, 8 միջուկ, տարբերակ HBase 2.0.0-cdh6.0.0-beta1:
MSLAB ռեժիմը նախատեսված է կույտի մասնատումը նվազեցնելու համար, որը տեղի է ունենում նոր և հին սերնդի տվյալների միախառնման պատճառով: Որպես լուծում, երբ MSLAB-ը միացված է, տվյալները տեղադրվում են համեմատաբար փոքր բջիջներում (կտորներ) և մշակվում են կտորներով: Արդյունքում, երբ պահանջվող տվյալների փաթեթի ծավալը գերազանցում է հատկացված չափը, կատարումը կտրուկ նվազում է: Մյուս կողմից, այս ռեժիմն անջատելը նույնպես նպատակահարմար չէ, քանի որ տվյալների ինտենսիվ մշակման պահերին դա կհանգեցնի GC-ի պատճառով կանգառների: Լավ լուծում է ակտիվ գրելու դեպքում բջիջի ծավալը մեծացնելը put-ի միջոցով՝ կարդալու հետ միաժամանակ: Հարկ է նշել, որ խնդիրը չի առաջանում, եթե ձայնագրությունից հետո գործարկեք flush հրամանը, որը վերակայում է MemStore-ը սկավառակի վրա, կամ եթե բեռնում եք BulkLoad-ի միջոցով: Ստորև բերված աղյուսակը ցույց է տալիս, որ MemStore-ից ավելի մեծ (և նույն քանակի) տվյալների հարցումները հանգեցնում են դանդաղեցման: Այնուամենայնիվ, մեծացնելով chunksize-ը, մենք վերամշակման ժամանակը վերադարձնում ենք նորմալ:
Ի հավելումն chunksize-ի մեծացմանը, տվյալների բաժանումն ըստ տարածաշրջանի օգնում է, այսինքն. սեղանի բաժանում. Սա հանգեցնում է նրան, որ ավելի քիչ հարցումներ են գալիս յուրաքանչյուր տարածաշրջան, և եթե դրանք տեղավորվում են խցում, պատասխանը մնում է լավ:
6. Աղյուսակները տարածաշրջանների բաժանելու ռազմավարություն (բաժանում)
Քանի որ HBase-ը բանալի-արժեքի պահեստ է, և բաժանումն իրականացվում է բանալիով, չափազանց կարևոր է տվյալների հավասարաչափ բաժանումը բոլոր տարածաշրջաններում: Օրինակ՝ նման աղյուսակը երեք մասի բաժանելը կհանգեցնի նրան, որ տվյալները կբաժանվեն երեք շրջանների.
Դա տեղի է ունենում, որ դա հանգեցնում է կտրուկ դանդաղեցման, եթե հետագայում բեռնված տվյալները նման են, օրինակ, երկար արժեքներին, որոնցից շատերը սկսվում են նույն թվանշանով, օրինակ.
1000001
1000002
...
1100003
Քանի որ ստեղները պահվում են որպես բայթ զանգված, դրանք բոլորը կսկսվեն նույնը և կպատկանեն նույն տարածաշրջանին #1, որտեղ պահվում են ստեղների այս շարքը: Բաժանման մի քանի ռազմավարություններ կան.
HexStringSplit – Բանալին վերածում է տասնվեցական կոդավորված տողի «00000000» => «FFFFFFFF» միջակայքում և ձախ կողմում զրոներով լցնում:
UniformSplit – Բանալին վերածում է բայթային զանգվածի վեցանկյուն կոդավորումով «00» => «FF» միջակայքում և աջ կողմում զրոներով լցոնված:
Բացի այդ, դուք կարող եք նշել ցանկացած տիրույթ կամ ստեղների հավաքածու՝ բաժանման համար և կարգավորել ավտոմատ բաժանումը: Այնուամենայնիվ, ամենապարզ և ամենաարդյունավետ մոտեցումներից մեկը UniformSplit-ն է և հեշ կապակցման օգտագործումը, օրինակ՝ բայթերի ամենակարևոր զույգը՝ բանալին գործարկելուց CRC32 (rowkey) ֆունկցիայի և հենց տողերի միջոցով.
Hash + Rowkey
Այնուհետև բոլոր տվյալները հավասարապես կբաշխվեն տարածաշրջաններում: Ընթերցանության ժամանակ առաջին երկու բայթերը պարզապես անտեսվում են, և սկզբնական բանալին մնում է: RS-ը նաև վերահսկում է տվյալների և ստեղների քանակը տարածաշրջանում և, եթե սահմանները գերազանցում են, այն ավտոմատ կերպով բաժանում է մասերի:
7. Սխալների հանդուրժողականություն և տվյալների տեղայնություն
Քանի որ միայն մեկ տարածաշրջան է պատասխանատու ստեղների յուրաքանչյուր հավաքածուի համար, RS-ի վթարի կամ շահագործումից հանելու հետ կապված խնդիրների լուծումը բոլոր անհրաժեշտ տվյալները HDFS-ում պահելն է: Երբ RS-ն ընկնում է, վարպետը դա հայտնաբերում է ZooKeeper հանգույցի վրա սրտի բաբախյունի բացակայության պատճառով: Այնուհետև այն վերագրում է սպասարկվող տարածաշրջանը մեկ այլ RS-ի և քանի որ HFiles-ը պահվում է բաշխված ֆայլային համակարգում, նոր սեփականատերը կարդում է դրանք և շարունակում է սպասարկել տվյալները: Այնուամենայնիվ, քանի որ տվյալների մի մասը կարող է լինել MemStore-ում և ժամանակ չի ունեցել մտնել HFiles, WAL-ը, որը նույնպես պահվում է HDFS-ում, օգտագործվում է գործողությունների պատմությունը վերականգնելու համար: Փոփոխությունները կիրառելուց հետո RS-ը կարող է պատասխանել հարցումներին, սակայն այդ քայլը հանգեցնում է նրան, որ որոշ տվյալներ և դրանք սպասարկող գործընթացներ հայտնվում են տարբեր հանգույցների վրա, այսինքն. տեղանքը նվազում է.
Խնդրի լուծումը խոշոր խտացումն է. այս ընթացակարգը ֆայլերը տեղափոխում է այն հանգույցները, որոնք պատասխանատու են դրանց համար (որտեղ գտնվում են դրանց շրջանները), ինչի արդյունքում այս ընթացակարգի ընթացքում ցանցի և սկավառակների բեռը կտրուկ մեծանում է: Այնուամենայնիվ, ապագայում տվյալների հասանելիությունը նկատելիորեն արագանում է։ Բացի այդ, major_compaction-ն իրականացնում է բոլոր HFiles-ների միաձուլումը մեկ ֆայլի մեջ տարածաշրջանում, ինչպես նաև մաքրում է տվյալները՝ կախված աղյուսակի կարգավորումներից: Օրինակ, կարող եք նշել օբյեկտի տարբերակների քանակը, որոնք պետք է պահպանվեն կամ ժամկետը, որից հետո օբյեկտը ֆիզիկապես կջնջվի:
Այս պրոցեդուրան կարող է շատ դրական ազդեցություն ունենալ HBase-ի աշխատանքի վրա: Ստորև նկարը ցույց է տալիս, թե ինչպես է կատարողականը վատթարացել տվյալների ակտիվ գրանցման արդյունքում: Այստեղ դուք կարող եք տեսնել, թե ինչպես են 40 շղթաներ գրում մեկ աղյուսակում և 40 թեմա միաժամանակ կարդում տվյալներ: Թեմաներ գրելը առաջացնում է ավելի ու ավելի շատ Hfiles, որոնք կարդում են այլ թելերով: Արդյունքում, ավելի ու ավելի շատ տվյալներ պետք է հեռացվեն հիշողությունից եւ, ի վերջո, GC- ն սկսում է աշխատել, ինչը գործնականում պարալիզացնում է բոլոր աշխատանքները: Հիմնական սեղմման մեկնարկը հանգեցրեց արդյունքում ստացված բեկորների մաքրմանը եւ արտադրողականության վերականգնմանը:
Թեստն իրականացվել է 3 DataNodes-ի և 4 RS-ի վրա (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads): HBase տարբերակ 1.2.0-cdh5.14.2
Հարկ է նշել, որ հիմնական խտացումը գործարկվել է «կենդանի» սեղանի վրա, որի մեջ ակտիվորեն գրվում և ընթերցվում էին տվյալները: Համացանցում հայտարարություն կար, որ դա կարող է հանգեցնել տվյալների ընթերցման ժամանակ սխալ պատասխանի: Ստուգելու համար գործարկվեց մի գործընթաց, որը ստեղծեց նոր տվյալներ և գրեց դրանք աղյուսակում: Որից հետո անմիջապես կարդացի և ստուգեցի, արդյոք ստացված արժեքը համընկնում է գրվածի հետ։ Մինչ այս գործընթացը աշխատում էր, խոշոր խտացումն իրականացվել է մոտ 200 անգամ և ոչ մի ձախողում չի գրանցվել: Թերևս խնդիրը հազվադեպ է ի հայտ գալիս և միայն բարձր ծանրաբեռնվածության ժամանակ, ուստի ավելի անվտանգ է դադարեցնել գրելու և կարդալու գործընթացները, ինչպես պլանավորված է, և մաքրում կատարել՝ կանխելու համար GC-ի նման կրճատումները:
Նաև մեծ սեղմումը չի ազդում MemStore-ի վիճակի վրա. այն սկավառակի վրա դնելու և կոմպակտացնելու համար անհրաժեշտ է օգտագործել flush (connection.getAdmin().flush(TableName.valueOf(tblName))):
8. Կարգավորումներ և կատարում
Ինչպես արդեն նշվեց, HBase-ն իր ամենամեծ հաջողությունը ցույց է տալիս այնտեղ, որտեղ նրան ոչինչ պետք չէ անել՝ BulkLoad-ը կատարելիս։ Այնուամենայնիվ, սա վերաբերում է համակարգերի և մարդկանց մեծամասնությանը: Այնուամենայնիվ, այս գործիքը ավելի հարմար է տվյալների զանգվածային մեծ բլոկներում պահելու համար, մինչդեռ եթե գործընթացը պահանջում է կարդալու և գրելու բազմաթիվ մրցակցային հարցումներ, ապա օգտագործվում են վերը նկարագրված Get and Put հրամանները: Օպտիմալ պարամետրերը որոշելու համար գործարկումներն իրականացվել են աղյուսակի պարամետրերի և պարամետրերի տարբեր համակցություններով.
- Միաժամանակ 10 անգամ անընդմեջ գործարկվել է 3 թել (եկեք սա անվանենք թելերի բլոկ)։
- Բլոկի բոլոր թելերի գործարկման ժամանակը միջինացված էր և բլոկի աշխատանքի վերջնական արդյունքն էր:
- Բոլոր թելերն աշխատում էին նույն աղյուսակով։
- Թելերի բլոկի յուրաքանչյուր մեկնարկից առաջ կատարվել է խոշոր խտացում:
- Յուրաքանչյուր բլոկ կատարել է հետևյալ գործողություններից միայն մեկը.
-Դնել
- Ստացեք
— Ստացեք + դրեք
- Յուրաքանչյուր բլոկ կատարել է իր գործունեության 50 կրկնություն:
- Գրառման բլոկի չափը 100 բայթ է, 1000 բայթ կամ 10000 բայթ (պատահական):
- Բլոկները գործարկվել են տարբեր թվով պահանջվող ստեղներով (կամ մեկ բանալի կամ 10):
- Բլոկները գործարկվել են սեղանի տարբեր պարամետրերով: Պարամետրերը փոխվել են.
— BlockCache = միացված կամ անջատված
— BlockSize = 65 ԿԲ կամ 16 ԿԲ
— միջնորմներ = 1, 5 կամ 30
— MSLAB = միացված կամ անջատված է
Այսպիսով, բլոկն ունի հետևյալ տեսքը.
ա. MSLAB ռեժիմը միացված/անջատվեց:
բ. Ստեղծվել է աղյուսակ, որի համար սահմանվել են հետևյալ պարամետրերը՝ BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30:
գ. Սեղմումը դրվել է GZ:
դ. 10 շղթա գործարկվել է միաժամանակ՝ կատարելով 1/10 put/get/get+put գործողություններ այս աղյուսակում 100/1000/10000 բայթ գրառումներով՝ կատարելով 50 հարցում անընդմեջ (պատահական ստեղներ):
ե. Դ կետը կրկնվել է երեք անգամ։
զ. Բոլոր թելերի շահագործման ժամանակը միջինացված է:
Բոլոր հնարավոր համակցությունները փորձարկվել են։ Կանխատեսելի է, որ արագությունը կնվազի, քանի որ ռեկորդային չափը մեծանում է, կամ քեշավորումն անջատելը կհանգեցնի դանդաղեցման: Այնուամենայնիվ, նպատակն էր հասկանալ յուրաքանչյուր պարամետրի ազդեցության աստիճանն ու նշանակությունը, ուստի հավաքագրված տվյալները սնվում էին գծային ռեգրեսիայի ֆունկցիայի մուտքագրման մեջ, ինչը հնարավորություն է տալիս գնահատել նշանակությունը t-վիճակագրության միջոցով: Ստորև ներկայացված են Put գործողություններ կատարող բլոկների արդյունքները: Համադրությունների ամբողջական հավաքածու 2*2*3*2*3 = 144 տարբերակ + 72 տկ. որոշներն արվել են երկու անգամ: Այսպիսով, ընդհանուր առմամբ կա 216 վազք.
Փորձարկումն իրականացվել է մինի-կլաստերի վրա, որը բաղկացած է 3 DataNodes-ից և 4 RS-ից (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads): HBase տարբերակ 1.2.0-cdh5.14.2.
Տեղադրման ամենաբարձր արագությունը՝ 3.7 վայրկյան, ստացվել է անջատված MSLAB ռեժիմով, մեկ բաժանմունքով սեղանի վրա, BlockCache-ը միացված է, BlockSize = 16, 100 բայթ գրառումներ, 10 հատ մեկ փաթեթում:
Ներմուծման ամենացածր արագությունը՝ 82.8 վրկ, ստացվել է միացված MSLAB ռեժիմով, մեկ միջնորմ ունեցող սեղանի վրա, BlockCache-ը միացված է, BlockSize = 16, 10000 բայթ գրառումներ, 1-ական:
Հիմա եկեք նայենք մոդելին: Մենք տեսնում ենք R2-ի վրա հիմնված մոդելի լավ որակը, բայց միանգամայն պարզ է, որ էքստրապոլացիան այստեղ հակացուցված է։ Համակարգի իրական վարքագիծը, երբ պարամետրերը փոխվում են, գծային չի լինի, այս մոդելն անհրաժեշտ է ոչ թե կանխատեսումների, այլ տվյալ պարամետրերում տեղի ունեցածը հասկանալու համար: Օրինակ, այստեղ Ուսանողի չափանիշից տեսնում ենք, որ BlockSize և BlockCache պարամետրերը նշանակություն չունեն Put գործողության համար (որը ընդհանուր առմամբ բավականին կանխատեսելի է).
Բայց այն, որ բաժանումների քանակի ավելացումը հանգեցնում է կատարողականի նվազմանը, ինչ-որ չափով անսպասելի է (մենք արդեն տեսել ենք BulkLoad-ով բաժանումների քանակի ավելացման դրական ազդեցությունը), թեև հասկանալի է։ Նախ, մշակման համար դուք պետք է 30 տարածաշրջանի հարցումներ գեներացնեք մեկի փոխարեն, և տվյալների ծավալն այնպիսին չէ, որ դա օգուտ բերի: Երկրորդ, ընդհանուր գործառնական ժամանակը որոշվում է ամենադանդաղ RS-ով, և քանի որ DataNodes-ների թիվը պակաս է RS-ների թվից, որոշ շրջաններ ունեն զրոյական տեղայնություն: Դե, եկեք նայենք լավագույն հնգյակին.
Հիմա եկեք գնահատենք Get բլոկների կատարման արդյունքները.
Բաժանմունքների թիվը կորցրել է իր նշանակությունը, ինչը, հավանաբար, բացատրվում է նրանով, որ տվյալները լավ են պահվում, իսկ ընթերցված քեշը ամենակարևոր (վիճակագրորեն) պարամետրն է։ Բնականաբար, խնդրանքի մեջ հաղորդագրությունների քանակի ավելացումը նույնպես շատ օգտակար է կատարման համար: Լավագույն միավորներ.
Դե, վերջապես, եկեք նայենք բլոկի մոդելին, որը սկզբում կատարվեց, ապա դրեց.
Այստեղ բոլոր պարամետրերը նշանակալի են: Իսկ առաջատարների արդյունքները.
9. Բեռի փորձարկում
Դե, վերջապես մենք կսկսենք քիչ թե շատ պատշաճ բեռ, բայց միշտ ավելի հետաքրքիր է, երբ համեմատելու բան ունես: Կասանդրայի հիմնական մշակող DataStax-ի կայքում կա Մի շարք NoSQL պահեստների NT, ներառյալ HBase տարբերակը 0.98.6-1: Բեռնումն իրականացվել է 40 թելերով, տվյալների չափը՝ 100 բայթ, SSD սկավառակներով։ Read-Modify-Write գործողությունների փորձարկման արդյունքը ցույց տվեց հետևյալ արդյունքները.
Որքան հասկանում եմ, ընթերցումն իրականացվել է 100 գրառումների բլոկներում և 16 HBase հանգույցների համար, DataStax թեստը ցույց է տվել վայրկյանում 10 հազար գործողություն:
Բարեբախտաբար, մեր կլաստերը նույնպես ունի 16 հանգույց, բայց այնքան էլ «բախտավոր» չէ, որ յուրաքանչյուրն ունի 64 միջուկ (թելեր), մինչդեռ DataStax թեստում կա ընդամենը 4: Մյուս կողմից, նրանք ունեն SSD կրիչներ, մինչդեռ մենք ունենք HDD: կամ ավելի շատ HBase-ի և CPU-ի օգտագործման նոր տարբերակը ծանրաբեռնվածության ժամանակ գործնականում էապես չի աճել (տեսողականորեն 5-10 տոկոսով): Այնուամենայնիվ, եկեք փորձենք սկսել օգտագործել այս կոնֆիգուրացիան: Աղյուսակի կանխադրված կարգավորումները, ընթերցումը կատարվում է առանցքային միջակայքում՝ 0-ից մինչև 50 միլիոն պատահականորեն (այսինքն՝ ըստ էության ամեն անգամ նոր): Աղյուսակը պարունակում է 50 միլիոն գրառում՝ բաժանված 64 բաժանման։ Ստեղները հաշված են crc32-ի միջոցով: Աղյուսակի կարգավորումները լռելյայն են, MSLAB-ը միացված է: Գործարկելով 40 շղթա, յուրաքանչյուր շարանը կարդում է 100 պատահական ստեղների մի շարք և անմիջապես գրում է ստացված 100 բայթը այդ ստեղների վրա:
Stand՝ 16 DataNode և 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads): HBase տարբերակ 1.2.0-cdh5.14.2.
Միջին արդյունքը ավելի մոտ է վայրկյանում 40 հազար գործողությունների, ինչը զգալիորեն ավելի լավ է, քան DataStax թեստում։ Այնուամենայնիվ, փորձարարական նպատակներով դուք կարող եք մի փոքր փոխել պայմանները: Բավական քիչ հավանական է, որ բոլոր աշխատանքները կատարվեն բացառապես մեկ սեղանի վրա, ինչպես նաև միայն եզակի բանալիների վրա: Ենթադրենք, որ կա ստեղների որոշակի «տաք» հավաքածու, որն առաջացնում է հիմնական բեռը: Հետևաբար, եկեք փորձենք ստեղծել բեռ ավելի մեծ գրառումներով (10 ԿԲ), նաև խմբաքանակներով 100, 4 տարբեր աղյուսակներում և սահմանափակելով պահանջվող ստեղների շրջանակը մինչև 50 հազար: 40 ստեղների հավաքածու և անմիջապես ետ գրում է պատահական 100 ԿԲ այս ստեղների վրա:
Stand՝ 16 DataNode և 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads): HBase տարբերակ 1.2.0-cdh5.14.2.
Բեռնման ընթացքում մի քանի անգամ գործարկվել է հիմնական խտացում, ինչպես ցույց է տրված վերևում, առանց այս ընթացակարգի, կատարումը աստիճանաբար կնվազի, սակայն կատարման ընթացքում առաջանում է նաև լրացուցիչ բեռ: Նվազումները պայմանավորված են տարբեր պատճառներով: Երբեմն թելերն ավարտում էին աշխատանքը, և դրանք վերագործարկվում էին ընդմիջում, երբեմն երրորդ կողմի հավելվածները բեռ էին ստեղծում կլաստերի վրա:
Ընթերցանությունը և անմիջապես գրելը HBase-ի համար ամենադժվար աշխատանքային սցենարներից մեկն է: Եթե դուք կատարում եք միայն փոքր տեղադրման հարցումներ, օրինակ՝ 100 բայթ, դրանք համատեղելով 10-50 հազար կտորների փաթեթների մեջ, կարող եք վայրկյանում հարյուր հազարավոր գործողություններ ստանալ, և իրավիճակը նման է միայն կարդալու հարցումների դեպքում: Հարկ է նշել, որ արդյունքներն արմատապես ավելի լավն են, քան DataStax-ի ստացածները, ամենից շատ՝ 50 հազարանոց բլոկների հարցումների շնորհիվ:
Stand՝ 16 DataNode և 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads): HBase տարբերակ 1.2.0-cdh5.14.2.
10: Եզրակացություններ
Այս համակարգը բավականին ճկուն է կազմաձևված, սակայն մեծ թվով պարամետրերի ազդեցությունը դեռևս անհայտ է: Դրանցից մի քանիսը փորձարկվել են, սակայն չեն ներառվել արդյունքում ստացված թեստային հավաքածուի մեջ։ Օրինակ՝ նախնական փորձերը ցույց տվեցին այնպիսի պարամետրի աննշան նշանակությունը, ինչպիսին է DATA_BLOCK_ENCODING, որը կոդավորում է տեղեկատվությունը՝ օգտագործելով հարևան բջիջների արժեքները, ինչը հասկանալի է պատահականորեն ստեղծվող տվյալների համար: Եթե դուք օգտագործում եք մեծ թվով կրկնօրինակ օբյեկտներ, ապա շահույթը կարող է նշանակալի լինել: Ընդհանուր առմամբ, կարելի է ասել, որ HBase-ը բավականին լուրջ և մտածված տվյալների բազայի տպավորություն է թողնում, որը կարող է բավականին արդյունավետ լինել տվյալների մեծ բլոկներով գործողություններ կատարելիս։ Հատկապես, եթե հնարավոր լինի ժամանակին առանձնացնել ընթերցանության և գրելու գործընթացները։
Եթե ձեր կարծիքով ինչ-որ բան կա, որը բավականաչափ չի բացահայտվում, ես պատրաստ եմ ձեզ ավելի մանրամասն պատմել։ Հրավիրում ենք ձեզ կիսվել ձեր փորձով կամ քննարկել, եթե ինչ-որ բանի հետ համաձայն չեք:
Source: www.habr.com