HBase-ൽ നിന്ന് 3 മടങ്ങ് വരെയും HDFS-ൽ നിന്ന് 5 മടങ്ങ് വരെയും എങ്ങനെ വായനാ വേഗത വർദ്ധിപ്പിക്കാം

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


എന്നിരുന്നാലും, മെച്ചപ്പെടുത്തലുകളുടെ സാരാംശത്തിലേക്ക് പോകുന്നതിനുമുമ്പ്, നിങ്ങൾ ഒരു എച്ച്ഡിഡിയിൽ ഇരുന്നാൽ, തത്വത്തിൽ, മറികടക്കാൻ കഴിയാത്ത നിയന്ത്രണങ്ങളെക്കുറിച്ച് സംസാരിക്കുന്നത് മൂല്യവത്താണ്.

എന്തുകൊണ്ട് HDD, ഫാസ്റ്റ് റാൻഡം ആക്സസ് റീഡുകൾ പൊരുത്തപ്പെടുന്നില്ല
നിങ്ങൾക്കറിയാവുന്നതുപോലെ, HBase, കൂടാതെ മറ്റ് പല ഡാറ്റാബേസുകളും, നിരവധി പതിനായിരക്കണക്കിന് കിലോബൈറ്റ് വലുപ്പമുള്ള ബ്ലോക്കുകളിൽ ഡാറ്റ സംഭരിക്കുന്നു. സ്ഥിരസ്ഥിതിയായി ഇത് ഏകദേശം 64 KB ആണ്. ഇനി നമുക്ക് 100 ബൈറ്റുകൾ മാത്രമേ ലഭിക്കൂ എന്ന് സങ്കൽപ്പിക്കുക, ഒരു നിശ്ചിത കീ ഉപയോഗിച്ച് ഈ ഡാറ്റ ഞങ്ങൾക്ക് നൽകാൻ ഞങ്ങൾ HBase-നോട് ആവശ്യപ്പെടുന്നു. HFiles-ലെ ബ്ലോക്ക് വലുപ്പം 64 KB ആയതിനാൽ, അഭ്യർത്ഥന ആവശ്യമുള്ളതിനേക്കാൾ 640 മടങ്ങ് വലുതായിരിക്കും (ഒരു മിനിറ്റ് മാത്രം!).

അടുത്തതായി, അഭ്യർത്ഥന എച്ച്ഡിഎഫ്എസിലൂടെയും അതിന്റെ മെറ്റാഡാറ്റ കാഷിംഗ് മെക്കാനിസത്തിലൂടെയും കടന്നുപോകുന്നതിനാൽ ഷോർട്ട് സർക്യൂട്ട് കാഷെ (ഇത് ഫയലുകളിലേക്ക് നേരിട്ട് പ്രവേശനം അനുവദിക്കുന്നു), ഇത് ഡിസ്കിൽ നിന്ന് ഇതിനകം 1 MB വായിക്കുന്നതിലേക്ക് നയിക്കുന്നു. എന്നിരുന്നാലും, ഇത് പാരാമീറ്റർ ഉപയോഗിച്ച് ക്രമീകരിക്കാവുന്നതാണ് dfs.client.read.shortcircuit.buffer.size കൂടാതെ പല കേസുകളിലും ഈ മൂല്യം കുറയ്ക്കുന്നതിന് അർത്ഥമുണ്ട്, ഉദാഹരണത്തിന് 126 കെ.ബി.

നമ്മൾ ഇത് ചെയ്യുന്നുവെന്ന് പറയുക, എന്നാൽ കൂടാതെ, FileChannel.read പോലുള്ള ഫംഗ്‌ഷനുകൾ പോലെയുള്ള java api വഴി ഡാറ്റ വായിക്കാൻ തുടങ്ങുകയും നിർദ്ദിഷ്ട ഡാറ്റ റീഡ് ചെയ്യാൻ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തോട് ആവശ്യപ്പെടുകയും ചെയ്യുമ്പോൾ, അത് “കേസിൽ” 2 മടങ്ങ് കൂടുതൽ വായിക്കുന്നു. , അതായത്. ഞങ്ങളുടെ കാര്യത്തിൽ 256 കെ.ബി. കാരണം, ഈ സ്വഭാവം തടയാൻ FADV_RANDOM ഫ്ലാഗ് സജ്ജീകരിക്കാൻ ജാവയ്ക്ക് എളുപ്പവഴിയില്ല.

തൽഫലമായി, ഞങ്ങളുടെ 100 ബൈറ്റുകൾ ലഭിക്കുന്നതിന്, 2600 മടങ്ങ് കൂടുതൽ വായിക്കുന്നു. പ്രതിവിധി വ്യക്തമാണെന്ന് തോന്നുന്നു, ബ്ലോക്കിന്റെ വലുപ്പം ഒരു കിലോബൈറ്റിലേക്ക് ചുരുക്കാം, സൂചിപ്പിച്ച പതാക സജ്ജമാക്കി മികച്ച ജ്ഞാനോദയ ത്വരണം നേടാം. പക്ഷേ, ബ്ലോക്ക് സൈസ് 2 മടങ്ങ് കുറയ്ക്കുന്നതിലൂടെ, ഒരു യൂണിറ്റ് സമയത്തിന് വായിക്കുന്ന ബൈറ്റുകളുടെ എണ്ണം ഞങ്ങൾ 2 മടങ്ങ് കുറയ്ക്കുന്നു എന്നതാണ് പ്രശ്‌നം.

FADV_RANDOM ഫ്ലാഗ് സജ്ജീകരിക്കുന്നതിൽ നിന്ന് ചില നേട്ടങ്ങൾ ലഭിക്കും, എന്നാൽ ഉയർന്ന മൾട്ടി-ത്രെഡിംഗും 128 KB ബ്ലോക്ക് വലുപ്പവും മാത്രമേ ലഭിക്കൂ, എന്നാൽ ഇത് പരമാവധി ദശലക്ഷക്കണക്കിന് ശതമാനമാണ്:

100 ഫയലുകളിൽ പരിശോധനകൾ നടത്തി, ഓരോന്നിനും 1 ജിബി വലുപ്പവും 10 എച്ച്ഡിഡികളിൽ സ്ഥിതിചെയ്യുന്നു.

തത്വത്തിൽ, ഈ വേഗതയിൽ നമുക്ക് കണക്കാക്കാൻ കഴിയുന്നത് കണക്കാക്കാം:
നമ്മൾ 10 ഡിസ്കുകളിൽ നിന്ന് 280 MB/sec വേഗതയിൽ വായിച്ചുവെന്ന് പറയാം, അതായത്. 3 ദശലക്ഷം തവണ 100 ബൈറ്റുകൾ. എന്നാൽ നമ്മൾ ഓർക്കുന്നതുപോലെ, നമുക്ക് ആവശ്യമുള്ള ഡാറ്റ വായിക്കുന്നതിനേക്കാൾ 2600 മടങ്ങ് കുറവാണ്. അങ്ങനെ, നമുക്ക് 3 ദശലക്ഷം 2600 കൊണ്ട് ഹരിച്ചാൽ ലഭിക്കും സെക്കൻഡിൽ 1100 റെക്കോർഡുകൾ.

നിരാശാജനകമാണ്, അല്ലേ? അത് സ്വഭാവമാണ് ക്രമരഹിത ആക്സസ് HDD-യിലെ ഡാറ്റയിലേക്കുള്ള ആക്സസ് - ബ്ലോക്ക് വലിപ്പം പരിഗണിക്കാതെ. റാൻഡം ആക്‌സസിന്റെ ഭൗതിക പരിധി ഇതാണ്, അത്തരം സാഹചര്യങ്ങളിൽ ഒരു ഡാറ്റാബേസിനും കൂടുതൽ ചൂഷണം ചെയ്യാൻ കഴിയില്ല.

പിന്നെ എങ്ങനെയാണ് ഡാറ്റാബേസുകൾ വളരെ ഉയർന്ന വേഗത കൈവരിക്കുന്നത്? ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ, ഇനിപ്പറയുന്ന ചിത്രത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കാം:

ആദ്യത്തെ കുറച്ച് മിനിറ്റുകളിൽ വേഗത ശരിക്കും സെക്കൻഡിൽ ആയിരം റെക്കോർഡുകളാണെന്ന് ഇവിടെ നാം കാണുന്നു. എന്നിരുന്നാലും, അഭ്യർത്ഥിച്ചതിനേക്കാൾ കൂടുതൽ വായിക്കപ്പെട്ടതിനാൽ, ഡാറ്റ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ (ലിനക്സ്) ബഫിൽ / കാഷെയിൽ അവസാനിക്കുകയും വേഗത സെക്കൻഡിൽ 60 ആയിരം ആയി വർദ്ധിക്കുകയും ചെയ്യുന്നു.

അതിനാൽ, OS കാഷെയിലുള്ളതോ താരതമ്യപ്പെടുത്താവുന്ന ആക്സസ് വേഗതയുള്ള SSD/NVMe സ്റ്റോറേജ് ഉപകരണങ്ങളിൽ സ്ഥിതി ചെയ്യുന്നതോ ആയ ഡാറ്റയിലേക്കുള്ള ആക്സസ് ത്വരിതപ്പെടുത്തുന്നത് ഞങ്ങൾ കൈകാര്യം ചെയ്യും.

ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾ 4 സെർവറുകളുടെ ഒരു ബെഞ്ചിൽ പരിശോധനകൾ നടത്തും, അവയിൽ ഓരോന്നും ഇനിപ്പറയുന്ന രീതിയിൽ ചാർജ് ചെയ്യുന്നു:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ത്രെഡുകൾ.
മെമ്മറി: 730 ജിബി.
ജാവ പതിപ്പ്: 1.8.0_111

ഇവിടെ പ്രധാന പോയിന്റ് വായിക്കേണ്ട പട്ടികകളിലെ ഡാറ്റയുടെ അളവാണ്. എച്ച്‌ബേസ് കാഷെയിൽ പൂർണ്ണമായി സ്ഥാപിച്ചിരിക്കുന്ന ഒരു ടേബിളിൽ നിന്നുള്ള ഡാറ്റ നിങ്ങൾ വായിക്കുകയാണെങ്കിൽ, അത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ബഫ്/കാഷെയിൽ നിന്ന് വായിക്കാൻ പോലും വരില്ല എന്നതാണ് വസ്തുത. കാരണം, HBase ഡിഫോൾട്ടായി 40% മെമ്മറി BlockCache എന്ന ഘടനയിലേക്ക് നീക്കിവയ്ക്കുന്നു. അടിസ്ഥാനപരമായി ഇതൊരു ConcurrentHashMap ആണ്, ഇവിടെ കീ ഫയലിന്റെ പേര് + ബ്ലോക്കിന്റെ ഓഫ്‌സെറ്റ് ആണ്, മൂല്യം ഈ ഓഫ്‌സെറ്റിലെ യഥാർത്ഥ ഡാറ്റയാണ്.

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

ഉദാഹരണത്തിന്, ഞങ്ങളുടെ കാര്യത്തിൽ, ഒരു RS-ലെ BlockCache ന്റെ അളവ് ഏകദേശം 12 GB ആണ്. ഞങ്ങൾ ഒരു നോഡിൽ രണ്ട് ആർഎസ് ഇറക്കി, അതായത്. എല്ലാ നോഡുകളിലും ബ്ലോക്ക് കാഷെക്കായി 96 GB അനുവദിച്ചിരിക്കുന്നു. കൂടാതെ നിരവധി മടങ്ങ് കൂടുതൽ ഡാറ്റയുണ്ട്, ഉദാഹരണത്തിന്, അത് 4 ടേബിളുകൾ, ഓരോന്നിനും 130 മേഖലകൾ, 800 MB വലുപ്പമുള്ള ഫയലുകൾ, FAST_DIFF ഉപയോഗിച്ച് കംപ്രസ്സുചെയ്‌തിരിക്കട്ടെ, അതായത്. ആകെ 410 GB (ഇത് ശുദ്ധമായ ഡാറ്റയാണ്, അതായത് പകർപ്പെടുക്കൽ ഘടകം കണക്കിലെടുക്കാതെ).

അങ്ങനെ, BlockCache മൊത്തം ഡാറ്റ വോളിയത്തിന്റെ ഏകദേശം 23% മാത്രമാണ്, ഇത് BigData എന്ന് വിളിക്കപ്പെടുന്ന യഥാർത്ഥ അവസ്ഥകളോട് വളരെ അടുത്താണ്. ഇവിടെയാണ് രസം ആരംഭിക്കുന്നത് - കാരണം വ്യക്തമായും, കാഷെ ഹിറ്റുകളുടെ കുറവ്, പ്രകടനം മോശമാണ്. എല്ലാത്തിനുമുപരി, നിങ്ങൾ നഷ്ടപ്പെടുകയാണെങ്കിൽ, നിങ്ങൾ ഒരുപാട് ജോലികൾ ചെയ്യേണ്ടിവരും - അതായത്. സിസ്റ്റം ഫംഗ്‌ഷനുകൾ വിളിക്കുന്നതിലേക്ക് പോകുക. എന്നിരുന്നാലും, ഇത് ഒഴിവാക്കാനാവില്ല, അതിനാൽ നമുക്ക് തികച്ചും വ്യത്യസ്തമായ ഒരു വശം നോക്കാം - കാഷെക്കുള്ളിലെ ഡാറ്റയ്ക്ക് എന്ത് സംഭവിക്കും?

നമുക്ക് സാഹചര്യം ലളിതമാക്കുകയും 1 ഒബ്‌ജക്റ്റിന് മാത്രം അനുയോജ്യമായ ഒരു കാഷെ ഉണ്ടെന്ന് കരുതുകയും ചെയ്യാം. കാഷെയേക്കാൾ 3 മടങ്ങ് വലുപ്പമുള്ള ഒരു ഡാറ്റ വോളിയത്തിൽ പ്രവർത്തിക്കാൻ ശ്രമിക്കുമ്പോൾ എന്ത് സംഭവിക്കും എന്നതിന്റെ ഒരു ഉദാഹരണം ഇതാ, ഞങ്ങൾ ചെയ്യേണ്ടത്:

1. ബ്ലോക്ക് 1 കാഷെയിൽ വയ്ക്കുക
2. കാഷെയിൽ നിന്ന് ബ്ലോക്ക് 1 നീക്കം ചെയ്യുക
3. ബ്ലോക്ക് 2 കാഷെയിൽ വയ്ക്കുക
4. കാഷെയിൽ നിന്ന് ബ്ലോക്ക് 2 നീക്കം ചെയ്യുക
5. ബ്ലോക്ക് 3 കാഷെയിൽ വയ്ക്കുക

5 പ്രവർത്തനങ്ങൾ പൂർത്തിയായി! എന്നിരുന്നാലും, ഈ സാഹചര്യത്തെ സാധാരണമെന്ന് വിളിക്കാൻ കഴിയില്ല; വാസ്തവത്തിൽ, പൂർണ്ണമായും ഉപയോഗശൂന്യമായ ഒരു കൂട്ടം ജോലി ചെയ്യാൻ ഞങ്ങൾ HBase-നെ നിർബന്ധിക്കുകയാണ്. ഇത് OS കാഷെയിൽ നിന്നുള്ള ഡാറ്റ നിരന്തരം വായിക്കുന്നു, അത് ബ്ലോക്ക് കാഷെയിൽ സ്ഥാപിക്കുന്നു, ഡാറ്റയുടെ ഒരു പുതിയ ഭാഗം വന്നതിനാൽ അത് ഉടൻ തന്നെ എറിയുന്നു. പോസ്റ്റിന്റെ തുടക്കത്തിലെ ആനിമേഷൻ പ്രശ്നത്തിന്റെ സാരാംശം കാണിക്കുന്നു - ഗാർബേജ് കളക്ടർ സ്കെയിൽ കുറയുന്നു, അന്തരീക്ഷം ചൂടാകുന്നു, വിദൂരവും ചൂടുള്ളതുമായ സ്വീഡനിലെ ചെറിയ ഗ്രേറ്റ അസ്വസ്ഥനാകുന്നു. കുട്ടികൾ സങ്കടപ്പെടുമ്പോൾ ഞങ്ങൾ ഐടി ആളുകൾക്ക് അത് ശരിക്കും ഇഷ്ടപ്പെടില്ല, അതിനാൽ അതിനെക്കുറിച്ച് നമുക്ക് എന്തുചെയ്യാനാകുമെന്ന് ഞങ്ങൾ ചിന്തിക്കാൻ തുടങ്ങുന്നു.

നിങ്ങൾ കാഷെയിൽ എല്ലാ ബ്ലോക്കുകളും ഇടാതെ, ഒരു നിശ്ചിത ശതമാനം മാത്രം, കാഷെ കവിഞ്ഞൊഴുകുന്നില്ലെങ്കിലോ? BlockCache-ലേക്ക് ഡാറ്റ ഇടുന്നതിനുള്ള ഫംഗ്ഷന്റെ തുടക്കത്തിലേക്ക് കുറച്ച് കോഡ് വരികൾ ചേർത്തുകൊണ്ട് നമുക്ക് ആരംഭിക്കാം:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

ഇവിടെയുള്ള പോയിന്റ് ഇനിപ്പറയുന്നതാണ്: ഫയലിലെ ബ്ലോക്കിന്റെ സ്ഥാനമാണ് ഓഫ്‌സെറ്റ്, അതിന്റെ അവസാന അക്കങ്ങൾ ക്രമരഹിതമായും 00 മുതൽ 99 വരെ തുല്യമായും വിതരണം ചെയ്യപ്പെടുന്നു. അതിനാൽ, നമുക്ക് ആവശ്യമുള്ള ശ്രേണിയിൽ വരുന്നവ മാത്രം ഞങ്ങൾ ഒഴിവാക്കും.

ഉദാഹരണത്തിന്, cacheDataBlockPercent = 20 സജ്ജമാക്കി എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണുക:

ഫലം വ്യക്തമാണ്. ചുവടെയുള്ള ഗ്രാഫുകളിൽ, എന്തുകൊണ്ടാണ് ഇത്തരമൊരു ത്വരണം സംഭവിച്ചതെന്ന് വ്യക്തമാകും - ചൊവ്വയിലെ നായ്ക്കളുടെ അഴുക്കുചാലിലേക്ക് ഉടൻ തന്നെ ഡാറ്റ കാഷെയിൽ സ്ഥാപിക്കുന്ന സിസിഫിയൻ ജോലി ചെയ്യാതെ ഞങ്ങൾ ധാരാളം ജിസി ഉറവിടങ്ങൾ ലാഭിക്കുന്നു:

അതേ സമയം, സിപിയു ഉപയോഗം വർദ്ധിക്കുന്നു, പക്ഷേ ഉൽപ്പാദനക്ഷമതയേക്കാൾ വളരെ കുറവാണ്:

BlockCache-ൽ സംഭരിച്ചിരിക്കുന്ന ബ്ലോക്കുകൾ വ്യത്യസ്തമാണെന്നതും ശ്രദ്ധേയമാണ്. മിക്കതും, ഏകദേശം 95%, ഡാറ്റ തന്നെയാണ്. ബാക്കിയുള്ളത് ബ്ലൂം ഫിൽട്ടറുകൾ അല്ലെങ്കിൽ LEAF_INDEX പോലുള്ള മെറ്റാഡാറ്റയാണ് തുടങ്ങിയവ.. ഈ ഡാറ്റ പര്യാപ്തമല്ല, പക്ഷേ ഇത് വളരെ ഉപയോഗപ്രദമാണ്, കാരണം ഡാറ്റ നേരിട്ട് ആക്‌സസ് ചെയ്യുന്നതിന് മുമ്പ്, ഇവിടെ കൂടുതൽ തിരയേണ്ടതുണ്ടോ എന്നും അങ്ങനെയാണെങ്കിൽ, താൽപ്പര്യത്തിന്റെ ബ്ലോക്ക് കൃത്യമായി എവിടെയാണെന്ന് മനസിലാക്കാൻ HBase മെറ്റായിലേക്ക് തിരിയുന്നു.

അതിനാൽ, കോഡിൽ നമ്മൾ ഒരു ചെക്ക് അവസ്ഥ കാണുന്നു buf.getBlockType().isData() ഈ മെറ്റായ്ക്ക് നന്ദി, ഏത് സാഹചര്യത്തിലും ഞങ്ങൾ ഇത് കാഷെയിൽ വിടും.

ഇപ്പോൾ നമുക്ക് ലോഡ് വർദ്ധിപ്പിക്കാം, ഒറ്റയടിക്ക് ഫീച്ചർ ചെറുതായി ശക്തമാക്കാം. ആദ്യ ടെസ്റ്റിൽ ഞങ്ങൾ കട്ട്ഓഫ് ശതമാനം = 20 ആക്കി, ബ്ലോക്ക് കാഷെ ചെറുതായി ഉപയോഗപ്പെടുത്തിയില്ല. ഇപ്പോൾ നമുക്ക് ഇത് 23% ആയി സജ്ജീകരിച്ച് ഓരോ 100 മിനിറ്റിലും 5 ത്രെഡുകൾ ചേർക്കാം, ഏത് ഘട്ടത്തിലാണ് സാച്ചുറേഷൻ സംഭവിക്കുന്നതെന്ന് കാണാൻ:

യഥാർത്ഥ പതിപ്പ് സെക്കൻഡിൽ ഏകദേശം 100 ആയിരം അഭ്യർത്ഥനകളിൽ ഉടൻ തന്നെ സീലിംഗിലെത്തുന്നത് ഇവിടെ കാണാം. അതേസമയം പാച്ച് 300 ആയിരം വരെ ത്വരണം നൽകുന്നു. അതേ സമയം, കൂടുതൽ ത്വരണം ഇനി "സൌജന്യമല്ല" എന്ന് വ്യക്തമാണ്; സിപിയു ഉപയോഗവും വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണ്.

എന്നിരുന്നാലും, ഇത് വളരെ ഗംഭീരമായ ഒരു പരിഹാരമല്ല, കാരണം എത്ര ശതമാനം ബ്ലോക്കുകൾ കാഷെ ചെയ്യണമെന്ന് ഞങ്ങൾക്ക് മുൻകൂട്ടി അറിയില്ല, ഇത് ലോഡ് പ്രൊഫൈലിനെ ആശ്രയിച്ചിരിക്കുന്നു. അതിനാൽ, വായനാ പ്രവർത്തനങ്ങളുടെ പ്രവർത്തനത്തെ ആശ്രയിച്ച് ഈ പരാമീറ്റർ സ്വയമേവ ക്രമീകരിക്കുന്നതിനുള്ള ഒരു സംവിധാനം നടപ്പിലാക്കി.

ഇത് നിയന്ത്രിക്കാൻ മൂന്ന് ഓപ്ഷനുകൾ ചേർത്തു:

hbase.lru.cache.heavy.eviction.count.limit - ഒപ്റ്റിമൈസേഷൻ (അതായത് ബ്ലോക്കുകൾ ഒഴിവാക്കുക) ഉപയോഗിച്ച് തുടങ്ങുന്നതിന് മുമ്പ് കാഷെയിൽ നിന്ന് ഡാറ്റ എവിക്റ്റ് ചെയ്യുന്ന പ്രക്രിയ എത്ര തവണ പ്രവർത്തിക്കണമെന്ന് സജ്ജീകരിക്കുന്നു. സ്ഥിരസ്ഥിതിയായി ഇത് MAX_INT = 2147483647 ന് തുല്യമാണ്, വാസ്തവത്തിൽ ഈ മൂല്യം ഉപയോഗിച്ച് ഫീച്ചർ പ്രവർത്തിക്കാൻ തുടങ്ങില്ല എന്നാണ്. ഓരോ 5 - 10 സെക്കൻഡിലും (ലോഡിനെ ആശ്രയിച്ചിരിക്കുന്നു) കൂടാതെ 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 വർഷത്തിലും കുടിയൊഴിപ്പിക്കൽ പ്രക്രിയ ആരംഭിക്കുന്നു. എന്നിരുന്നാലും, നമുക്ക് ഈ പാരാമീറ്റർ 0 ആയി സജ്ജീകരിക്കാനും ലോഞ്ച് ചെയ്ത ഉടൻ തന്നെ ഫീച്ചർ പ്രവർത്തനക്ഷമമാക്കാനും കഴിയും.

എന്നിരുന്നാലും, ഈ പരാമീറ്ററിൽ ഒരു പേലോഡും ഉണ്ട്. ഞങ്ങളുടെ ലോഡ് ഹ്രസ്വകാല റീഡുകളും (പകൽ സമയത്ത് പറയുക) ദീർഘകാല വായനകളും (രാത്രിയിൽ) നിരന്തരം ഇടകലരുന്ന തരത്തിലാണെങ്കിൽ, ദൈർഘ്യമേറിയ വായനാ പ്രവർത്തനങ്ങൾ പുരോഗമിക്കുമ്പോൾ മാത്രമേ ഫീച്ചർ ഓണാക്കിയിട്ടുള്ളൂവെന്ന് ഉറപ്പാക്കാൻ കഴിയും.

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

hbase.lru.cache.heavy.eviction.mb.size.limit - 10 സെക്കൻഡിനുള്ളിൽ കാഷെയിൽ എത്ര മെഗാബൈറ്റുകൾ സ്ഥാപിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു (തീർച്ചയായും, പുറത്താക്കുക) സജ്ജമാക്കുന്നു. ഫീച്ചർ ഈ മൂല്യത്തിൽ എത്താനും അത് നിലനിർത്താനും ശ്രമിക്കും. കാര്യം ഇതാണ്: ഞങ്ങൾ കാഷെയിലേക്ക് ജിഗാബൈറ്റുകൾ തള്ളുകയാണെങ്കിൽ, ഞങ്ങൾ ജിഗാബൈറ്റുകൾ പുറത്താക്കേണ്ടിവരും, ഇത് ഞങ്ങൾ മുകളിൽ കണ്ടതുപോലെ വളരെ ചെലവേറിയതാണ്. എന്നിരുന്നാലും, നിങ്ങൾ ഇത് വളരെ ചെറുതായി സജ്ജീകരിക്കാൻ ശ്രമിക്കരുത്, ഇത് ബ്ലോക്ക് സ്‌കിപ്പ് മോഡ് അകാലത്തിൽ പുറത്തുകടക്കാൻ ഇടയാക്കും. ശക്തമായ സെർവറുകൾക്ക് (ഏകദേശം 20-40 ഫിസിക്കൽ കോറുകൾ), ഏകദേശം 300-400 MB സജ്ജമാക്കുന്നത് അനുയോജ്യമാണ്. മധ്യവർഗത്തിന് (~10 കോറുകൾ) 200-300 MB. ദുർബലമായ സിസ്റ്റങ്ങൾക്ക് (2-5 കോറുകൾ) 50-100 MB സാധാരണമായിരിക്കാം (ഇവയിൽ പരീക്ഷിച്ചിട്ടില്ല).

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നമുക്ക് നോക്കാം: ഞങ്ങൾ hbase.lru.cache.heavy.eviction.mb.size.limit = 500 സജ്ജീകരിച്ചുവെന്ന് പറയാം, ഒരു തരത്തിലുള്ള ലോഡ് (വായന) ഉണ്ട്, തുടർന്ന് ഓരോ ~10 സെക്കൻഡിലും എത്ര ബൈറ്റുകൾ ഉണ്ടെന്ന് ഞങ്ങൾ കണക്കാക്കുന്നു. ഫോർമുല ഉപയോഗിച്ച് പുറത്താക്കി:

ഓവർഹെഡ് = ഫ്രീഡ് ബൈറ്റുകൾ സം (MB) * 100 / പരിധി (MB) - 100;

യഥാർത്ഥത്തിൽ 2000 MB പുറത്താക്കിയാൽ, ഓവർഹെഡ് ഇതിന് തുല്യമാണ്:

2000 * 100 / 500 - 100 = 300%

അൽഗോരിതങ്ങൾ ഏതാനും പതിനായിരക്കണക്കിന് ശതമാനത്തിൽ കൂടുതൽ നിലനിർത്താൻ ശ്രമിക്കുന്നു, അതിനാൽ സവിശേഷത കാഷെ ചെയ്ത ബ്ലോക്കുകളുടെ ശതമാനം കുറയ്ക്കും, അതുവഴി ഒരു ഓട്ടോ-ട്യൂണിംഗ് സംവിധാനം നടപ്പിലാക്കും.

എന്നിരുന്നാലും, ലോഡ് കുറയുകയാണെങ്കിൽ, 200 MB മാത്രമേ പുറത്താക്കപ്പെടുകയുള്ളൂവെന്നും ഓവർഹെഡ് നെഗറ്റീവ് ആകുമെന്നും പറയാം (ഓവർഷൂട്ടിംഗ് എന്ന് വിളിക്കപ്പെടുന്നവ):

200 * 100 / 500 - 100 = -60%

നേരെമറിച്ച്, ഓവർഹെഡ് പോസിറ്റീവ് ആകുന്നത് വരെ ഫീച്ചർ കാഷെ ചെയ്ത ബ്ലോക്കുകളുടെ ശതമാനം വർദ്ധിപ്പിക്കും.

യഥാർത്ഥ ഡാറ്റയിൽ ഇത് എങ്ങനെ കാണപ്പെടുന്നു എന്നതിന്റെ ഒരു ഉദാഹരണം ചുവടെയുണ്ട്. 0% എത്താൻ ശ്രമിക്കേണ്ടതില്ല, അത് അസാധ്യമാണ്. ഇത് ഏകദേശം 30 - 100% ആയിരിക്കുമ്പോൾ വളരെ നല്ലതാണ്, ഇത് ഹ്രസ്വകാല കുതിച്ചുചാട്ടങ്ങളിൽ ഒപ്റ്റിമൈസേഷൻ മോഡിൽ നിന്ന് അകാല എക്സിറ്റ് ഒഴിവാക്കാൻ സഹായിക്കുന്നു.

hbase.lru.cache.heavy.eviction.overhead.coficiency - ഫലം എത്ര വേഗത്തിൽ ലഭിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് സജ്ജീകരിക്കുന്നു. ഞങ്ങളുടെ വായനകൾ കൂടുതലും ദൈർഘ്യമേറിയതാണെന്നും കാത്തിരിക്കാൻ ആഗ്രഹിക്കുന്നില്ലെന്നും ഞങ്ങൾക്ക് ഉറപ്പുണ്ടെങ്കിൽ, ഈ അനുപാതം വർദ്ധിപ്പിക്കാനും ഉയർന്ന പ്രകടനം വേഗത്തിൽ നേടാനും കഴിയും.

ഉദാഹരണത്തിന്, ഞങ്ങൾ ഈ ഗുണകം = 0.01 സജ്ജമാക്കി. ഇതിനർത്ഥം ഓവർഹെഡ് (മുകളിൽ കാണുക) ഫലമായുണ്ടാകുന്ന ഫലത്താൽ ഈ സംഖ്യ കൊണ്ട് ഗുണിക്കുകയും കാഷെ ചെയ്ത ബ്ലോക്കുകളുടെ ശതമാനം കുറയുകയും ചെയ്യും. ഓവർഹെഡ് = 300%, കോഫിഫിഷ്യന്റ് = 0.01, അപ്പോൾ കാഷെ ചെയ്ത ബ്ലോക്കുകളുടെ ശതമാനം 3% കുറയുമെന്ന് നമുക്ക് അനുമാനിക്കാം.

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

നടപ്പാക്കൽ കോഡ്

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

ഒരു യഥാർത്ഥ ഉദാഹരണം ഉപയോഗിച്ച് നമുക്ക് ഇപ്പോൾ ഇതെല്ലാം നോക്കാം. ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ടെസ്റ്റ് സ്ക്രിപ്റ്റ് ഉണ്ട്:

1. നമുക്ക് സ്കാൻ ചെയ്യാൻ തുടങ്ങാം (25 ത്രെഡുകൾ, ബാച്ച് = 100)
2. 5 മിനിറ്റിനു ശേഷം, മൾട്ടി-ഗെറ്റുകൾ ചേർക്കുക (25 ത്രെഡുകൾ, ബാച്ച് = 100)
3. 5 മിനിറ്റിന് ശേഷം, മൾട്ടി-ഗെറ്റുകൾ ഓഫാക്കുക (സ്‌കാൻ മാത്രം ശേഷിക്കുന്നു)

ഞങ്ങൾ രണ്ട് റൺസ് ചെയ്യുന്നു, ആദ്യം hbase.lru.cache.heavy.eviction.count.limit = 10000 (അത് യഥാർത്ഥത്തിൽ സവിശേഷതയെ പ്രവർത്തനരഹിതമാക്കുന്നു), തുടർന്ന് പരിധി = 0 സജ്ജമാക്കുക (ഇത് പ്രവർത്തനക്ഷമമാക്കുന്നു).

ഫീച്ചർ എങ്ങനെ ഓണാക്കിയെന്നും ഓവർഷൂട്ടിംഗ് 14-71% ആയി പുനഃസജ്ജമാക്കുന്നത് എങ്ങനെയെന്നും ചുവടെയുള്ള ലോഗുകളിൽ കാണാം. കാലാകാലങ്ങളിൽ ലോഡ് കുറയുന്നു, ഇത് ബാക്ക്പ്രഷർ ഓണാക്കുന്നു, HBase വീണ്ടും കൂടുതൽ ബ്ലോക്കുകൾ കാഷെ ചെയ്യുന്നു.

Log RegionServer
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 0, അനുപാതം 0.0, ഓവർഹെഡ് (%): -100, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 0, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 100
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 0, അനുപാതം 0.0, ഓവർഹെഡ് (%): -100, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 0, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 100
പുറത്താക്കപ്പെട്ട (MB): 2170, അനുപാതം 1.09, ഓവർഹെഡ് (%): 985, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 1, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 91 <ആരംഭിക്കുക
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 3763, അനുപാതം 1.08, ഓവർഹെഡ് (%): 1781, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 2, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 76
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 3306, അനുപാതം 1.07, ഓവർഹെഡ് (%): 1553, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 3, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 61
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 2508, അനുപാതം 1.06, ഓവർഹെഡ് (%): 1154, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 4, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 50
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 1824, അനുപാതം 1.04, ഓവർഹെഡ് (%): 812, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 5, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 42
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 1482, അനുപാതം 1.03, ഓവർഹെഡ് (%): 641, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 6, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 36
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 1140, അനുപാതം 1.01, ഓവർഹെഡ് (%): 470, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 7, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 32
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 913, അനുപാതം 1.0, ഓവർഹെഡ് (%): 356, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 8, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 29
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 912, അനുപാതം 0.89, ഓവർഹെഡ് (%): 356, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 9, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 26
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 684, അനുപാതം 0.76, ഓവർഹെഡ് (%): 242, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 10, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 24
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 684, അനുപാതം 0.61, ഓവർഹെഡ് (%): 242, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 11, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.51, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 12, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 21
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.42, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 13, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 20
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.33, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 14, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 15, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.32, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 16, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.31, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 17, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.3, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 18, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.29, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 19, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.27, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 20, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.25, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 21, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.24, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 22, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.22, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 23, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.21, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 24, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.2, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 25, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.17, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 26, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.17, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 27, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18 < ചേർത്തു (എന്നാൽ പട്ടിക അത് തന്നെ)
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.15, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 28, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.13, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 29, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.11, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 30, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.09, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 31, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.08, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 32, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.07, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 33, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.06, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 34, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.05, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 35, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.05, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 36, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.04, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 37, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 109, അനുപാതം 0.04, ഓവർഹെഡ് (%): -46, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 37, കറന്റ് കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22 < ബാക്ക് പ്രഷർ
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 798, അനുപാതം 0.24, ഓവർഹെഡ് (%): 299, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 38, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 20
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 798, അനുപാതം 0.29, ഓവർഹെഡ് (%): 299, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 39, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 570, അനുപാതം 0.27, ഓവർഹെഡ് (%): 185, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 40, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 17
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.22, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 41, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.16, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 42, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.11, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 43, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.09, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 44, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.07, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 45, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.05, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 46, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 222, അനുപാതം 0.04, ഓവർഹെഡ് (%): 11, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 47, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 16
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 104, അനുപാതം 0.03, ഓവർഹെഡ് (%): -48, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 47, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 21 < തടസ്സം ലഭിക്കുന്നു
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 684, അനുപാതം 0.2, ഓവർഹെഡ് (%): 242, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 48, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 19
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 570, അനുപാതം 0.23, ഓവർഹെഡ് (%): 185, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 49, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.22, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 50, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.21, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 51, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.2, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 52, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.18, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 53, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.16, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 54, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 228, അനുപാതം 0.14, ഓവർഹെഡ് (%): 14, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 55, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 18
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 112, അനുപാതം 0.14, ഓവർഹെഡ് (%): -44, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 55, കറന്റ് കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 23 < ബാക്ക് പ്രഷർ
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 456, അനുപാതം 0.26, ഓവർഹെഡ് (%): 128, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 56, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.31, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 57, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 58, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 59, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 60, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 61, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 62, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 63, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.32, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 64, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 65, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 66, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.32, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 67, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 68, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.32, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 69, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.32, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 70, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 71, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 72, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 73, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 74, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 75, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 342, അനുപാതം 0.33, ഓവർഹെഡ് (%): 71, ഹെവി എവിക്ഷൻ കൗണ്ടർ: 76, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 22
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 21, അനുപാതം 0.33, ഓവർഹെഡ് (%): -90, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 76, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 32
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 0, അനുപാതം 0.0, ഓവർഹെഡ് (%): -100, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 0, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 100
കുടിയൊഴിപ്പിക്കപ്പെട്ടു (MB): 0, അനുപാതം 0.0, ഓവർഹെഡ് (%): -100, ഹെവി എവിക്ഷൻ കൌണ്ടർ: 0, നിലവിലെ കാഷിംഗ് ഡാറ്റാബ്ലോക്ക് (%): 100

രണ്ട് കാഷെ വിഭാഗങ്ങൾ തമ്മിലുള്ള ബന്ധത്തിന്റെ ഗ്രാഫ് രൂപത്തിൽ സമാന പ്രക്രിയ കാണിക്കാൻ സ്കാനുകൾ ആവശ്യമായിരുന്നു - സിംഗിൾ (ഇതുവരെ അഭ്യർത്ഥിച്ചിട്ടില്ലാത്ത ബ്ലോക്കുകൾ), മൾട്ടി (ഒരിക്കലെങ്കിലും "അഭ്യർത്ഥിച്ച" ഡാറ്റ ഇവിടെ സംഭരിച്ചിരിക്കുന്നു):

അവസാനമായി, പാരാമീറ്ററുകളുടെ പ്രവർത്തനം ഒരു ഗ്രാഫിന്റെ രൂപത്തിൽ എങ്ങനെയിരിക്കും. താരതമ്യത്തിനായി, തുടക്കത്തിൽ കാഷെ പൂർണ്ണമായും ഓഫാക്കി, തുടർന്ന് HBase കാഷിംഗ് ഉപയോഗിച്ച് സമാരംഭിക്കുകയും ഒപ്റ്റിമൈസേഷൻ ജോലിയുടെ ആരംഭം 5 മിനിറ്റ് വൈകിപ്പിക്കുകയും ചെയ്തു (30 എവിക്ഷൻ സൈക്കിളുകൾ).

പുൾ അഭ്യർത്ഥനയിൽ മുഴുവൻ കോഡും കാണാം HBASE 23887 ഗിത്തബിൽ.

എന്നിരുന്നാലും, ഈ സാഹചര്യങ്ങളിൽ ഈ ഹാർഡ്‌വെയറിൽ നേടാനാകുന്നതെല്ലാം സെക്കൻഡിൽ 300 ആയിരം റീഡുകളല്ല. നിങ്ങൾക്ക് HDFS വഴി ഡാറ്റ ആക്‌സസ് ചെയ്യേണ്ടിവരുമ്പോൾ, നെറ്റ്‌വർക്ക് ഇടപെടലുകൾ ഒഴിവാക്കിക്കൊണ്ട് ഡാറ്റ നേരിട്ട് ആക്‌സസ് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന ShortCircuitCache (ഇനിമുതൽ SSC എന്ന് വിളിക്കുന്നു) മെക്കാനിസം ഉപയോഗിക്കുന്നു എന്നതാണ് വസ്തുത.

പ്രൊഫൈലിംഗ് കാണിക്കുന്നത് ഈ സംവിധാനം ഒരു വലിയ നേട്ടം നൽകുന്നുണ്ടെങ്കിലും, ഒരു ഘട്ടത്തിൽ ഇത് ഒരു തടസ്സമായി മാറുകയും ചെയ്യുന്നു, കാരണം മിക്കവാറും എല്ലാ കനത്ത പ്രവർത്തനങ്ങളും ഒരു ലോക്കിനുള്ളിൽ സംഭവിക്കുന്നു, ഇത് മിക്ക സമയത്തും തടയുന്നതിലേക്ക് നയിക്കുന്നു.

ഇത് മനസ്സിലാക്കിയ ശേഷം, സ്വതന്ത്ര എസ്എസ്‌സികളുടെ ഒരു നിര സൃഷ്‌ടിക്കുന്നതിലൂടെ പ്രശ്‌നം മറികടക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

അവസാന ഓഫ്‌സെറ്റ് അക്കത്തിലെ കവലകൾ ഒഴികെ അവരോടൊപ്പം പ്രവർത്തിക്കുക:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

ഇപ്പോൾ നിങ്ങൾക്ക് പരിശോധന ആരംഭിക്കാം. ഇത് ചെയ്യുന്നതിന്, ലളിതമായ മൾട്ടി-ത്രെഡഡ് ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച് HDFS-ൽ നിന്നുള്ള ഫയലുകൾ ഞങ്ങൾ വായിക്കും. പാരാമീറ്ററുകൾ സജ്ജമാക്കുക:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

ഫയലുകൾ വായിക്കുക:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

ഈ കോഡ് പ്രത്യേക ത്രെഡുകളിൽ എക്സിക്യൂട്ട് ചെയ്യുന്നു, ഞങ്ങൾ ഒരേസമയം വായിക്കുന്ന ഫയലുകളുടെ എണ്ണം (10 മുതൽ 200 വരെ - തിരശ്ചീന അക്ഷം), കാഷെകളുടെ എണ്ണം (1 മുതൽ 10 വരെ - ഗ്രാഫിക്സ്) വർദ്ധിപ്പിക്കും. ഒരു കാഷെ ഉള്ളപ്പോൾ കേസുമായി ബന്ധപ്പെട്ട് എസ്എസ്‌സിയുടെ വർദ്ധനവിന്റെ ഫലമായുണ്ടാകുന്ന ത്വരണം ലംബ അക്ഷം കാണിക്കുന്നു.

ഗ്രാഫ് എങ്ങനെ വായിക്കാം: ഒരു കാഷെ ഉപയോഗിച്ച് 100 കെബി ബ്ലോക്കുകളിൽ 64 ​​ആയിരം റീഡുകളുടെ എക്സിക്യൂഷൻ സമയം 78 സെക്കൻഡ് ആവശ്യമാണ്. അതേസമയം 5 കാഷെകളിൽ 16 സെക്കൻഡ് എടുക്കും. ആ. ~5 മടങ്ങ് ത്വരണം ഉണ്ട്. ഗ്രാഫിൽ നിന്ന് കാണാൻ കഴിയുന്നതുപോലെ, ഒരു ചെറിയ എണ്ണം സമാന്തര വായനകൾക്ക് പ്രഭാവം വളരെ ശ്രദ്ധേയമല്ല; 50-ലധികം ത്രെഡ് റീഡുകൾ ഉള്ളപ്പോൾ ഇത് ശ്രദ്ധേയമായ പങ്ക് വഹിക്കാൻ തുടങ്ങുന്നു. എസ്എസ്‌സികളുടെ എണ്ണം 6 ൽ നിന്ന് വർദ്ധിക്കുന്നതും ശ്രദ്ധേയമാണ്. അതിനുമുകളിൽ കാര്യമായ ചെറിയ പ്രകടന വർദ്ധനവ് നൽകുന്നു.

കുറിപ്പ് 1: പരിശോധനാ ഫലങ്ങൾ വളരെ അസ്ഥിരമായതിനാൽ (ചുവടെ കാണുക), 3 റൺസ് നടത്തുകയും ഫലമായുണ്ടാകുന്ന മൂല്യങ്ങൾ ശരാശരി കണക്കാക്കുകയും ചെയ്തു.

കുറിപ്പ് 2: ക്രമരഹിതമായ ആക്‌സസ് കോൺഫിഗർ ചെയ്യുന്നതിൽ നിന്നുള്ള പ്രകടന നേട്ടം ഒന്നുതന്നെയാണ്, ആക്‌സസ് തന്നെ അൽപ്പം മന്ദഗതിയിലാണെങ്കിലും.

എന്നിരുന്നാലും, HBase-ൽ നിന്ന് വ്യത്യസ്തമായി, ഈ ത്വരണം എല്ലായ്പ്പോഴും സൗജന്യമല്ലെന്ന് വ്യക്തമാക്കേണ്ടത് ആവശ്യമാണ്. ലോക്കുകളിൽ തൂങ്ങിക്കിടക്കുന്നതിനുപകരം കൂടുതൽ ജോലി ചെയ്യാനുള്ള സിപിയുവിന്റെ കഴിവ് ഞങ്ങൾ ഇവിടെ "അൺലോക്ക്" ചെയ്യുന്നു.

പൊതുവേ, കാഷെകളുടെ എണ്ണത്തിലെ വർദ്ധനവ് സിപിയു ഉപയോഗത്തിൽ ഏകദേശം ആനുപാതികമായ വർദ്ധനവ് നൽകുന്നതായി ഇവിടെ നിങ്ങൾക്ക് നിരീക്ഷിക്കാനാകും. എന്നിരുന്നാലും, അല്പം കൂടുതൽ വിജയിക്കുന്ന കോമ്പിനേഷനുകൾ ഉണ്ട്.

ഉദാഹരണത്തിന്, നമുക്ക് SSC = 3 എന്ന ക്രമീകരണം സൂക്ഷ്മമായി പരിശോധിക്കാം. ശ്രേണിയിലെ പ്രകടനത്തിലെ വർദ്ധനവ് ഏകദേശം 3.3 മടങ്ങാണ്. മൂന്ന് വ്യത്യസ്ത റണ്ണുകളിൽ നിന്നുള്ള ഫലങ്ങൾ ചുവടെയുണ്ട്.

അതേസമയം സിപിയു ഉപഭോഗം ഏകദേശം 2.8 മടങ്ങ് വർദ്ധിക്കുന്നു. വ്യത്യാസം വളരെ വലുതല്ല, പക്ഷേ ചെറിയ ഗ്രേറ്റ ഇതിനകം സന്തോഷവതിയാണ്, കൂടാതെ സ്കൂളിൽ പോകാനും പാഠങ്ങൾ പഠിക്കാനും സമയമുണ്ടായേക്കാം.

അതിനാൽ, ആപ്ലിക്കേഷൻ കോഡ് ഭാരം കുറഞ്ഞതും (അതായത് പ്ലഗ് എച്ച്ഡിഎഫ്എസ് ക്ലയന്റ് വശത്താണ്) സൗജന്യ സിപിയു പവറും ഉണ്ടെങ്കിൽ, HDFS-ലേക്ക് ബൾക്ക് ആക്‌സസ് ഉപയോഗിക്കുന്ന ഏതൊരു ഉപകരണത്തിനും ഇത് നല്ല ഫലം നൽകും (ഉദാഹരണത്തിന് സ്പാർക്ക് മുതലായവ). . പരിശോധിക്കുന്നതിന്, HBase-ൽ നിന്നുള്ള വായനയ്ക്കായി BlockCache ഒപ്റ്റിമൈസേഷന്റെയും SSC ട്യൂണിംഗിന്റെയും സംയോജിത ഉപയോഗം എന്ത് ഫലമുണ്ടാക്കുമെന്ന് പരിശോധിക്കാം.

അത്തരം സാഹചര്യങ്ങളിൽ, ശുദ്ധീകരിച്ച പരിശോധനകളിൽ (ഒരു പ്രോസസ്സിംഗും കൂടാതെ വായന) പ്രഭാവം അത്ര മികച്ചതല്ലെന്ന് കാണാൻ കഴിയും, എന്നാൽ ഇവിടെ അധികമായി 80K ചൂഷണം ചെയ്യുന്നത് തികച്ചും സാദ്ധ്യമാണ്. രണ്ട് ഒപ്റ്റിമൈസേഷനുകളും ഒരുമിച്ച് 4x വേഗത നൽകുന്നു.

ഈ ഒപ്റ്റിമൈസേഷനായി ഒരു പിആർ ഉണ്ടാക്കി [HDFS-15202], ഇത് ലയിപ്പിച്ചിരിക്കുന്നു, ഈ പ്രവർത്തനം ഭാവി റിലീസുകളിൽ ലഭ്യമാകും.

അവസാനമായി, സമാനമായ വൈഡ് കോളം ഡാറ്റാബേസ്, കസാന്ദ്ര, എച്ച്ബേസ് എന്നിവയുടെ വായനാ പ്രകടനം താരതമ്യം ചെയ്യുന്നത് രസകരമായിരുന്നു.

ഇത് ചെയ്യുന്നതിന്, രണ്ട് ഹോസ്റ്റുകളിൽ നിന്ന് സ്റ്റാൻഡേർഡ് YCSB ലോഡ് ടെസ്റ്റിംഗ് യൂട്ടിലിറ്റിയുടെ ഉദാഹരണങ്ങൾ ഞങ്ങൾ സമാരംഭിച്ചു (ആകെ 800 ത്രെഡുകൾ). സെർവർ ഭാഗത്ത് - 4 ഹോസ്റ്റുകളിൽ RegionServer, Cassandra എന്നിവയുടെ 4 സംഭവങ്ങൾ (അവരുടെ സ്വാധീനം ഒഴിവാക്കാൻ ക്ലയന്റുകൾ പ്രവർത്തിക്കുന്ന സ്ഥലങ്ങളല്ല). വലുപ്പത്തിലുള്ള പട്ടികകളിൽ നിന്നാണ് വായനകൾ വന്നത്:

HBase - HDFS-ൽ 300 GB (100 GB ശുദ്ധമായ ഡാറ്റ)

കസാന്ദ്ര - 250 GB (റെപ്ലിക്കേഷൻ ഘടകം = 3)

ആ. വോളിയം ഏകദേശം സമാനമായിരുന്നു (HBase-ൽ കുറച്ചുകൂടി).

HBase പാരാമീറ്ററുകൾ:

dfs.client.short.circuit.num = 5 (HDFS ക്ലയന്റ് ഒപ്റ്റിമൈസേഷൻ)

hbase.lru.cache.heavy.eviction.count.limit = 30 - ഇതിനർത്ഥം 30 കുടിയൊഴിപ്പിക്കലുകൾക്ക് ശേഷം പാച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങും (~5 മിനിറ്റ്)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - കാഷിംഗിന്റെയും കുടിയൊഴിപ്പിക്കലിന്റെയും ലക്ഷ്യം

YCSB ലോഗുകൾ പാഴ്‌സ് ചെയ്യുകയും Excel ഗ്രാഫുകളിലേക്ക് കംപൈൽ ചെയ്യുകയും ചെയ്തു:

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഈ വ്യവസ്ഥകളിൽ ഈ ഡാറ്റാബേസുകളുടെ പ്രകടനം താരതമ്യം ചെയ്യാനും സെക്കൻഡിൽ 450 ആയിരം റീഡുകൾ നേടാനും ഈ ഒപ്റ്റിമൈസേഷനുകൾ സാധ്യമാക്കുന്നു.

ഉൽ‌പാദനക്ഷമതയ്‌ക്കായുള്ള ആവേശകരമായ പോരാട്ടത്തിൽ ഈ വിവരങ്ങൾ ആർക്കെങ്കിലും ഉപയോഗപ്രദമാകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

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