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. പൊതു വാസ്തുവിദ്യ

സൂകീപ്പർ നോഡിലെ സജീവമായ ഒരാളുടെ ഹൃദയമിടിപ്പ് ബാക്കപ്പ് മാസ്റ്റർ ശ്രദ്ധിക്കുന്നു, അപ്രത്യക്ഷമായാൽ, മാസ്റ്ററുടെ പ്രവർത്തനങ്ങൾ ഏറ്റെടുക്കുന്നു.

2. HBASE-ലേക്ക് ഡാറ്റ എഴുതുക

ആദ്യം, നമുക്ക് ഏറ്റവും ലളിതമായ കേസ് നോക്കാം - put(rowkey) ഉപയോഗിച്ച് ഒരു ടേബിളിലേക്ക് ഒരു കീ-മൂല്യം ഒബ്ജക്റ്റ് എഴുതുക. hbase:meta table സംഭരിക്കുന്ന റൂട്ട് റീജിയൻ സെർവർ (RRS) എവിടെയാണെന്ന് ക്ലയൻ്റ് ആദ്യം കണ്ടെത്തണം. ZooKeeper-ൽ നിന്നാണ് അയാൾക്ക് ഈ വിവരം ലഭിക്കുന്നത്. അതിനുശേഷം അത് RRS ആക്‌സസ് ചെയ്യുകയും hbase:meta ടേബിൾ വായിക്കുകയും ചെയ്യുന്നു, അതിൽ നിന്ന് താൽപ്പര്യമുള്ള പട്ടികയിൽ തന്നിരിക്കുന്ന റൗക്കിയുടെ ഡാറ്റ സംഭരിക്കുന്നതിന് ഏത് RegionServer (RS) ഉത്തരവാദിയാണ് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ എക്‌സ്‌ട്രാക്റ്റുചെയ്യുന്നു. ഭാവിയിലെ ഉപയോഗത്തിനായി, മെറ്റാ ടേബിൾ ക്ലയൻ്റ് കാഷെ ചെയ്യുന്നു, അതിനാൽ തുടർന്നുള്ള കോളുകൾ വേഗത്തിൽ RS-ലേക്ക് പോകുന്നു.

അടുത്തതായി, RS, ഒരു അഭ്യർത്ഥന ലഭിച്ചു, ആദ്യം അത് WriteAheadLog (WAL) ലേക്ക് എഴുതുന്നു, ഇത് ഒരു ക്രാഷ് സംഭവിച്ചാൽ വീണ്ടെടുക്കുന്നതിന് ആവശ്യമാണ്. തുടർന്ന് ഡാറ്റ മെംസ്റ്റോറിൽ സംരക്ഷിക്കുന്നു. ഇത് മെമ്മറിയിലെ ഒരു ബഫറാണ്, അതിൽ ഒരു നിശ്ചിത പ്രദേശത്തിനായി അടുക്കിയ ഒരു കൂട്ടം കീകൾ അടങ്ങിയിരിക്കുന്നു. ഒരു ടേബിളിനെ റീജിയണുകളായി (പാർട്ടീഷനുകൾ) വിഭജിക്കാം, അവയിൽ ഓരോന്നിനും ഒരു വിഭജിത കീകൾ അടങ്ങിയിരിക്കുന്നു. ഉയർന്ന പ്രകടനം നേടുന്നതിന് വിവിധ സെർവറുകളിൽ പ്രദേശങ്ങൾ സ്ഥാപിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, ഈ പ്രസ്താവനയുടെ വ്യക്തത ഉണ്ടായിരുന്നിട്ടും, എല്ലാ സാഹചര്യങ്ങളിലും ഇത് പ്രവർത്തിക്കില്ലെന്ന് നമുക്ക് പിന്നീട് കാണാം.

MemStore-ൽ ഒരു എൻട്രി നൽകിയ ശേഷം, എൻട്രി വിജയകരമായി സംരക്ഷിച്ചു എന്ന ഒരു പ്രതികരണം ക്ലയൻ്റിന് തിരികെ നൽകും. എന്നിരുന്നാലും, വാസ്തവത്തിൽ ഇത് ഒരു ബഫറിൽ മാത്രമേ സംഭരിക്കപ്പെടുകയുള്ളൂ, ഒരു നിശ്ചിത കാലയളവ് കഴിഞ്ഞതിന് ശേഷമോ അല്ലെങ്കിൽ അത് പുതിയ ഡാറ്റ കൊണ്ട് നിറയ്ക്കുമ്പോഴോ മാത്രമേ ഡിസ്കിൽ എത്തുകയുള്ളൂ.

"ഇല്ലാതാക്കുക" പ്രവർത്തനം നടത്തുമ്പോൾ, ഡാറ്റ ഭൗതികമായി ഇല്ലാതാക്കില്ല. അവ ഇല്ലാതാക്കിയതായി അടയാളപ്പെടുത്തിയിരിക്കുന്നു, പ്രധാന കോംപാക്റ്റ് ഫംഗ്ഷനെ വിളിക്കുന്ന നിമിഷത്തിലാണ് നാശം സംഭവിക്കുന്നത്, അത് ഖണ്ഡിക 7 ൽ കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു.

HFile ഫോർമാറ്റിലുള്ള ഫയലുകൾ HDFS-ൽ ശേഖരിക്കപ്പെടുകയും കാലാകാലങ്ങളിൽ ചെറിയ കോംപാക്റ്റ് പ്രോസസ്സ് ആരംഭിക്കുകയും ചെയ്യുന്നു, ഇത് ചെറിയ ഫയലുകളെ ഒന്നും ഇല്ലാതാക്കാതെ വലിയവയിലേക്ക് ലയിപ്പിക്കുന്നു. കാലക്രമേണ, ഇത് ഡാറ്റ വായിക്കുമ്പോൾ മാത്രം ദൃശ്യമാകുന്ന ഒരു പ്രശ്നമായി മാറുന്നു (ഞങ്ങൾ കുറച്ച് കഴിഞ്ഞ് ഇതിലേക്ക് മടങ്ങാം).

മുകളിൽ വിവരിച്ച ലോഡിംഗ് പ്രക്രിയയ്ക്ക് പുറമേ, കൂടുതൽ ഫലപ്രദമായ ഒരു നടപടിക്രമമുണ്ട്, ഇത് ഒരുപക്ഷേ ഈ ഡാറ്റാബേസിൻ്റെ ഏറ്റവും ശക്തമായ വശമാണ് - ബൾക്ക്ലോഡ്. ഞങ്ങൾ സ്വതന്ത്രമായി HFiles രൂപീകരിക്കുകയും അവ ഡിസ്കിൽ ഇടുകയും ചെയ്യുന്നു എന്ന വസ്തുതയിലാണ് ഇത് സ്ഥിതിചെയ്യുന്നത്, ഇത് തികച്ചും സ്കെയിൽ ചെയ്യാനും വളരെ മാന്യമായ വേഗത കൈവരിക്കാനും ഞങ്ങളെ അനുവദിക്കുന്നു. വാസ്തവത്തിൽ, ഇവിടെ പരിമിതി HBase അല്ല, ഹാർഡ്‌വെയറിൻ്റെ കഴിവുകളാണ്. 16 RegionServers ഉം 16 NodeManager YARN ഉം (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ത്രെഡുകൾ), HBase പതിപ്പ് 1.2.0-cdh5.14.2 അടങ്ങുന്ന ഒരു ക്ലസ്റ്ററിലെ ബൂട്ട് ഫലങ്ങൾ ചുവടെയുണ്ട്.

ടേബിളിലെ പാർട്ടീഷനുകളുടെ (പ്രദേശങ്ങൾ) എണ്ണം വർദ്ധിപ്പിക്കുന്നതിലൂടെയും സ്പാർക്ക് എക്സിക്യൂട്ടർമാർ വഴിയും നമുക്ക് ഡൗൺലോഡ് വേഗതയിൽ വർദ്ധനവ് ലഭിക്കുന്നത് ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും. കൂടാതെ, വേഗത റെക്കോർഡിംഗ് വോളിയത്തെ ആശ്രയിച്ചിരിക്കുന്നു. വലിയ ബ്ലോക്കുകൾ MB/sec-ൽ വർദ്ധനവ് നൽകുന്നു, ഓരോ യൂണിറ്റ് സമയത്തിനും ചേർത്ത റെക്കോർഡുകളുടെ എണ്ണത്തിൽ ചെറിയ ബ്ലോക്കുകൾ, മറ്റെല്ലാ കാര്യങ്ങളും തുല്യമാണ്.

നിങ്ങൾക്ക് ഒരേ സമയം രണ്ട് ടേബിളുകളിലേക്ക് ലോഡ് ചെയ്യാൻ തുടങ്ങുകയും ഇരട്ടി വേഗത നേടുകയും ചെയ്യാം. രണ്ട് ടേബിളുകളിലേക്ക് 10 KB ബ്ലോക്കുകൾ ഒരേസമയം എഴുതുന്നത് ഓരോന്നിലും ഏകദേശം 600 MB/sec വേഗതയിൽ സംഭവിക്കുന്നത് (ആകെ 1275 MB/sec), ഇത് ഒരു ടേബിളിലേക്ക് 623 MB/സെക്കൻ്റിലേക്ക് എഴുതുന്ന വേഗതയുമായി പൊരുത്തപ്പെടുന്നതായി നിങ്ങൾക്ക് ചുവടെ കാണാൻ കഴിയും (കാണുക മുകളിൽ നമ്പർ 11)

എന്നാൽ 50 KB യുടെ റെക്കോർഡുകളുള്ള രണ്ടാമത്തെ ഓട്ടം, ഡൗൺലോഡ് വേഗത ചെറുതായി വളരുന്നതായി കാണിക്കുന്നു, ഇത് പരിധി മൂല്യങ്ങളെ സമീപിക്കുന്നുവെന്ന് സൂചിപ്പിക്കുന്നു. അതേസമയം, HBASE-ൽ തന്നെ പ്രായോഗികമായി ഒരു ലോഡും സൃഷ്‌ടിച്ചിട്ടില്ലെന്ന് നിങ്ങൾ ഓർമ്മിക്കേണ്ടതുണ്ട്, ഇതിന് ആദ്യം വേണ്ടത് hbase:meta-ൽ നിന്ന് ഡാറ്റ നൽകുക, കൂടാതെ HFiles ലൈനിംഗ് ചെയ്‌ത ശേഷം, BlockCache ഡാറ്റ പുനഃസജ്ജമാക്കി സംരക്ഷിക്കുക മെംസ്റ്റോർ ഡിസ്കിലേക്ക് ബഫർ, അത് ശൂന്യമല്ലെങ്കിൽ.

3. HBASE-ൽ നിന്നുള്ള ഡാറ്റ വായിക്കുന്നു

hbase:meta (പോയിൻ്റ് 2 കാണുക) എന്നതിൽ നിന്നുള്ള എല്ലാ വിവരങ്ങളും ക്ലയൻ്റിന് ഇതിനകം ഉണ്ടെന്ന് ഞങ്ങൾ അനുമാനിക്കുകയാണെങ്കിൽ, ആവശ്യമായ കീ സംഭരിച്ചിരിക്കുന്ന RS-ലേക്ക് അഭ്യർത്ഥന നേരിട്ട് പോകുന്നു. ആദ്യം, മെംകാഷെയിലാണ് തിരയൽ നടത്തുന്നത്. അവിടെ ഡാറ്റ ഉണ്ടോ ഇല്ലയോ എന്നത് പരിഗണിക്കാതെ തന്നെ, തിരയൽ BlockCache ബഫറിലും ആവശ്യമെങ്കിൽ HFiles-ലും നടത്തുന്നു. ഫയലിൽ ഡാറ്റ കണ്ടെത്തിയാൽ, അത് ബ്ലോക്ക് കാഷെയിൽ സ്ഥാപിക്കുകയും അടുത്ത അഭ്യർത്ഥനയിൽ വേഗത്തിൽ തിരികെ നൽകുകയും ചെയ്യും. ബ്ലൂം ഫിൽട്ടറിൻ്റെ ഉപയോഗത്തിന് നന്ദി, HFile-ൽ തിരയുന്നത് താരതമ്യേന വേഗതയുള്ളതാണ്, അതായത്. ഒരു ചെറിയ അളവിലുള്ള ഡാറ്റ വായിച്ചുകഴിഞ്ഞാൽ, ഈ ഫയലിൽ ആവശ്യമായ കീ അടങ്ങിയിട്ടുണ്ടോ എന്ന് അത് ഉടനടി നിർണ്ണയിക്കുന്നു, ഇല്ലെങ്കിൽ, അടുത്തതിലേക്ക് നീങ്ങുന്നു.

ഈ മൂന്ന് ഉറവിടങ്ങളിൽ നിന്നും ഡാറ്റ ലഭിച്ച ശേഷം, RS ഒരു പ്രതികരണം സൃഷ്ടിക്കുന്നു. പ്രത്യേകിച്ചും, ക്ലയൻ്റ് വേർഷനിംഗ് അഭ്യർത്ഥിച്ചാൽ ഒരു ഒബ്‌ജക്റ്റിൻ്റെ കണ്ടെത്തിയ നിരവധി പതിപ്പുകൾ ഒരേസമയം കൈമാറാൻ ഇതിന് കഴിയും.

4. ഡാറ്റ കാഷിംഗ്

MemStore, BlockCache ബഫറുകൾ അനുവദിച്ച ഓൺ-ഹീപ്പ് RS മെമ്മറിയുടെ 80% വരെ ഉൾക്കൊള്ളുന്നു (ബാക്കിയുള്ളത് RS സേവന ടാസ്‌ക്കുകൾക്കായി നീക്കിവച്ചിരിക്കുന്നു). സാധാരണ ഉപയോഗ മോഡ് ഒരേ ഡാറ്റ എഴുതുകയും ഉടൻ വായിക്കുകയും ചെയ്യുന്ന തരത്തിലാണെങ്കിൽ, ബ്ലോക്ക് കാഷെ കുറയ്ക്കുകയും മെംസ്റ്റോർ വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നത് അർത്ഥമാക്കുന്നു, കാരണം ഡാറ്റ എഴുതുമ്പോൾ വായനയ്ക്കായി കാഷെയിൽ പ്രവേശിക്കാത്തപ്പോൾ, BlockCache വളരെ കുറച്ച് തവണ മാത്രമേ ഉപയോഗിക്കൂ. BlockCache ബഫറിൽ രണ്ട് ഭാഗങ്ങൾ അടങ്ങിയിരിക്കുന്നു: LruBlockCache (എല്ലായ്‌പ്പോഴും ഓൺ-ഹീപ്പ്), BucketCache (സാധാരണയായി ഓഫ്-ഹീപ്പ് അല്ലെങ്കിൽ ഒരു SSD-ൽ). ധാരാളം വായനാ അഭ്യർത്ഥനകൾ ഉള്ളപ്പോൾ ബക്കറ്റ് കാഷെ ഉപയോഗിക്കണം, അവ LruBlockCache-ലേക്ക് യോജിക്കുന്നില്ല, ഇത് ഗാർബേജ് കളക്ടറുടെ സജീവ പ്രവർത്തനത്തിലേക്ക് നയിക്കുന്നു. അതേ സമയം, റീഡ് കാഷെ ഉപയോഗിക്കുന്നതിൽ നിന്ന് പ്രകടനത്തിൽ സമൂലമായ വർദ്ധനവ് നിങ്ങൾ പ്രതീക്ഷിക്കരുത്, പക്ഷേ ഞങ്ങൾ ഇതിലേക്ക് 8-ാം ഖണ്ഡികയിലേക്ക് മടങ്ങും.

മുഴുവൻ RS-നും ഒരു BlockCache ഉണ്ട്, ഓരോ ടേബിളിനും ഒരു MemStore ഉണ്ട് (ഓരോ കോളം കുടുംബത്തിനും ഒന്ന്).

എങ്ങനെ വിവരിച്ചു സൈദ്ധാന്തികമായി, എഴുതുമ്പോൾ, ഡാറ്റ കാഷെയിലേക്ക് പോകുന്നില്ല, തീർച്ചയായും, പട്ടികയ്‌ക്കായുള്ള CACHE_DATA_ON_WRITE എന്ന പാരാമീറ്ററുകളും RS-നുള്ള "കാഷെ ഡാറ്റ ഓൺ റൈറ്റും" തെറ്റായി സജ്ജീകരിച്ചിരിക്കുന്നു. എന്നിരുന്നാലും, പ്രായോഗികമായി, ഞങ്ങൾ മെംസ്റ്റോറിലേക്ക് ഡാറ്റ എഴുതുകയാണെങ്കിൽ, അത് ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യുക (അങ്ങനെ അത് ക്ലിയർ ചെയ്യുക), തുടർന്ന് ഫലമായുണ്ടാകുന്ന ഫയൽ ഇല്ലാതാക്കുക, തുടർന്ന് ഒരു ഗെറ്റ് അഭ്യർത്ഥന നടപ്പിലാക്കുന്നതിലൂടെ ഞങ്ങൾക്ക് ഡാറ്റ വിജയകരമായി ലഭിക്കും. മാത്രമല്ല, നിങ്ങൾ 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

"വായനയിലെ കാഷെ ഡാറ്റ" പാരാമീറ്റർ തെറ്റ് എന്ന് സജ്ജീകരിച്ചിരിക്കുന്നു. നിങ്ങൾക്ക് എന്തെങ്കിലും ആശയങ്ങൾ ഉണ്ടെങ്കിൽ, അഭിപ്രായങ്ങളിൽ അത് ചർച്ച ചെയ്യാൻ സ്വാഗതം.

5. ബാച്ച് ഡാറ്റ പ്രോസസ്സിംഗ് MultiGet/MultiPut

സിംഗിൾ അഭ്യർത്ഥനകൾ (നേടുക/ ഇടുക/ ഇല്ലാതാക്കുക) പ്രോസസ്സ് ചെയ്യുന്നത് വളരെ ചെലവേറിയ പ്രവർത്തനമാണ്, അതിനാൽ സാധ്യമെങ്കിൽ, നിങ്ങൾ അവയെ ഒരു ലിസ്റ്റിലേക്കോ ലിസ്റ്റിലേക്കോ സംയോജിപ്പിക്കണം, ഇത് കാര്യമായ പ്രകടനം വർദ്ധിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. എഴുത്ത് പ്രവർത്തനത്തിന് ഇത് പ്രത്യേകിച്ചും സത്യമാണ്, പക്ഷേ വായിക്കുമ്പോൾ ഇനിപ്പറയുന്ന അപകടമുണ്ട്. MemStore-ൽ നിന്ന് 50 റെക്കോർഡുകൾ വായിക്കാനുള്ള സമയം ചുവടെയുള്ള ഗ്രാഫ് കാണിക്കുന്നു. ഒരു ത്രെഡിലാണ് വായന നടത്തിയത്, തിരശ്ചീന അക്ഷം അഭ്യർത്ഥനയിലെ കീകളുടെ എണ്ണം കാണിക്കുന്നു. ഒരു അഭ്യർത്ഥനയിൽ ആയിരം കീകൾ വർദ്ധിപ്പിക്കുമ്പോൾ, എക്സിക്യൂഷൻ സമയം കുറയുന്നത് ഇവിടെ കാണാം, അതായത്. വേഗത വർദ്ധിക്കുന്നു. എന്നിരുന്നാലും, സ്ഥിരസ്ഥിതിയായി MSLAB മോഡ് പ്രവർത്തനക്ഷമമാക്കിയാൽ, ഈ പരിധിക്ക് ശേഷം പ്രകടനത്തിൽ സമൂലമായ ഇടിവ് ആരംഭിക്കുന്നു, കൂടാതെ റെക്കോർഡിലെ ഡാറ്റയുടെ അളവ് കൂടുന്നതിനനുസരിച്ച് പ്രവർത്തന സമയം വർദ്ധിക്കും.

ഒരു വെർച്വൽ മെഷീനിൽ ടെസ്റ്റുകൾ നടത്തി, 8 കോറുകൾ, പതിപ്പ് HBase 2.0.0-cdh6.0.0-beta1.

MSLAB മോഡ് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത് ഹീപ്പ് ഫ്രാഗ്‌മെൻ്റേഷൻ കുറയ്ക്കുന്നതിനാണ്, ഇത് പുതിയതും പഴയതുമായ തലമുറ ഡാറ്റയുടെ മിശ്രിതം മൂലമാണ് സംഭവിക്കുന്നത്. ഒരു പരിഹാരമെന്ന നിലയിൽ, MSLAB പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ, ഡാറ്റ താരതമ്യേന ചെറിയ സെല്ലുകളിലേക്ക് (ചങ്കുകൾ) സ്ഥാപിക്കുകയും കഷണങ്ങളായി പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു. തൽഫലമായി, അഭ്യർത്ഥിച്ച ഡാറ്റാ പാക്കറ്റിലെ വോളിയം അനുവദിച്ച വലുപ്പത്തേക്കാൾ കൂടുതലാകുമ്പോൾ, പ്രകടനം കുത്തനെ കുറയുന്നു. മറുവശത്ത്, ഈ മോഡ് ഓഫാക്കുന്നത് ഉചിതമല്ല, കാരണം ഇത് തീവ്രമായ ഡാറ്റ പ്രോസസ്സിംഗിൻ്റെ നിമിഷങ്ങളിൽ ജിസി കാരണം സ്റ്റോപ്പുകളിലേക്ക് നയിക്കും. വായനയുടെ അതേ സമയം പുട്ട് വഴി സജീവമായി എഴുതുന്ന സാഹചര്യത്തിൽ സെൽ വോളിയം വർദ്ധിപ്പിക്കുക എന്നതാണ് ഒരു നല്ല പരിഹാരം. റെക്കോർഡിംഗിന് ശേഷം, നിങ്ങൾ മെംസ്റ്റോറിനെ ഡിസ്കിലേക്ക് പുനഃസജ്ജമാക്കുന്ന ഫ്ലഷ് കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയോ ബൾക്ക്ലോഡ് ഉപയോഗിച്ച് ലോഡ് ചെയ്യുകയോ ചെയ്താൽ പ്രശ്നം ഉണ്ടാകില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. MemStore-ൽ നിന്നുള്ള വലിയ (ഒരേ തുക) ഡാറ്റയ്‌ക്കായുള്ള അന്വേഷണങ്ങൾ വേഗത കുറയുന്നതിന് കാരണമാകുമെന്ന് ചുവടെയുള്ള പട്ടിക കാണിക്കുന്നു. എന്നിരുന്നാലും, ചങ്ക്‌സൈസ് വർദ്ധിപ്പിക്കുന്നതിലൂടെ ഞങ്ങൾ പ്രോസസ്സിംഗ് സമയം സാധാരണ നിലയിലാക്കുന്നു.

ചങ്ക്‌സൈസ് വർദ്ധിപ്പിക്കുന്നതിന് പുറമേ, പ്രദേശം അനുസരിച്ച് ഡാറ്റ വിഭജിക്കുന്നത് സഹായിക്കുന്നു, അതായത്. പട്ടിക വിഭജനം. ഇത് ഓരോ പ്രദേശത്തേക്കും കുറച്ച് അഭ്യർത്ഥനകൾ വരുന്നതിലേക്ക് നയിക്കുന്നു, അവ ഒരു സെല്ലിൽ ചേരുകയാണെങ്കിൽ, പ്രതികരണം മികച്ചതായി തുടരും.

6. ടേബിളുകൾ മേഖലകളായി വിഭജിക്കുന്നതിനുള്ള തന്ത്രം (വിഭജനം)

HBase ഒരു കീ-വാല്യൂ സ്റ്റോറേജ് ആയതിനാൽ, പാർട്ടീഷനിംഗ് കീ വഴിയാണ് നടത്തുന്നത്, എല്ലാ പ്രദേശങ്ങളിലും ഡാറ്റ തുല്യമായി വിഭജിക്കേണ്ടത് വളരെ പ്രധാനമാണ്. ഉദാഹരണത്തിന്, അത്തരമൊരു പട്ടിക മൂന്ന് ഭാഗങ്ങളായി വിഭജിക്കുന്നത് ഡാറ്റയെ മൂന്ന് മേഖലകളായി വിഭജിക്കുന്നതിന് കാരണമാകും:

പിന്നീട് ലോഡ് ചെയ്ത ഡാറ്റ, ഉദാഹരണത്തിന്, ദൈർഘ്യമേറിയ മൂല്യങ്ങൾ, അവയിൽ മിക്കതും ഒരേ അക്കത്തിൽ ആരംഭിക്കുന്നതുപോലെ കാണപ്പെടുന്നുവെങ്കിൽ, ഇത് കുത്തനെ മാന്ദ്യത്തിലേക്ക് നയിക്കുന്നു, ഉദാഹരണത്തിന്:

1000001
1000002
പങ്ക് € |
1100003

കീകൾ ഒരു ബൈറ്റ് അറേ ആയി സംഭരിച്ചിരിക്കുന്നതിനാൽ, അവയെല്ലാം ഒരേപോലെ ആരംഭിക്കുകയും ഈ കീകളുടെ ശ്രേണി സംഭരിക്കുന്ന ഒരേ റീജിയൻ #1-ൽ ഉൾപ്പെടുകയും ചെയ്യും. നിരവധി വിഭജന തന്ത്രങ്ങൾ ഉണ്ട്:

HexStringSplit – കീയെ "00000000" => "FFFFFFFF" ശ്രേണിയിൽ ഒരു ഹെക്സാഡെസിമൽ എൻകോഡ് ചെയ്ത സ്ട്രിംഗാക്കി മാറ്റുകയും ഇടതുവശത്ത് പൂജ്യങ്ങൾ പാഡ് ചെയ്യുകയും ചെയ്യുന്നു.

UniformSplit – "00" => "FF" ശ്രേണിയിലെ ഹെക്‌സാഡെസിമൽ എൻകോഡിംഗും വലതുവശത്ത് പൂജ്യങ്ങളുള്ള പാഡിംഗും ഉപയോഗിച്ച് കീയെ ഒരു ബൈറ്റ് അറേ ആക്കി മാറ്റുന്നു.

കൂടാതെ, വിഭജനത്തിനായി നിങ്ങൾക്ക് ഏതെങ്കിലും ശ്രേണി അല്ലെങ്കിൽ കീകളുടെ സെറ്റ് വ്യക്തമാക്കാനും സ്വയമേവ വിഭജനം ക്രമീകരിക്കാനും കഴിയും. എന്നിരുന്നാലും, ഏറ്റവും ലളിതവും ഫലപ്രദവുമായ സമീപനങ്ങളിലൊന്നാണ് യൂണിഫോംസ്പ്ലിറ്റും ഹാഷ് കോൺകാറ്റനേഷൻ്റെ ഉപയോഗവും, ഉദാഹരണത്തിന് CRC32(rowkey) ഫംഗ്ഷനിലൂടെയും റോക്കിയിലൂടെയും കീ പ്രവർത്തിപ്പിക്കുന്നതിൽ നിന്നുള്ള ഏറ്റവും പ്രധാനപ്പെട്ട ജോഡി ബൈറ്റുകൾ:

ഹാഷ് + റോക്കി

തുടർന്ന് എല്ലാ ഡാറ്റയും പ്രദേശങ്ങളിലുടനീളം തുല്യമായി വിതരണം ചെയ്യും. വായിക്കുമ്പോൾ, ആദ്യത്തെ രണ്ട് ബൈറ്റുകൾ വെറുതെ കളയുകയും യഥാർത്ഥ കീ ​​നിലനിൽക്കുകയും ചെയ്യും. പ്രദേശത്തെ ഡാറ്റയുടെയും കീകളുടെയും അളവും RS നിയന്ത്രിക്കുന്നു, പരിധികൾ കവിഞ്ഞാൽ, അത് യാന്ത്രികമായി ഭാഗങ്ങളായി വിഭജിക്കുന്നു.

7. തെറ്റ് സഹിഷ്ണുതയും ഡാറ്റ പ്രാദേശികതയും

ഓരോ സെറ്റ് കീകൾക്കും ഒരു പ്രദേശം മാത്രമേ ഉത്തരവാദിയായിട്ടുള്ളൂ എന്നതിനാൽ, RS ക്രാഷുകളുമായോ ഡീകമ്മീഷനിംഗുമായോ ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾക്കുള്ള പരിഹാരം HDFS-ൽ ആവശ്യമായ എല്ലാ ഡാറ്റയും സംഭരിക്കുക എന്നതാണ്. RS വീഴുമ്പോൾ, ZooKeeper നോഡിൽ ഹൃദയമിടിപ്പിൻ്റെ അഭാവത്തിൽ മാസ്റ്റർ ഇത് കണ്ടെത്തുന്നു. പിന്നീട് അത് മറ്റൊരു RS-ലേക്ക് സെർവ് ചെയ്ത മേഖലയെ നിയോഗിക്കുന്നു, കൂടാതെ HFiles ഒരു വിതരണം ചെയ്ത ഫയൽ സിസ്റ്റത്തിൽ സംഭരിച്ചിരിക്കുന്നതിനാൽ, പുതിയ ഉടമ അവ വായിക്കുകയും ഡാറ്റ നൽകുന്നത് തുടരുകയും ചെയ്യുന്നു. എന്നിരുന്നാലും, ചില ഡാറ്റ MemStore-ൽ ആയിരിക്കാം, HFiles-ൽ പ്രവേശിക്കാൻ സമയമില്ലാതിരുന്നതിനാൽ, പ്രവർത്തനങ്ങളുടെ ചരിത്രം പുനഃസ്ഥാപിക്കാൻ HDFS-ലും സംഭരിച്ചിരിക്കുന്ന WAL ഉപയോഗിക്കുന്നു. മാറ്റങ്ങൾ പ്രയോഗിച്ചതിന് ശേഷം, അഭ്യർത്ഥനകളോട് പ്രതികരിക്കാൻ RS-ന് കഴിയും, എന്നാൽ ഈ നീക്കം ചില ഡാറ്റയും അവയ്ക്ക് സേവനം നൽകുന്ന പ്രക്രിയകളും വ്യത്യസ്ത നോഡുകളിൽ അവസാനിക്കുന്നു എന്ന വസ്തുതയിലേക്ക് നയിക്കുന്നു, അതായത്. പ്രദേശം കുറയുന്നു.

പ്രശ്നത്തിനുള്ള പരിഹാരം പ്രധാന കോംപാക്ഷൻ ആണ് - ഈ നടപടിക്രമം ഫയലുകളെ അവയ്ക്ക് ഉത്തരവാദികളായ നോഡുകളിലേക്ക് നീക്കുന്നു (അവയുടെ പ്രദേശങ്ങൾ എവിടെയാണ്), അതിൻ്റെ ഫലമായി ഈ പ്രക്രിയയ്ക്കിടെ നെറ്റ്‌വർക്കിലെയും ഡിസ്കുകളിലെയും ലോഡ് കുത്തനെ വർദ്ധിക്കുന്നു. എന്നിരുന്നാലും, ഭാവിയിൽ, ഡാറ്റയിലേക്കുള്ള ആക്സസ് ശ്രദ്ധേയമായി ത്വരിതപ്പെടുത്തുന്നു. കൂടാതെ, major_compaction എല്ലാ HFiles-ഉം ഒരു പ്രദേശത്തിനുള്ളിൽ ഒരു ഫയലിലേക്ക് ലയിപ്പിക്കുന്നു, കൂടാതെ പട്ടിക ക്രമീകരണങ്ങൾക്കനുസരിച്ച് ഡാറ്റ വൃത്തിയാക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഒബ്‌ജക്‌റ്റിൻ്റെ നിലനിർത്തേണ്ട പതിപ്പുകളുടെ എണ്ണം അല്ലെങ്കിൽ ഒബ്‌ജക്റ്റ് ഭൗതികമായി ഇല്ലാതാക്കിയ ജീവിതകാലം എന്നിവ നിങ്ങൾക്ക് വ്യക്തമാക്കാൻ കഴിയും.

ഈ നടപടിക്രമം HBase- ൻ്റെ പ്രവർത്തനത്തിൽ വളരെ നല്ല സ്വാധീനം ചെലുത്തും. സജീവ ഡാറ്റ റെക്കോർഡിംഗിൻ്റെ ഫലമായി പ്രകടനം എങ്ങനെ കുറഞ്ഞുവെന്ന് ചുവടെയുള്ള ചിത്രം കാണിക്കുന്നു. ഒരു ടേബിളിലേക്ക് 40 ത്രെഡുകൾ എഴുതിയതും 40 ത്രെഡുകൾ ഒരേസമയം ഡാറ്റ വായിക്കുന്നതും ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും. റൈറ്റിംഗ് ത്രെഡുകൾ കൂടുതൽ കൂടുതൽ എച്ച് ഫയലുകൾ സൃഷ്ടിക്കുന്നു, അവ മറ്റ് ത്രെഡുകൾ വായിക്കുന്നു. തൽഫലമായി, മെമ്മറിയിൽ നിന്ന് കൂടുതൽ കൂടുതൽ ഡാറ്റ നീക്കംചെയ്യേണ്ടതുണ്ട്, ഒടുവിൽ ജിസി പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു, ഇത് എല്ലാ പ്രവർത്തനങ്ങളെയും പ്രായോഗികമായി തളർത്തുന്നു. മേജർ കോംപാക്‌ഷൻ്റെ വിക്ഷേപണം ഫലമായുണ്ടാകുന്ന അവശിഷ്ടങ്ങൾ നീക്കം ചെയ്യുന്നതിനും ഉൽപാദനക്ഷമത പുനഃസ്ഥാപിക്കുന്നതിനും കാരണമായി.

3 ഡാറ്റാ നോഡുകളിലും 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ത്രെഡുകൾ) ലും പരിശോധന നടത്തി. HBase പതിപ്പ് 1.2.0-cdh5.14.2

ഒരു "തത്സമയ" പട്ടികയിൽ പ്രധാന കോംപാക്ഷൻ സമാരംഭിച്ചു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, അതിൽ ഡാറ്റ സജീവമായി എഴുതുകയും വായിക്കുകയും ചെയ്തു. ഡാറ്റ വായിക്കുമ്പോൾ ഇത് തെറ്റായ പ്രതികരണത്തിന് കാരണമാകുമെന്ന് ഓൺലൈനിൽ ഒരു പ്രസ്താവന ഉണ്ടായിരുന്നു. പരിശോധിക്കുന്നതിനായി, പുതിയ ഡാറ്റ സൃഷ്ടിച്ച് ഒരു ടേബിളിൽ എഴുതുന്ന ഒരു പ്രക്രിയ ആരംഭിച്ചു. അതിനുശേഷം, തത്ഫലമായുണ്ടാകുന്ന മൂല്യം എഴുതിയതുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് ഞാൻ ഉടൻ വായിക്കുകയും പരിശോധിക്കുകയും ചെയ്തു. ഈ പ്രക്രിയ പ്രവർത്തിക്കുമ്പോൾ, പ്രധാന കോംപാക്ഷൻ 200 തവണ പ്രവർത്തിപ്പിച്ചു, ഒരു പരാജയം പോലും രേഖപ്പെടുത്തിയില്ല. ഒരുപക്ഷേ പ്രശ്നം വളരെ അപൂർവമായി മാത്രമേ പ്രത്യക്ഷപ്പെടുകയുള്ളൂ, ഉയർന്ന ലോഡിൽ മാത്രമേ ഉണ്ടാകൂ, അതിനാൽ ആസൂത്രണം ചെയ്തതുപോലെ എഴുത്തും വായനയും നിർത്തുകയും അത്തരം GC ഡ്രോഡൗണുകൾ തടയുന്നതിന് ക്ലീനിംഗ് നടത്തുകയും ചെയ്യുന്നത് സുരക്ഷിതമാണ്.

കൂടാതെ, പ്രധാന കോംപാക്ഷൻ മെംസ്റ്റോറിൻ്റെ അവസ്ഥയെ ബാധിക്കില്ല; ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യാനും ഒതുക്കാനും, നിങ്ങൾ ഫ്ലഷ് ഉപയോഗിക്കേണ്ടതുണ്ട് (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. ക്രമീകരണങ്ങളും പ്രകടനവും

ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, ബൾക്ക്ലോഡ് എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, ഒന്നും ചെയ്യേണ്ടതില്ലാത്തിടത്ത് HBase അതിൻ്റെ ഏറ്റവും വലിയ വിജയം കാണിക്കുന്നു. എന്നിരുന്നാലും, ഇത് മിക്ക സിസ്റ്റങ്ങൾക്കും ആളുകൾക്കും ബാധകമാണ്. എന്നിരുന്നാലും, വലിയ ബ്ലോക്കുകളിൽ ഡാറ്റ ബൾക്ക് ആയി സംഭരിക്കുന്നതിന് ഈ ടൂൾ കൂടുതൽ അനുയോജ്യമാണ്, അതേസമയം പ്രക്രിയയ്ക്ക് ഒന്നിലധികം മത്സരിക്കുന്ന റീഡ് ആൻഡ് റൈറ്റ് അഭ്യർത്ഥനകൾ ആവശ്യമാണെങ്കിൽ, മുകളിൽ വിവരിച്ച Get and Put കമാൻഡുകൾ ഉപയോഗിക്കുന്നു. ഒപ്റ്റിമൽ പാരാമീറ്ററുകൾ നിർണ്ണയിക്കുന്നതിന്, ടേബിൾ പാരാമീറ്ററുകളുടെയും ക്രമീകരണങ്ങളുടെയും വിവിധ കോമ്പിനേഷനുകൾ ഉപയോഗിച്ച് ലോഞ്ചുകൾ നടത്തി:

• 10 ത്രെഡുകൾ ഒരേസമയം 3 തവണ തുടർച്ചയായി സമാരംഭിച്ചു (ഇതിനെ നമുക്ക് ത്രെഡുകളുടെ ഒരു ബ്ലോക്ക് എന്ന് വിളിക്കാം).
• ഒരു ബ്ലോക്കിലെ എല്ലാ ത്രെഡുകളുടെയും പ്രവർത്തന സമയം ശരാശരി കണക്കാക്കി, ബ്ലോക്കിൻ്റെ പ്രവർത്തനത്തിൻ്റെ അന്തിമ ഫലമായിരുന്നു അത്.
• എല്ലാ ത്രെഡുകളും ഒരേ പട്ടികയിൽ പ്രവർത്തിച്ചു.
• ത്രെഡ് ബ്ലോക്കിൻ്റെ ഓരോ തുടക്കത്തിനും മുമ്പ്, ഒരു പ്രധാന കോംപാക്ഷൻ നടത്തി.
• ഓരോ ബ്ലോക്കും ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങളിൽ ഒന്ന് മാത്രമാണ് നടത്തിയത്:

- ഇടുക
- നേടുക
- നേടുക+ ഇടുക

• ഓരോ ബ്ലോക്കും അതിൻ്റെ പ്രവർത്തനത്തിൻ്റെ 50 ആവർത്തനങ്ങൾ നടത്തി.
• ഒരു റെക്കോർഡിൻ്റെ ബ്ലോക്ക് വലുപ്പം 100 ബൈറ്റുകൾ, 1000 ബൈറ്റുകൾ അല്ലെങ്കിൽ 10000 ബൈറ്റുകൾ (റാൻഡം) ആണ്.
• അഭ്യർത്ഥിച്ച വിവിധ എണ്ണം കീകൾ (ഒന്നുകിൽ ഒരു കീ അല്ലെങ്കിൽ 10) ഉപയോഗിച്ച് ബ്ലോക്കുകൾ സമാരംഭിച്ചു.
• വ്യത്യസ്ത പട്ടിക ക്രമീകരണങ്ങൾക്ക് കീഴിൽ ബ്ലോക്കുകൾ പ്രവർത്തിപ്പിച്ചു. പരാമീറ്ററുകൾ മാറ്റി:

— BlockCache = ഓൺ അല്ലെങ്കിൽ ഓഫ്
— ബ്ലോക്ക് സൈസ് = 65 KB അല്ലെങ്കിൽ 16 KB
- പാർട്ടീഷനുകൾ = 1, 5 അല്ലെങ്കിൽ 30
— MSLAB = പ്രവർത്തനക്ഷമമാക്കി അല്ലെങ്കിൽ പ്രവർത്തനരഹിതമാക്കി

അതിനാൽ ബ്ലോക്ക് ഇതുപോലെ കാണപ്പെടുന്നു:

എ. MSLAB മോഡ് ഓൺ/ഓഫ് ചെയ്തു.
ബി. ഇനിപ്പറയുന്ന പാരാമീറ്ററുകൾ സജ്ജീകരിച്ച ഒരു പട്ടിക സൃഷ്ടിച്ചു: ബ്ലോക്ക് കാഷെ = ശരി/ഒന്നുമില്ല, ബ്ലോക്ക് സൈസ് = 65/16 കെബി, പാർട്ടീഷൻ = 1/5/30.
സി. കംപ്രഷൻ GZ ആയി സജ്ജീകരിച്ചു.
ഡി. 10/1/10 ബൈറ്റുകളുടെ റെക്കോർഡുകളുള്ള ഈ ടേബിളിലേക്ക് 100/1000 പുട്ട്/ഗെറ്റ്/ഗെറ്റ്+പുട്ട് ഓപ്പറേഷനുകൾ ചെയ്തുകൊണ്ട് ഒരേസമയം 10000 ​​ത്രെഡുകൾ സമാരംഭിച്ചു, തുടർച്ചയായി 50 അന്വേഷണങ്ങൾ നടത്തുന്നു (റാൻഡം കീകൾ).
ഇ. പോയിൻ്റ് ഡി മൂന്ന് തവണ ആവർത്തിച്ചു.
എഫ്. എല്ലാ ത്രെഡുകളുടെയും പ്രവർത്തന സമയം ശരാശരിയാണ്.

സാധ്യമായ എല്ലാ കോമ്പിനേഷനുകളും പരീക്ഷിച്ചു. റെക്കോർഡ് വലുപ്പം കൂടുന്നതിനനുസരിച്ച് വേഗത കുറയുമെന്ന് പ്രവചിക്കാവുന്നതാണ്, അല്ലെങ്കിൽ കാഷിംഗ് പ്രവർത്തനരഹിതമാക്കുന്നത് വേഗത കുറയുന്നതിന് കാരണമാകും. എന്നിരുന്നാലും, ഓരോ പാരാമീറ്ററിൻ്റെയും സ്വാധീനത്തിൻ്റെ അളവും പ്രാധാന്യവും മനസ്സിലാക്കുക എന്നതായിരുന്നു ലക്ഷ്യം, അതിനാൽ ശേഖരിച്ച ഡാറ്റ ഒരു ലീനിയർ റിഗ്രഷൻ ഫംഗ്ഷൻ്റെ ഇൻപുട്ടിലേക്ക് നൽകി, ഇത് ടി-സ്റ്റാറ്റിസ്റ്റിക്സ് ഉപയോഗിച്ച് പ്രാധാന്യം വിലയിരുത്തുന്നത് സാധ്യമാക്കുന്നു. പുട്ട് പ്രവർത്തനങ്ങൾ നടത്തുന്ന ബ്ലോക്കുകളുടെ ഫലങ്ങൾ ചുവടെയുണ്ട്. കോമ്പിനേഷനുകളുടെ പൂർണ്ണ സെറ്റ് 2 * 2 * 3 * 2 * 3 = 144 ഓപ്ഷനുകൾ + 72 tk. ചിലത് രണ്ടുതവണ ചെയ്തു. അതിനാൽ, ആകെ 216 റൺസ് ഉണ്ട്:

3 ഡാറ്റ നോഡുകളും 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ത്രെഡുകൾ) അടങ്ങുന്ന ഒരു മിനി-ക്ലസ്റ്ററിലാണ് പരിശോധന നടത്തിയത്. HBase പതിപ്പ് 1.2.0-cdh5.14.2.

ഒരു പാർട്ടീഷനുള്ള ഒരു ടേബിളിൽ, BlockCache പ്രവർത്തനക്ഷമമാക്കി, BlockSize = 3.7, 16 ബൈറ്റുകളുടെ റെക്കോർഡുകൾ, ഒരു പായ്ക്കിന് 100 പീസുകൾ, MSLAB മോഡ് ഓഫാക്കിയപ്പോൾ, 10 സെക്കൻഡിൻ്റെ ഉയർന്ന ഇൻസേർഷൻ വേഗത ലഭിച്ചു.
MSLAB മോഡ് പ്രവർത്തനക്ഷമമാക്കിയ 82.8 സെക്കൻ്റാണ് ഏറ്റവും കുറഞ്ഞ ഇൻസേർഷൻ വേഗത, ഒരു പാർട്ടീഷനുള്ള ഒരു ടേബിളിൽ, BlockCache പ്രവർത്തനക്ഷമമാക്കി, BlockSize = 16, 10000 ബൈറ്റുകളുടെ റെക്കോർഡുകൾ, 1 വീതം.

ഇനി നമുക്ക് മാതൃക നോക്കാം. R2 അടിസ്ഥാനമാക്കിയുള്ള മോഡലിൻ്റെ നല്ല നിലവാരം ഞങ്ങൾ കാണുന്നു, പക്ഷേ എക്സ്ട്രാപോളേഷൻ ഇവിടെ വിപരീതഫലമാണെന്ന് വ്യക്തമാണ്. പരാമീറ്ററുകൾ മാറുമ്പോൾ സിസ്റ്റത്തിൻ്റെ യഥാർത്ഥ സ്വഭാവം രേഖീയമായിരിക്കില്ല; ഉദാഹരണത്തിന്, പുട്ട് ഓപ്പറേഷന് BlockSize, BlockCache പാരാമീറ്ററുകൾ പ്രശ്നമല്ലെന്ന് വിദ്യാർത്ഥിയുടെ മാനദണ്ഡത്തിൽ നിന്ന് ഞങ്ങൾ ഇവിടെ കാണുന്നു (ഇത് പൊതുവെ പ്രവചിക്കാവുന്നതാണ്):

എന്നാൽ പാർട്ടീഷനുകളുടെ എണ്ണം വർദ്ധിക്കുന്നത് പ്രകടനത്തിൽ കുറവുണ്ടാക്കുന്നു എന്ന വസ്തുത ഒരു പരിധിവരെ അപ്രതീക്ഷിതമാണ് (ബൾക്ക്ലോഡ് ഉപയോഗിച്ച് പാർട്ടീഷനുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതിൻ്റെ നല്ല സ്വാധീനം ഞങ്ങൾ ഇതിനകം കണ്ടു), മനസ്സിലാക്കാവുന്നതാണെങ്കിലും. ഒന്നാമതായി, പ്രോസസ്സിംഗിനായി, ഒന്നിന് പകരം 30 മേഖലകളിലേക്ക് അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്, കൂടാതെ ഡാറ്റയുടെ അളവ് ഇത് നേട്ടമുണ്ടാക്കുന്ന തരത്തിലല്ല. രണ്ടാമതായി, മൊത്തം പ്രവർത്തന സമയം നിർണ്ണയിക്കുന്നത് വേഗത കുറഞ്ഞ RS ആണ്, കൂടാതെ ഡാറ്റാനോഡുകളുടെ എണ്ണം RS-കളുടെ എണ്ണത്തേക്കാൾ കുറവായതിനാൽ, ചില പ്രദേശങ്ങൾക്ക് പൂജ്യം പ്രാദേശികതയുണ്ട്. ശരി, നമുക്ക് ആദ്യ അഞ്ച് കാര്യങ്ങൾ നോക്കാം:

ഗെറ്റ് ബ്ലോക്കുകൾ നടപ്പിലാക്കുന്നതിൻ്റെ ഫലങ്ങൾ ഇപ്പോൾ നമുക്ക് വിലയിരുത്താം:

പാർട്ടീഷനുകളുടെ എണ്ണത്തിന് പ്രാധാന്യം നഷ്‌ടപ്പെട്ടു, ഡാറ്റ നന്നായി കാഷെ ചെയ്‌തിരിക്കുന്നതും റീഡ് കാഷെ ഏറ്റവും പ്രധാനപ്പെട്ട (സ്റ്റാറ്റിസ്റ്റിക്കൽ) പരാമീറ്ററും ആയതിനാൽ ഇത് വിശദീകരിക്കാം. സ്വാഭാവികമായും, ഒരു അഭ്യർത്ഥനയിലെ സന്ദേശങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതും പ്രകടനത്തിന് വളരെ ഉപയോഗപ്രദമാണ്. മികച്ച സ്കോറുകൾ:

ശരി, ഒടുവിൽ, ആദ്യം നിർവഹിച്ച ബ്ലോക്കിൻ്റെ മോഡൽ നോക്കാം, തുടർന്ന് ഇടുക:

എല്ലാ പാരാമീറ്ററുകളും ഇവിടെ പ്രധാനമാണ്. നേതാക്കളുടെ ഫലങ്ങളും:

9. ലോഡ് ടെസ്റ്റിംഗ്

ശരി, ഒടുവിൽ ഞങ്ങൾ കൂടുതലോ കുറവോ മാന്യമായ ലോഡ് സമാരംഭിക്കും, എന്നാൽ നിങ്ങൾക്ക് താരതമ്യം ചെയ്യാൻ എന്തെങ്കിലും ഉള്ളപ്പോൾ ഇത് എല്ലായ്പ്പോഴും കൂടുതൽ രസകരമാണ്. കസാന്ദ്രയുടെ പ്രധാന ഡെവലപ്പറായ DataStax-ൻ്റെ വെബ്സൈറ്റിൽ ഉണ്ട് ഫലങ്ങൾ HBase പതിപ്പ് 0.98.6-1 ഉൾപ്പെടെ നിരവധി NoSQL സ്റ്റോറേജുകളുടെ NT. 40 ത്രെഡുകൾ, ഡാറ്റ വലുപ്പം 100 ബൈറ്റുകൾ, എസ്എസ്ഡി ഡിസ്കുകൾ എന്നിവ ഉപയോഗിച്ച് ലോഡിംഗ് നടത്തി. റീഡ്-മോഡിഫൈ-റൈറ്റ് ഓപ്പറേഷനുകൾ പരീക്ഷിച്ചതിൻ്റെ ഫലം ഇനിപ്പറയുന്ന ഫലങ്ങൾ കാണിച്ചു.

ഞാൻ മനസ്സിലാക്കിയിടത്തോളം, 100 റെക്കോർഡുകളുടെ ബ്ലോക്കുകളിലാണ് വായന നടത്തിയത്, കൂടാതെ 16 എച്ച്ബേസ് നോഡുകൾക്കായി, ഡാറ്റാസ്റ്റാക്സ് ടെസ്റ്റ് സെക്കൻഡിൽ 10 ആയിരം പ്രവർത്തനങ്ങളുടെ പ്രകടനം കാണിച്ചു.

ഞങ്ങളുടെ ക്ലസ്റ്ററിനും 16 നോഡുകൾ ഉണ്ടെന്നത് ഭാഗ്യമാണ്, എന്നാൽ ഓരോന്നിനും 64 കോറുകൾ (ത്രെഡുകൾ) ഉള്ളത് വളരെ “ഭാഗ്യമല്ല”, അതേസമയം ഡാറ്റാസ്റ്റാക്സ് ടെസ്റ്റിൽ 4 മാത്രമേയുള്ളൂ. മറുവശത്ത്, അവർക്ക് SSD ഡ്രൈവുകൾ ഉണ്ട്, ഞങ്ങൾക്ക് HDD-കൾ ഉണ്ട്. അല്ലെങ്കിൽ കൂടുതൽ പുതിയ പതിപ്പായ HBase, CPU ഉപയോഗം ലോഡ് സമയത്ത് പ്രായോഗികമായി ഗണ്യമായി വർദ്ധിച്ചില്ല (കാഴ്ചയിൽ 5-10 ശതമാനം). എന്നിരുന്നാലും, ഈ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് തുടങ്ങാൻ ശ്രമിക്കാം. സ്ഥിരസ്ഥിതി പട്ടിക ക്രമീകരണങ്ങൾ, വായന 0 മുതൽ 50 ദശലക്ഷം വരെയുള്ള കീ ശ്രേണിയിൽ ക്രമരഹിതമായി നടപ്പിലാക്കുന്നു (അതായത്, ഓരോ തവണയും പുതിയത്). പട്ടികയിൽ 50 ദശലക്ഷം റെക്കോർഡുകൾ അടങ്ങിയിരിക്കുന്നു, 64 പാർട്ടീഷനുകളായി തിരിച്ചിരിക്കുന്നു. കീകൾ crc32 ഉപയോഗിച്ചാണ് ഹാഷ് ചെയ്തിരിക്കുന്നത്. പട്ടിക ക്രമീകരണങ്ങൾ ഡിഫോൾട്ടാണ്, MSLAB പ്രവർത്തനക്ഷമമാക്കി. 40 ത്രെഡുകൾ സമാരംഭിക്കുമ്പോൾ, ഓരോ ത്രെഡും 100 റാൻഡം കീകളുടെ ഒരു സെറ്റ് വായിക്കുകയും ഉടനടി ജനറേറ്റ് ചെയ്ത 100 ബൈറ്റുകൾ ഈ കീകളിലേക്ക് തിരികെ എഴുതുകയും ചെയ്യുന്നു.

സ്റ്റാൻഡ്: 16 ഡാറ്റാനോഡും 16 ആർഎസും (സിപിയു സിയോൺ ഇ5-2680 വി4 @ 2.40GHz * 64 ത്രെഡുകൾ). HBase പതിപ്പ് 1.2.0-cdh5.14.2.

ശരാശരി ഫലം സെക്കൻഡിൽ 40 പ്രവർത്തനങ്ങളുടെ അടുത്താണ്, ഇത് DataStax ടെസ്റ്റിനേക്കാൾ മികച്ചതാണ്. എന്നിരുന്നാലും, പരീക്ഷണാത്മക ആവശ്യങ്ങൾക്കായി, നിങ്ങൾക്ക് വ്യവസ്ഥകൾ ചെറുതായി മാറ്റാൻ കഴിയും. എല്ലാ ജോലികളും ഒരു ടേബിളിൽ മാത്രമായി നടത്താനും അതുല്യമായ കീകളിൽ മാത്രം നടത്താനും സാധ്യതയില്ല. പ്രധാന ലോഡ് സൃഷ്ടിക്കുന്ന ഒരു പ്രത്യേക "ചൂടുള്ള" കീകൾ ഉണ്ടെന്ന് നമുക്ക് അനുമാനിക്കാം. അതിനാൽ, വലിയ റെക്കോർഡുകളുള്ള (10 KB) ഒരു ലോഡ് സൃഷ്ടിക്കാൻ ശ്രമിക്കാം, കൂടാതെ 100 ബാച്ചുകളിലും 4 വ്യത്യസ്ത പട്ടികകളിലായി അഭ്യർത്ഥിച്ച കീകളുടെ പരിധി 50 ആയിരം ആയി പരിമിതപ്പെടുത്തുന്നു, ചുവടെയുള്ള ഗ്രാഫ് 40 ത്രെഡുകളുടെ സമാരംഭം കാണിക്കുന്നു, ഓരോ ത്രെഡും 100 കീകളുടെ ഒരു കൂട്ടം, ഈ കീകളിൽ ഉടൻ തന്നെ ക്രമരഹിതമായി 10 KB എഴുതുന്നു.

സ്റ്റാൻഡ്: 16 ഡാറ്റാനോഡും 16 ആർഎസും (സിപിയു സിയോൺ ഇ5-2680 വി4 @ 2.40GHz * 64 ത്രെഡുകൾ). HBase പതിപ്പ് 1.2.0-cdh5.14.2.

ലോഡ് സമയത്ത്, മേജർ കോംപാക്ഷൻ നിരവധി തവണ സമാരംഭിച്ചു, മുകളിൽ കാണിച്ചിരിക്കുന്നതുപോലെ, ഈ നടപടിക്രമമില്ലാതെ, പ്രകടനം ക്രമേണ കുറയും, എന്നിരുന്നാലും, എക്സിക്യൂഷൻ സമയത്ത് അധിക ലോഡും ഉണ്ടാകുന്നു. ഡ്രോഡൗണുകൾ വിവിധ കാരണങ്ങളാൽ സംഭവിക്കുന്നു. ചിലപ്പോൾ ത്രെഡുകൾ പ്രവർത്തനം പൂർത്തിയാക്കി, അവ പുനരാരംഭിക്കുമ്പോൾ ഒരു താൽക്കാലിക വിരാമമുണ്ടായി, ചിലപ്പോൾ മൂന്നാം കക്ഷി ആപ്ലിക്കേഷനുകൾ ക്ലസ്റ്ററിൽ ഒരു ലോഡ് സൃഷ്ടിച്ചു.

എച്ച്‌ബേസിൻ്റെ ഏറ്റവും പ്രയാസകരമായ ജോലി സാഹചര്യങ്ങളിലൊന്നാണ് വായിക്കുന്നതും ഉടനടി എഴുതുന്നതും. നിങ്ങൾ ചെറിയ പുട്ട് അഭ്യർത്ഥനകൾ മാത്രം നടത്തുകയാണെങ്കിൽ, ഉദാഹരണത്തിന് 100 ബൈറ്റുകൾ, അവയെ 10-50 ആയിരം കഷണങ്ങളുള്ള പായ്ക്കുകളായി സംയോജിപ്പിച്ച്, നിങ്ങൾക്ക് സെക്കൻഡിൽ ലക്ഷക്കണക്കിന് പ്രവർത്തനങ്ങൾ നേടാനാകും, കൂടാതെ വായന-മാത്രം അഭ്യർത്ഥനകളുമായി സ്ഥിതി സമാനമാണ്. 50 ആയിരം ബ്ലോക്കുകളിലെ അഭ്യർത്ഥനകൾ കാരണം, ഡാറ്റാസ്റ്റാക്സ് ലഭിച്ചതിനേക്കാൾ സമൂലമായി മികച്ച ഫലങ്ങൾ ഉണ്ടെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

സ്റ്റാൻഡ്: 16 ഡാറ്റാനോഡും 16 ആർഎസും (സിപിയു സിയോൺ ഇ5-2680 വി4 @ 2.40GHz * 64 ത്രെഡുകൾ). HBase പതിപ്പ് 1.2.0-cdh5.14.2.

10. നിഗമനങ്ങൾ

ഈ സിസ്റ്റം തികച്ചും അയവുള്ള രീതിയിൽ ക്രമീകരിച്ചിരിക്കുന്നു, പക്ഷേ ധാരാളം പാരാമീറ്ററുകളുടെ സ്വാധീനം ഇപ്പോഴും അജ്ഞാതമായി തുടരുന്നു. അവയിൽ ചിലത് പരീക്ഷിക്കപ്പെട്ടു, പക്ഷേ ഫലമായുള്ള ടെസ്റ്റ് സെറ്റിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. ഉദാഹരണത്തിന്, പ്രാഥമിക പരീക്ഷണങ്ങൾ DATA_BLOCK_ENCODING പോലെയുള്ള അത്തരം ഒരു പരാമീറ്ററിൻ്റെ അപ്രധാനമായ പ്രാധാന്യം കാണിച്ചു, അത് അയൽ സെല്ലുകളിൽ നിന്നുള്ള മൂല്യങ്ങൾ ഉപയോഗിച്ച് വിവരങ്ങൾ എൻകോഡ് ചെയ്യുന്നു, ഇത് ക്രമരഹിതമായി സൃഷ്ടിച്ച ഡാറ്റയ്ക്ക് മനസ്സിലാക്കാവുന്നതേയുള്ളൂ. നിങ്ങൾ ധാരാളം ഡ്യൂപ്ലിക്കേറ്റ് ഒബ്‌ജക്‌റ്റുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, നേട്ടം ഗണ്യമായിരിക്കാം. പൊതുവേ, എച്ച്‌ബേസ് വളരെ ഗൗരവമേറിയതും നന്നായി ചിന്തിക്കുന്നതുമായ ഒരു ഡാറ്റാബേസിൻ്റെ പ്രതീതി നൽകുന്നുവെന്ന് നമുക്ക് പറയാൻ കഴിയും, ഇത് വലിയ ഡാറ്റാ ബ്ലോക്കുകൾ ഉപയോഗിച്ച് പ്രവർത്തനങ്ങൾ നടത്തുമ്പോൾ അത് വളരെ ഫലപ്രദമായിരിക്കും. വായന, എഴുത്ത് പ്രക്രിയകൾ സമയബന്ധിതമായി വേർതിരിക്കാൻ കഴിയുമെങ്കിൽ പ്രത്യേകിച്ചും.

നിങ്ങളുടെ അഭിപ്രായത്തിൽ വേണ്ടത്ര വെളിപ്പെടുത്താത്ത എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, കൂടുതൽ വിശദമായി നിങ്ങളോട് പറയാൻ ഞാൻ തയ്യാറാണ്. നിങ്ങളുടെ അനുഭവം പങ്കിടാനോ എന്തെങ്കിലും വിയോജിപ്പുണ്ടെങ്കിൽ ചർച്ച ചെയ്യാനോ ഞങ്ങൾ നിങ്ങളെ ക്ഷണിക്കുന്നു.

അവലംബം: www.habr.com