HBase የመጠቀም ንድፈ ሃሳብ እና ልምምድ

እንደምን አረፈድክ ስሜ ዳኒል ሊፖቮይ እባላለሁ፣ በ Sbertech የሚገኘው ቡድናችን HBaseን ለተግባራዊ መረጃ ማከማቻ መጠቀም ጀመረ። በማጥናት ሂደት ውስጥ, እኔ ስርዓት ለመዘርዘር እና ለመግለጽ የፈለግኩት ልምድ ተከማችቷል (ለብዙዎች ጠቃሚ እንደሚሆን ተስፋ እናደርጋለን). ከዚህ በታች ያሉት ሁሉም ሙከራዎች የተከናወኑት በHBase ስሪቶች 1.2.0-cdh5.14.2 እና 2.0.0-cdh6.0.0-beta1 ነው።

1. አጠቃላይ አርክቴክቸር
2. ለHBASE ውሂብ በመጻፍ ላይ
3. የንባብ ውሂብ ከHBASE
4. የውሂብ መሸጎጫ
5. ባች ዳታ በማስኬድ MultiGet/MultiPut
6. ሰንጠረዦችን ወደ ክልሎች የመከፋፈል ስልት (መከፋፈል)
7. የስህተት መቻቻል፣ መጠቅለል እና የውሂብ አካባቢ
8. ቅንብሮች እና አፈጻጸም
9. የጭንቀት ሙከራ
10. ግኝቶች

1. አጠቃላይ አርክቴክቸር

የመጠባበቂያ ማስተር በ ZooKeeper መስቀለኛ መንገድ ላይ የነቃውን የልብ ምት ያዳምጣል እና ቢጠፋም የጌታውን ተግባራት ይቆጣጠራል።

2. ለ HBASE ውሂብ ይፃፉ

በመጀመሪያ፣ ቀላሉን ጉዳይ እንመልከት - put(rowkey) በመጠቀም የቁልፍ እሴት ነገርን ወደ ጠረጴዛ መፃፍ። ደንበኛው በመጀመሪያ hbase:meta ሠንጠረዥን የሚያከማች የ Root Region Server (RRS) የት እንደሚገኝ ማወቅ አለበት. ይህንን መረጃ ከ ZooKeeper ይቀበላል። ከዚያ በኋላ RRS ን ይደርስና hbase:meta ሠንጠረዥን ያነባል፣ ከየትኛው ሪጅን ሰርቨር (RS) በፍላጎት ሠንጠረዥ ውስጥ ለተጠቀሰው rowkey መረጃ የማከማቸት ኃላፊነት እንዳለበት መረጃ ያወጣል። ለወደፊት ጥቅም, የሜታ ሠንጠረዥ በደንበኛው የተሸጎጠ ነው እና ስለዚህ ተከታይ ጥሪዎች በፍጥነት ወደ አርኤስ.

በመቀጠል ፣ RS ፣ ጥያቄ ከደረሰ በኋላ ፣ በመጀመሪያ ወደ WriteAheadLog (WAL) ይጽፋል ፣ ይህም ብልሽት ቢከሰት ለማገገም አስፈላጊ ነው። ከዚያ ውሂቡን ወደ MemStore ያስቀምጣል። ይህ ለተወሰነ ክልል የተደረደሩ ቁልፎችን የያዘ የማህደረ ትውስታ ቋት ነው። ሠንጠረዥ ወደ ክልሎች (ክፍልፋዮች) ሊከፋፈል ይችላል, እያንዳንዱም የተከፋፈሉ ቁልፎችን ይዟል. ይህ ከፍተኛ አፈፃፀም ለማግኘት ክልሎችን በተለያዩ አገልጋዮች ላይ እንዲያስቀምጡ ያስችልዎታል። ሆኖም ግን, የዚህ መግለጫ ግልጽነት ቢኖረውም, ይህ በሁሉም ጉዳዮች ላይ እንደማይሰራ በኋላ እንመለከታለን.

በMemStore ውስጥ ግቤት ካስገቡ በኋላ፣ ግቤቱ በተሳካ ሁኔታ እንደተቀመጠ ለደንበኛው ምላሽ ይሰጠዋል። ነገር ግን, በእውነቱ, በመጠባበቂያ ውስጥ ብቻ የተከማቸ እና ወደ ዲስክ የሚደርሰው የተወሰነ ጊዜ ካለፈ በኋላ ወይም በአዲስ መረጃ ሲሞላ ብቻ ነው.

የ "ሰርዝ" ክዋኔውን ሲያከናውን ውሂቡ በአካል አይሰረዝም. እነሱ በቀላሉ እንደተሰረዙ ምልክት ተደርጎባቸዋል ፣ እና ጥፋቱ ራሱ በአንቀጽ 7 ላይ በበለጠ ዝርዝር የተገለጸውን ዋናውን የታመቀ ተግባር በሚጠራበት ጊዜ ይከሰታል።

በ HFile ቅርፀት ውስጥ ያሉ ፋይሎች በኤችዲኤፍኤስ ውስጥ ይከማቻሉ እና ከጊዜ ወደ ጊዜ ጥቃቅን ጥቃቅን ሂደቶች ተጀምረዋል, ይህም በቀላሉ ትናንሽ ፋይሎችን ወደ ትላልቅ ፋይሎች ያዋህዳል ምንም ነገር ሳይሰርዝ. ከጊዜ በኋላ, ይህ ውሂብ በሚያነቡበት ጊዜ ብቻ ወደሚታየው ችግር ይቀየራል (ወደዚህ ትንሽ ቆይተን እንመለሳለን).

ከላይ ከተገለፀው የመጫን ሂደት በተጨማሪ በጣም ውጤታማ የሆነ አሰራር አለ, ምናልባትም የዚህ የውሂብ ጎታ ጠንካራ ጎን - BulkLoad. እኛ እራሳችንን ራሳችንን ኤች ፋይሎችን በማቋቋም እና በዲስክ ላይ በማስቀመጥ ላይ ነው ፣ ይህም በትክክል እንድንመዘን እና በጣም ጥሩ ፍጥነቶችን እንድናሳካ ያስችለናል። እንደ እውነቱ ከሆነ, እዚህ ያለው ገደብ HBase አይደለም, ነገር ግን የሃርድዌር ችሎታዎች. ከዚህ በታች 16 RegionServers እና 16 NodeManager YARN (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz * 64 ክሮች)፣ HBase ስሪት 1.2.0-cdh5.14.2 ባካተተ ክላስተር ላይ የማስነሻ ውጤቶች አሉ።

እዚህ በሠንጠረዡ ውስጥ ያሉትን ክፍልፋዮች (ክልሎች) እና እንዲሁም የስፓርክ አስፈፃሚዎችን በመጨመር የማውረድ ፍጥነት መጨመር እንዳለብን ማየት ይችላሉ. እንዲሁም, ፍጥነቱ በመቅጃው መጠን ይወሰናል. ትላልቅ ብሎኮች የሜባ/ሰከንድ ጭማሪ ይሰጣሉ፣ ትንሽ ብሎኮች በአንድ ክፍለ ጊዜ የተካተቱ መዝገቦች ብዛት፣ ሁሉም ሌሎች ነገሮች እኩል ናቸው።

እንዲሁም በአንድ ጊዜ ወደ ሁለት ጠረጴዛዎች መጫን መጀመር እና ፍጥነቱን በእጥፍ ማግኘት ይችላሉ. ከዚህ በታች 10 ኪባ ብሎኮችን ወደ ሁለት ጠረጴዛዎች በአንድ ጊዜ መፃፍ በእያንዳንዱ በ 600 ሜባ / ሰከንድ (በአጠቃላይ 1275 ሜባ / ሰከንድ) ፍጥነት ይከሰታል ፣ ይህም ወደ አንድ ጠረጴዛ 623 ሜባ / ሰከንድ የመፃፍ ፍጥነት ጋር ይገጣጠማል (ይመልከቱ) ከላይ ቁጥር 11)

ነገር ግን የ 50 ኪ.ባ መዛግብት ያለው ሁለተኛው ሩጫ የማውረጃው ፍጥነት በትንሹ እያደገ መሆኑን ያሳያል ይህም ወደ ገደቡ እሴቶቹ እየተቃረበ መሆኑን ያመለክታል. በተመሳሳይ ጊዜ በHBASE በራሱ ላይ ምንም አይነት ጭነት እንዳልተፈጠረ መዘንጋት የለብንም ፣ ከሱ የሚፈለገው በመጀመሪያ ከ hbase:meta መረጃ መስጠት እና HFiles ን ከሸፈነ በኋላ የBlockCache ውሂብን እንደገና ያስጀምሩ እና ያስቀምጡ MemStore ቋት ወደ ዲስክ፣ ባዶ ካልሆነ።

3. የ HBASE መረጃን ማንበብ

ደንበኛው ቀድሞውኑ ሁሉንም መረጃ ከ hbase: meta (ነጥብ 2 ይመልከቱ) እንዳለው ካሰብን, ጥያቄው የሚፈለገው ቁልፍ ወደሚከማችበት RS በቀጥታ ይሄዳል. በመጀመሪያ, ፍለጋው በ MemCache ውስጥ ይከናወናል. እዚያም መረጃ ቢኖርም ባይኖርም ፍለጋው በብሎክካሼ ቋት ውስጥ እና አስፈላጊ ከሆነም በHFiles ውስጥ ይካሄዳል። በፋይሉ ውስጥ ያለው መረጃ ከተገኘ በብሎክካሼ ውስጥ ይቀመጣል እና በሚቀጥለው ጥያቄ በፍጥነት ይመለሳል። በHFile ውስጥ መፈለግ በአንፃራዊነት ፈጣን ነው ለ Bloom ማጣሪያ አጠቃቀም ፣ ማለትም። ትንሽ መጠን ያለው መረጃ ካነበበ በኋላ ይህ ፋይል የሚፈለገውን ቁልፍ እንደያዘ ወዲያውኑ ይወስናል እና ካልሆነ ወደሚቀጥለው ይሄዳል።

ከእነዚህ ሶስት ምንጮች መረጃ ከደረሰን፣ RS ምላሽ ይፈጥራል። በተለይም ደንበኛው ስሪት እንዲሰራ ከጠየቀ ብዙ የተገኙ የአንድ ነገር ስሪቶችን በአንድ ጊዜ ማስተላለፍ ይችላል።

4. የውሂብ መሸጎጫ

MemStore እና BlockCache ቋት እስከ 80% የሚሆነውን የክምር ላይ አርኤስ ማህደረ ትውስታን ይይዛሉ (የተቀረው ለ RS አገልግሎት ተግባራት ነው የተቀመጠው)። የተለመደው የአጠቃቀም ሁኔታ ሂደቶች አንድ አይነት ውሂብ እንዲጽፉ እና ወዲያውኑ እንዲያነቡ ከሆነ, BlockCache ን መቀነስ እና MemStore ን መጨመር ምክንያታዊ ነው, ምክንያቱም መረጃን ለመጻፍ ወደ መሸጎጫው ውስጥ ለንባብ በማይገባበት ጊዜ, BlockCache በተደጋጋሚ ጥቅም ላይ ይውላል. የBlockCache ቋት ሁለት ክፍሎችን ያቀፈ ነው፡- LruBlockCache (ሁልጊዜ ክምር ላይ) እና BucketCache (ብዙውን ጊዜ ከቁልል ውጪ ወይም በኤስኤስዲ)። BucketCache ብዙ የንባብ ጥያቄዎች ሲኖሩ እና ከ LruBlockCache ጋር የማይጣጣሙ ሲሆን ይህም ወደ ቆሻሻ ሰብሳቢው ንቁ ስራ ይመራዋል. በተመሳሳይ ጊዜ የተነበበ መሸጎጫ ከመጠቀም የአፈፃፀም ከፍተኛ ጭማሪ መጠበቅ የለብዎትም ፣ ግን ወደዚህ በአንቀጽ 8 እንመለሳለን ።

ለጠቅላላው አርኤስ አንድ BlockCache አለ፣ እና ለእያንዳንዱ ጠረጴዛ አንድ MemStore አለ (አንድ ለእያንዳንዱ አምድ ቤተሰብ)።

እንዴት ተገል describedል በንድፈ ሀሳብ ፣ በሚጽፉበት ጊዜ ፣ ​​​​ውሂቡ ወደ መሸጎጫው ውስጥ አይገባም እና በእውነቱ ፣ እንደዚህ ያሉ መለኪያዎች ለጠረጴዛው CACHE_DATA_ON_WRITE እና “Cache DATA on Write” ለ RS ወደ ሐሰት ይቀመጣሉ። ነገር ግን፣ በተግባር፣ ውሂብን ወደ 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" መለኪያው ወደ ሐሰት ተቀናብሯል። ማንኛውም ሀሳብ ካለዎት በአስተያየቶቹ ውስጥ ለመወያየት እንኳን ደህና መጡ.

5. ባች ዳታ ማቀናበር MultiGet/MultiPut

ነጠላ ጥያቄዎችን (አግኝ/አስቀምጥ/ሰርዝ) ማካሄድ በጣም ውድ ክዋኔ ነው፣ ስለዚህ ከተቻለ ወደ ዝርዝር ወይም ዝርዝር ውስጥ ማጣመር አለቦት፣ ይህም ጉልህ የሆነ የአፈጻጸም እድገት እንድታገኙ ያስችልዎታል። ይህ በተለይ ለጽሑፍ ሥራ እውነት ነው, ነገር ግን በሚያነቡበት ጊዜ የሚከተለው ወጥመድ አለ. ከታች ያለው ግራፍ ከMemStore 50 መዝገቦችን ለማንበብ ጊዜ ያሳያል። ንባቡ የተከናወነው በአንድ ክር ነው እና አግድም ዘንግ በጥያቄው ውስጥ ያሉትን ቁልፎች ብዛት ያሳያል። እዚህ ማየት ይችላሉ በአንድ ጥያቄ ውስጥ ወደ አንድ ሺህ ቁልፎች ሲጨምሩ, የማስፈጸሚያ ጊዜ ይቀንሳል, ማለትም. ፍጥነት ይጨምራል. ነገር ግን፣ MSLAB ሁነታ በነባሪነት በነቃ፣ ከዚህ ገደብ በኋላ የአፈጻጸም ነቀል ጠብታ ይጀምራል፣ እና በመዝገቡ ውስጥ ያለው የውሂብ መጠን ትልቅ ከሆነ፣ የስራው ጊዜ ይረዝማል።

ሙከራዎች የተከናወኑት በቨርቹዋል ማሽን፣ 8 ኮር፣ እትም HBase 2.0.0-cdh6.0.0-beta1 ላይ ነው።

የ MSLAB ሁነታ በአዲስ እና በአሮጌው ትውልድ ውሂብ መቀላቀል ምክንያት የሚከሰተውን ክምር ስብርባሪ ለመቀነስ የተቀየሰ ነው። እንደ መፍትሄ፣ MSLAB ሲነቃ ውሂቡ በአንፃራዊ ሁኔታ ወደ ትናንሽ ህዋሶች (ክፍሎች) ይቀመጣል እና በክፍል ውስጥ ይከናወናል። በውጤቱም, በተጠየቀው የውሂብ ፓኬት ውስጥ ያለው የድምጽ መጠን ከተመደበው መጠን ሲበልጥ, አፈፃፀሙ በከፍተኛ ሁኔታ ይቀንሳል. በሌላ በኩል፣ ይህን ሁነታን ማጥፋትም አይመከርም፣ ምክንያቱም በጂሲ ምክንያት ከፍተኛ የመረጃ ሂደት በሚካሄድበት ጊዜ ወደ ማቆሚያዎች ስለሚመራ። ጥሩው መፍትሔ በንባብ ጊዜ በተመሳሳይ ጊዜ በማስቀመጥ ንቁ በሆነ ጽሑፍ ውስጥ የሕዋስ መጠን መጨመር ነው። ከቀረጻ በኋላ MemStore ን ወደ ዲስክ የሚያስተካክለውን የፍሳሽ ትዕዛዙን ካስኬዱ ወይም BulkLoad ን ከጫኑ ችግሩ እንደማይከሰት ልብ ሊባል ይገባል። ከዚህ በታች ያለው ሠንጠረዥ የሚያሳየው ከMemStore ለትልቅ (እና ለተመሳሳይ መጠን) ውሂብ መቀዛቀዝ ያስከትላሉ። ነገር ግን, መጠኑን በመጨመር የሂደቱን ጊዜ ወደ መደበኛው እንመለሳለን.

ክፍተቱን ከመጨመር በተጨማሪ መረጃውን በክልል መከፋፈል ይረዳል, ማለትም. የጠረጴዛ ክፍፍል. ይህ ወደ እያንዳንዱ ክልል የሚመጡ ጥቂት ጥያቄዎችን ያስከትላል እና ወደ ሕዋስ ውስጥ የሚገቡ ከሆነ ምላሹ ጥሩ ሆኖ ይቆያል።

6. ሰንጠረዦችን ወደ ክልሎች የመከፋፈል ስልት (መከፋፈል)

HBase የቁልፍ እሴት ማከማቻ ስለሆነ እና ክፍፍሉ የሚከናወነው በቁልፍ በመሆኑ መረጃውን በሁሉም ክልሎች እኩል መከፋፈል እጅግ በጣም አስፈላጊ ነው። ለምሳሌ እንዲህ ዓይነቱን ሠንጠረዥ በሦስት ክፍሎች መከፋፈል ውሂቡ ወደ ሦስት ክልሎች እንዲከፈል ያደርጋል.

በኋላ ላይ የተጫነው መረጃ ለምሳሌ ረጅም እሴቶችን የሚመስል ከሆነ ይህ ወደ ከፍተኛ ፍጥነት መቀዛቀዝ ይመራዋል፣ አብዛኛዎቹ በተመሳሳይ አሃዝ የሚጀምሩት ለምሳሌ፡-

1000001
1000002
...
1100003

ቁልፎቹ እንደ ባይት ድርድር ስለሚቀመጡ፣ ሁሉም ተመሳሳይ ይጀምራሉ እና ይህን የቁልፎች ብዛት የሚያከማችበት ክልል #1 ይሆናሉ። በርካታ የመከፋፈል ስልቶች አሉ፡-

HexStringSplit - ቁልፉን ወደ ሄክሳዴሲማል ኮድ በ "00000000" ክልል = "FFFFFFFF" እና በግራ በኩል ከዜሮዎች ጋር ይቀይረዋል.

UniformSplit - ቁልፉን ወደ ባይት ድርድር ይቀይራል በ "00" ክልል ውስጥ ባለ ሄክሳዴሲማል ኢንኮዲንግ = "ኤፍኤፍ" እና በቀኝ በኩል ከዜሮዎች ጋር።

በተጨማሪም, ለመከፋፈል እና ለማዋቀር ማንኛውንም ክልል ወይም የቁልፍ ስብስቦችን መግለጽ ይችላሉ. ነገር ግን፣ በጣም ቀላል እና ውጤታማ ከሆኑ አቀራረቦች አንዱ ዩኒፎርም ስፕሊት እና የሃሽ ማገናኘት አጠቃቀም ነው፣ ለምሳሌ በጣም ጉልህ የሆኑት ጥንድ ባይት ቁልፉን በCRC32(rowkey) ተግባር እና በረድፍ ቁልፍ በኩል ከማስኬድ።

hash + rowkey

ከዚያ ሁሉም መረጃዎች በክልሎች ላይ እኩል ይሰራጫሉ። በሚያነቡበት ጊዜ የመጀመሪያዎቹ ሁለት ባይቶች በቀላሉ ይጣላሉ እና ዋናው ቁልፍ ይቀራል. RS እንዲሁም በክልሉ ውስጥ ያለውን የውሂብ እና የቁልፍ መጠን ይቆጣጠራል እና ገደቦቹ ካለፉ, በራስ-ሰር ወደ ክፍሎች ይከፋፍሉት.

7. የስህተት መቻቻል እና የውሂብ አካባቢ

ለእያንዳንዱ የቁልፎች ስብስብ አንድ ክልል ብቻ ተጠያቂ ስለሆነ፣ ከRS ብልሽት ወይም ከስራ መጥፋት ጋር ተያይዘው ላሉ ችግሮች መፍትሄው ሁሉንም አስፈላጊ መረጃዎች በኤችዲኤፍኤስ ውስጥ ማከማቸት ነው። አርኤስ ሲወድቅ፣ ጌታው ይህንን የሚያየው በ ZooKeeper node ላይ የልብ ምት ባለመኖሩ ነው። ከዚያ ያገለገለውን ክልል ለሌላ RS ይመድባል እና ኤች ፋይሎቹ በተከፋፈለ የፋይል ስርዓት ውስጥ ስለሚከማቹ አዲሱ ባለቤት ያነባቸውና ውሂቡን ማገልገሉን ይቀጥላል። ነገር ግን፣ አንዳንድ መረጃዎች በMemStore ውስጥ ሊሆኑ ስለሚችሉ እና ወደ HFiles ለመግባት ጊዜ ስላልነበራቸው፣ በኤችዲኤፍኤስ ውስጥ የተከማቸ WAL፣ የክዋኔዎችን ታሪክ ወደነበረበት ለመመለስ ይጠቅማል። ለውጦቹ ከተተገበሩ በኋላ, RS ለጥያቄዎች ምላሽ መስጠት ይችላል, ነገር ግን እንቅስቃሴው አንዳንድ መረጃዎች እና እነሱን የሚያገለግሉ ሂደቶች በተለያዩ አንጓዎች ላይ ወደመሆኑ እውነታ ይመራል, ማለትም. አካባቢ እየቀነሰ ነው።

ለችግሩ መፍትሄው ትልቅ መጨናነቅ ነው - ይህ አሰራር ፋይሎችን ወደ እነሱ ተጠያቂ ወደሆኑት አንጓዎች (ክልሎቻቸው በሚገኙበት ቦታ) ይንቀሳቀሳሉ, በዚህም ምክንያት በዚህ ሂደት ውስጥ በኔትወርክ እና በዲስክ ላይ ያለው ጭነት በከፍተኛ ሁኔታ ይጨምራል. ነገር ግን፣ ወደፊት፣ የውሂብ መዳረሻ በሚያስደንቅ ሁኔታ የተፋጠነ ነው። በተጨማሪም, major_compaction ሁሉንም HFiles በአንድ ክልል ውስጥ ወደ አንድ ፋይል ማዋሃድ ያከናውናል, እና እንዲሁም እንደ ሰንጠረዥ መቼቶች መረጃን ያጸዳል. ለምሳሌ፣ መቆየት ያለበት የነገሩን ስሪቶች ብዛት ወይም እቃው በአካል የተሰረዘበትን የህይወት ዘመን መግለጽ ትችላለህ።

ይህ አሰራር በ HBase አሠራር ላይ በጣም አዎንታዊ ተጽእኖ ይኖረዋል. ከታች ያለው ምስል በንቁ የውሂብ ቀረጻ ምክንያት አፈጻጸሙ እንዴት እንደቀነሰ ያሳያል። እዚህ 40 ክሮች ወደ አንድ ጠረጴዛ እንዴት እንደጻፉ እና 40 ክሮች በአንድ ጊዜ ውሂብ እንደሚያነብ ማየት ይችላሉ. የአጻጻፍ ክሮች የበለጠ እና ተጨማሪ HFiles ያመነጫሉ, በሌሎች ክሮች የሚነበቡ. በውጤቱም, ብዙ እና ተጨማሪ መረጃዎች ከማህደረ ትውስታ መወገድ አለባቸው እና በመጨረሻም ጂሲ መስራት ይጀምራል, ይህም ሁሉንም ስራዎች በተጨባጭ ሽባ ያደርገዋል. የዋና ማጠናቀቂያ ሥራ መጀመር የተፈጠረውን ፍርስራሾች በማጽዳት ምርታማነትን ወደነበረበት እንዲመለስ አድርጓል።

ፈተናው የተካሄደው በ3 DataNodes እና 4 RS (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz* 64 ክሮች) ነው። HBase ስሪት 1.2.0-cdh5.14.2

በ"ቀጥታ" ጠረጴዛ ላይ ዋና ማጠናከሪያ መጀመሩን ልብ ሊባል የሚገባው መረጃ በንቃት የተፃፈበት እና የተነበበበት ነው። መረጃን በሚያነቡበት ጊዜ ይህ ወደ የተሳሳተ ምላሽ ሊመራ እንደሚችል በመስመር ላይ አንድ መግለጫ ነበር። ለማጣራት አዲስ መረጃ የሚያመነጭ እና ወደ ጠረጴዛ የጻፈው ሂደት ተጀመረ። ከዚያ በኋላ ወዲያውኑ አነበብኩ እና የተገኘው እሴት ከተጻፈው ጋር መገናኘቱን አጣራሁ። ይህ ሂደት በሂደት ላይ እያለ፣ ዋና ኮምፓክት 200 ጊዜ ያህል ተካሂዷል እና አንድም ውድቀት አልተመዘገበም። ምናልባት ችግሩ እምብዛም አይታይም እና በከፍተኛ ጭነት ጊዜ ብቻ ነው, ስለዚህ እንደታቀደው የአጻጻፍ እና የማንበብ ሂደቶችን ማቆም እና እንደነዚህ ያሉ የጂሲ መዘዞችን ለመከላከል ጽዳት ማካሄድ የበለጠ አስተማማኝ ነው.

እንዲሁም፣ Major compaction የ MemStore ሁኔታን አይጎዳውም ፣ ወደ ዲስክ ለማፍሰስ እና እሱን ለመጠቅለል ፍሎሽ (connection.getAdmin() .flush(TableName.valueOf(tblName))) መጠቀም ያስፈልግዎታል።

8. ቅንብሮች እና አፈጻጸም

ቀደም ሲል እንደተገለፀው HBase BulkLoadን በሚሰራበት ጊዜ ምንም ነገር ማድረግ በማይፈልግበት ቦታ ትልቁን ስኬት ያሳያል. ሆኖም፣ ይህ ለአብዛኞቹ ስርዓቶች እና ሰዎች ተፈጻሚ ይሆናል። ነገር ግን ይህ መሳሪያ በትላልቅ ብሎኮች ውስጥ መረጃን በጅምላ ለማከማቸት የበለጠ አመቺ ሲሆን ሂደቱ ብዙ ተወዳዳሪ የማንበብ እና የመፃፍ ጥያቄዎችን የሚፈልግ ከሆነ ከላይ የተገለጹት የ Get and Put ትዕዛዞች ስራ ላይ ይውላሉ። ምርጥ መለኪያዎችን ለመወሰን ጅምር ከተለያዩ የሰንጠረዥ መለኪያዎች እና ቅንብሮች ጋር ተካሂዷል።

• 10 ክሮች በተከታታይ 3 ጊዜ በአንድ ጊዜ ተጀምረዋል (ይህን የክር እንበለው)።
• በብሎክ ውስጥ ያሉ ሁሉም ክሮች የሚሠሩበት ጊዜ አማካይ እና የብሎክ አሠራር የመጨረሻ ውጤት ነበር።
• ሁሉም ክሮች ከተመሳሳይ ጠረጴዛ ጋር ሠርተዋል.
• ከእያንዳንዱ የክር ማገጃ ጅምር በፊት አንድ ትልቅ ኮምፓክት ተካሂዷል።
• እያንዳንዱ እገዳ ከሚከተሉት ተግባራት ውስጥ አንዱን ብቻ ፈጽሟል።

- አስቀምጠው
- አግኝ
— አግኝ+አስቀምጥ

• እያንዳንዱ ብሎክ 50 ድግግሞሾችን አከናውኗል።
• የማገጃው መጠን 100 ባይት፣ 1000 ባይት ወይም 10000 ባይት (በዘፈቀደ) ነው።
• ብሎኮች በተለያዩ የተጠየቁ ቁልፎች (አንድ ቁልፍ ወይም 10) ተጀምረዋል።
• እገዳዎቹ በተለያዩ የጠረጴዛ መቼቶች ውስጥ ተካሂደዋል. መለኪያዎች ተለውጠዋል፡-

- BlockCache = በርቷል ወይም ጠፍቷል
- BlockSize = 65 KB ወይም 16 KB
- ክፍልፋዮች = 1, 5 ወይም 30
- MSLAB = ነቅቷል ወይም ተሰናክሏል።

ስለዚህ እገዳው ይህንን ይመስላል።

ሀ. MSLAB ሁነታ በርቷል/ ጠፍቷል።
ለ. የሚከተሉት መመዘኛዎች የተቀመጡበት ሠንጠረዥ ተፈጠረ፡ BlockCache = true/ none, BlockSize = 65/16 Kb, Partition = 1/5/30.
ሐ. መጭመቂያ ወደ GZ ተቀናብሯል።
መ. 10 ክሮች በአንድ ጊዜ ተጀምረዋል 1/10 put/get/get+ put Operations በዚህ ሠንጠረዥ ውስጥ ከ100/1000/10000 ባይት መዛግብት ጋር፣ 50 መጠይቆችን በተከታታይ (የዘፈቀደ ቁልፎች) አከናውነዋል።
ሠ. ነጥብ d ሦስት ጊዜ ተደግሟል.
ረ. የሁሉም ክሮች የስራ ጊዜ አማካይ ነበር።

ሁሉም ሊሆኑ የሚችሉ ጥምረት ተፈትኗል። የመዝገቡ መጠን ሲጨምር ፍጥነቱ እንደሚቀንስ ወይም መሸጎጫውን ማሰናከል መቀዛቀዝ ያስከትላል። ሆኖም ግቡ የእያንዳንዱን ግቤት ተፅእኖ ደረጃ እና አስፈላጊነት ለመረዳት ነበር ፣ ስለሆነም የተሰበሰበው መረጃ ወደ መስመራዊ ሪግሬሽን ተግባር ግብዓት ውስጥ ገብቷል ፣ ይህም በቲ-ስታቲስቲክስ በመጠቀም ትርጉሙን ለመገምገም ያስችላል። ከታች ያሉት ብሎኮች የ Put ስራዎችን የሚያከናውኑ ውጤቶች ናቸው. ሙሉ ስብስብ 2 * 2 * 3 * 2 * 3 = 144 አማራጮች + 72 tk. አንዳንዶቹ ሁለት ጊዜ ተደርገዋል. ስለዚህ በጠቅላላው 216 ሩጫዎች አሉ-

ሙከራ የተካሄደው 3 DataNodes እና 4 RS (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz * 64 ክሮች) ባቀፈ አነስተኛ ክላስተር ላይ ነው። 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 ነው, እና የዳታ ኖዶች ቁጥር ከ RS ቁጥር ያነሰ ስለሆነ, አንዳንድ ክልሎች ዜሮ አካባቢ አላቸው. ደህና፣ አምስቱን ዋና ዋናዎቹን እንመልከት፡-

አሁን Get ብሎኮችን የማስፈጸም ውጤቶችን እንገምግም፡-

የክፍሎች ብዛት ጠቀሜታ አጥቷል, ይህም ምናልባት መረጃው በደንብ መሸጎጡ እና የተነበበው መሸጎጫ በጣም ጠቃሚ (በስታቲስቲክስ) መለኪያ ነው. በተፈጥሮ፣ በጥያቄ ውስጥ ያሉ የመልእክቶችን ብዛት መጨመር ለአፈጻጸም በጣም ጠቃሚ ነው። ከፍተኛ ውጤቶች፡

ደህና ፣ በመጨረሻ ፣ መጀመሪያ ያከናወነውን የማገጃውን ሞዴል እንይ እና ከዚያ አስቀምጥ

ሁሉም መለኪያዎች እዚህ ጉልህ ናቸው. የመሪዎቹም ውጤት፡-

9. የመጫን ሙከራ

ደህና፣ በመጨረሻም ብዙ ወይም ያነሰ ጨዋ የሆነ ጭነት እንጀምራለን፣ ነገር ግን የሚያነጻጽረው ነገር ሲኖርዎት ሁልጊዜ የበለጠ ትኩረት የሚስብ ነው። የካሳንድራ ቁልፍ ገንቢ በሆነው በዳታስታክስ ድህረ ገጽ ላይ አለ። ውጤቶቹ HBase ስሪት 0.98.6-1ን ጨምሮ የበርካታ NoSQL ማከማቻዎች NT። መጫን በ 40 ክሮች, የውሂብ መጠን 100 ባይት, ኤስኤስዲ ዲስኮች ተከናውኗል. የንባብ-ማስተካከል-ይፃፉ ስራዎችን የመሞከር ውጤት የሚከተሉትን ውጤቶች አሳይቷል.

እኔ እስከገባኝ ድረስ ንባብ በብሎኮች 100 መዝገቦች እና ለ 16 HBase nodes ተካሂዶ ነበር ፣ የ DataStax ሙከራ በሰከንድ 10 ሺህ ኦፕሬሽኖች አፈፃፀም አሳይቷል።

የእኛ ክላስተር 16 አንጓዎች መኖራቸው ዕድለኛ ነው ፣ ግን እያንዳንዳቸው 64 ኮር (ክር) ያላቸው መሆናቸው በጣም “እድለኛ” አይደለም ፣ በዳታስታክስ ሙከራ ውስጥ 4 ብቻ ናቸው ። በሌላ በኩል ፣ ኤስኤስዲ ድራይቭ አላቸው ፣ እኛ HDDs እያለን ወይም ከዚያ በላይ አዲሱ የHBase እና የሲፒዩ አጠቃቀም በጭነት ጊዜ በተግባር በከፍተኛ ደረጃ አልጨመረም (በእይታ ከ5-10 በመቶ)። ሆኖም፣ ይህን ውቅር መጠቀም ለመጀመር እንሞክር። ነባሪ የሰንጠረዥ ቅንጅቶች፣ ንባብ በቁልፍ ክልል ውስጥ ከ0 እስከ 50 ሚልዮን በዘፈቀደ ይከናወናሉ (ማለትም፣ ሁልጊዜ አዲስ ነው)። ሠንጠረዡ በ 50 ክፍሎች የተከፈለ 64 ሚሊዮን መዝገቦችን ይዟል. ቁልፎቹ crc32 በመጠቀም የተጠለፉ ናቸው። የሰንጠረዥ ቅንጅቶች ነባሪ ናቸው፣ MSLAB ነቅቷል። 40 ክሮች በማስጀመር እያንዳንዱ ክር 100 የዘፈቀደ ቁልፎችን ስብስብ ያነባል እና ወዲያውኑ የመነጨውን 100 ባይት ወደ እነዚህ ቁልፎች ይጽፋል።

ቁም፡ 16 ዳታ ኖድ እና 16 አርኤስ (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz * 64 ክሮች)። HBase ስሪት 1.2.0-cdh5.14.2.

አማካይ ውጤቱ በሴኮንድ ወደ 40 ሺህ ኦፕሬሽኖች ይጠጋል, ይህም ከ DataStax ፈተና በጣም የተሻለ ነው. ነገር ግን, ለሙከራ ዓላማዎች, ሁኔታዎችን በትንሹ መቀየር ይችላሉ. ሁሉም ስራዎች በአንድ ጠረጴዛ ላይ ብቻ እና እንዲሁም በልዩ ቁልፎች ላይ ብቻ መከናወን የማይቻል ነው. ዋናውን ጭነት የሚያመነጨው የተወሰነ "ሙቅ" የቁልፍ ስብስብ እንዳለ እናስብ. ስለዚህ ፣ በትላልቅ መዝገቦች (10 ኪ.ቢ) ፣ እንዲሁም በ 100 ባች ፣ በ 4 የተለያዩ ጠረጴዛዎች እና የተጠየቁትን ቁልፎች እስከ 50 ሺህ በመገደብ ጭነት ለመፍጠር እንሞክር ። ከዚህ በታች ያለው ግራፍ የ 40 ክሮች መጀመሩን ያሳያል ፣ እያንዳንዱ ክር ይነበባል ። የ100 ቁልፎች ስብስብ እና ወዲያውኑ በዘፈቀደ 10 ኪባ በእነዚህ ቁልፎች ላይ ይጽፋል።

ቁም፡ 16 ዳታ ኖድ እና 16 አርኤስ (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz * 64 ክሮች)። HBase ስሪት 1.2.0-cdh5.14.2.

በጭነቱ ወቅት, ከላይ እንደሚታየው ዋናው መጨናነቅ ብዙ ጊዜ ተጀምሯል, ያለዚህ አሰራር, አፈፃፀሙ ቀስ በቀስ እየቀነሰ ይሄዳል, ነገር ግን በአፈፃፀም ወቅት ተጨማሪ ጭነትም ይነሳል. ድክመቶች በተለያዩ ምክንያቶች ይከሰታሉ. አንዳንድ ጊዜ ክሮቹ ሥራቸውን ያጠናቀቁ እና እንደገና ሲጀምሩ ለአፍታ ቆሟል፣ አንዳንድ ጊዜ የሶስተኛ ወገን መተግበሪያዎች በክላስተር ላይ ጭነት ፈጠሩ።

ማንበብ እና ወዲያውኑ መጻፍ ለHBase በጣም አስቸጋሪ ከሆኑ የስራ ሁኔታዎች ውስጥ አንዱ ነው። ትንሽ ጥያቄዎችን ብቻ ካቀረብክ ለምሳሌ 100 ባይት ከ10-50 ሺሕ ፓኬጆችን በማዋሃድ በሰከንድ በመቶ ሺዎች የሚቆጠሩ ኦፕሬሽኖችን ማግኘት ትችላለህ፣ እና ሁኔታው ​​ከተነበብ-ብቻ ጥያቄዎች ጋር ተመሳሳይ ነው። ውጤቶቹ በ DataStax ከተገኙት እጅግ በጣም የተሻሉ መሆናቸውን ልብ ሊባል የሚገባው ነው ፣ ከሁሉም በላይ በ 50 ሺህ ብሎኮች ውስጥ ባሉ ጥያቄዎች ምክንያት።

ቁም፡ 16 ዳታ ኖድ እና 16 አርኤስ (ሲፒዩ Xeon E5-2680 v4 @ 2.40GHz * 64 ክሮች)። HBase ስሪት 1.2.0-cdh5.14.2.

10. መደምደሚያ

ይህ ስርዓት በተለዋዋጭ ሁኔታ የተዋቀረ ነው ፣ ግን የብዙ ልኬቶች ተጽዕኖ አሁንም አልታወቀም። አንዳንዶቹ ተፈትነዋል፣ ነገር ግን በውጤቱ የፈተና ስብስብ ውስጥ አልተካተቱም። ለምሳሌ፣የመጀመሪያ ሙከራዎች እንደ DATA_BLOCK_ENCODING ያለ ትርጉም የጎደለው ጠቀሜታ አሳይተዋል፣ይህም መረጃን ከአጎራባች ህዋሶች በመጠቀም ኮድ ይሰጣል፣ይህም በዘፈቀደ ለሚመነጨው ውሂብ ነው። ብዙ የተባዙ ነገሮችን ከተጠቀሙ ትርፉ ጠቃሚ ሊሆን ይችላል። በአጠቃላይ ፣ HBase በትክክል ከባድ እና በደንብ የታሰበ የውሂብ ጎታ ስሜትን ይሰጣል ፣ ይህም በትላልቅ የውሂብ ብሎኮች ስራዎችን ሲያከናውን በጣም ውጤታማ ሊሆን ይችላል። በተለይም የማንበብ እና የመጻፍ ሂደቶችን በጊዜ መለየት ከተቻለ.

በእርስዎ አስተያየት በበቂ ሁኔታ ያልተገለጸ ነገር ካለ፣ የበለጠ በዝርዝር ልነግርዎ ዝግጁ ነኝ። በአንድ ነገር ካልተስማሙ ልምድዎን እንዲያካፍሉ ወይም እንዲወያዩ እንጋብዝዎታለን።

ምንጭ: hab.com