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

പഴയ സ്കൂൾ രീതികൾ, ബ്രൂട്ട് ഫോഴ്‌സ് സമീപനം, അനാവശ്യ ലെയറുകൾ ഒഴിവാക്കി സങ്കീർണ്ണമായ ഡാറ്റാ ഘടനകൾ ഒഴിവാക്കൽ എന്നിവയിലൂടെ സ്‌കാലൈറിൽ ഞങ്ങൾ ഈ പ്രശ്നം എങ്ങനെ പരിഹരിച്ചുവെന്ന് ഈ ലേഖനം വിവരിക്കുന്നു. നിങ്ങളുടെ സ്വന്തം എഞ്ചിനീയറിംഗ് പ്രശ്നങ്ങൾക്ക് ഈ പാഠങ്ങൾ പ്രയോഗിക്കാവുന്നതാണ്.

പഴയ സ്കൂൾ ശക്തി

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

ലളിതവും ലളിതവുമായ പ്രവർത്തനങ്ങളിൽ ആധുനിക പ്രോസസറുകൾ വളരെ വേഗത്തിലാണെന്നതാണ് പ്രധാന ഉൾക്കാഴ്ച. I/O വേഗതയെയും നെറ്റ്‌വർക്ക് പ്രവർത്തനങ്ങളെയും ആശ്രയിക്കുന്ന സങ്കീർണ്ണമായ മൾട്ടി-ലെയർ സിസ്റ്റങ്ങളിൽ ഇത് നഷ്‌ടമാകുന്നത് എളുപ്പമാണ്, അത്തരം സിസ്റ്റങ്ങൾ ഇന്ന് വളരെ സാധാരണമാണ്. അതിനാൽ പാളികളും അധിക അവശിഷ്ടങ്ങളും കുറയ്ക്കുന്ന ഒരു ഡിസൈൻ ഞങ്ങൾ വികസിപ്പിച്ചെടുത്തു. ഒന്നിലധികം പ്രോസസറുകളും സെർവറുകളും സമാന്തരമായി, തിരയൽ വേഗത സെക്കൻഡിൽ 1 TB എത്തുന്നു.

ഈ ലേഖനത്തിൽ നിന്നുള്ള പ്രധാന കാര്യങ്ങൾ:

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

(ഈ ലേഖനം മെമ്മറിയിൽ ഡാറ്റ തിരയുന്നത് വിവരിക്കുന്നു. മിക്ക കേസുകളിലും, ഒരു ഉപയോക്താവ് ഒരു ലോഗ് തിരയൽ നടത്തുമ്പോൾ, Scalyr സെർവറുകൾ ഇതിനകം തന്നെ അത് കാഷെ ചെയ്‌തിട്ടുണ്ട്. അടുത്ത ലേഖനം കാഷെ ചെയ്യാത്ത ലോഗുകൾക്കായി തിരയുന്നതിനെ കുറിച്ച് ചർച്ച ചെയ്യും. അതേ തത്ത്വങ്ങൾ ബാധകമാണ്: കാര്യക്ഷമമായ കോഡ്, ബ്രൂട്ട് ഫോഴ്‌സ് വലിയ കമ്പ്യൂട്ടേഷണൽ ഉറവിടങ്ങൾക്കൊപ്പം).

ബ്രൂട്ട് ഫോഴ്സ് രീതി

പരമ്പരാഗതമായി, ഒരു വലിയ ഡാറ്റ സെറ്റ് ഒരു കീവേഡ് സൂചിക ഉപയോഗിച്ച് തിരയുന്നു. സെർവർ ലോഗുകളിൽ പ്രയോഗിക്കുമ്പോൾ, ലോഗിലെ ഓരോ തനതായ വാക്കും തിരയുക എന്നാണ് ഇതിനർത്ഥം. ഓരോ വാക്കിനും, നിങ്ങൾ എല്ലാ ഉൾപ്പെടുത്തലുകളുടെയും ഒരു ലിസ്റ്റ് ഉണ്ടാക്കേണ്ടതുണ്ട്. ഈ വാക്ക് ഉപയോഗിച്ച് എല്ലാ സന്ദേശങ്ങളും കണ്ടെത്തുന്നത് ഇത് എളുപ്പമാക്കുന്നു, ഉദാഹരണത്തിന് 'പിശക്', 'ഫയർഫോക്സ്' അല്ലെങ്കിൽ "ട്രാൻസക്ഷൻ_16851951" - സൂചികയിൽ നോക്കുക.

ഞാൻ Google-ൽ ഈ സമീപനം ഉപയോഗിച്ചു, അത് നന്നായി പ്രവർത്തിച്ചു. എന്നാൽ Scalyr ൽ നമ്മൾ ലോഗുകൾ ബൈറ്റ് ബൈറ്റ് ആയി തിരയുന്നു.

എന്തുകൊണ്ട്? ഒരു അമൂർത്തമായ അൽഗോരിതം വീക്ഷണത്തിൽ, കീവേഡ് സൂചികകൾ ബ്രൂട്ട് ഫോഴ്‌സ് തിരയലുകളേക്കാൾ വളരെ കാര്യക്ഷമമാണ്. എന്നിരുന്നാലും, ഞങ്ങൾ അൽഗോരിതങ്ങൾ വിൽക്കുന്നില്ല, പ്രകടനമാണ് ഞങ്ങൾ വിൽക്കുന്നത്. പ്രകടനം അൽഗോരിതം മാത്രമല്ല, സിസ്റ്റം എഞ്ചിനീയറിംഗും കൂടിയാണ്. ഞങ്ങൾ എല്ലാം പരിഗണിക്കണം: ഡാറ്റയുടെ അളവ്, തിരയലിന്റെ തരം, ലഭ്യമായ ഹാർഡ്‌വെയർ, സോഫ്റ്റ്‌വെയർ സന്ദർഭം. ഞങ്ങളുടെ പ്രത്യേക പ്രശ്‌നത്തിന്, ഒരു സൂചികയേക്കാൾ 'ഗ്രെപ്പ്' പോലെയുള്ള ഒന്ന് അനുയോജ്യമാണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു.

സൂചികകൾ മികച്ചതാണ്, പക്ഷേ അവയ്ക്ക് പരിമിതികളുണ്ട്. ഒരു വാക്ക് കണ്ടെത്താൻ എളുപ്പമാണ്. എന്നാൽ 'googlebot', '404' എന്നിങ്ങനെ ഒന്നിലധികം വാക്കുകളുള്ള സന്ദേശങ്ങൾ തിരയുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്. 'പിടിക്കപ്പെടാത്ത അപവാദം' പോലെയുള്ള ഒരു വാക്യത്തിനായി തിരയുന്നതിന്, ആ വാക്കിനൊപ്പം എല്ലാ സന്ദേശങ്ങളും മാത്രമല്ല, വാക്കിന്റെ നിർദ്ദിഷ്ട സ്ഥാനവും രേഖപ്പെടുത്തുന്ന കൂടുതൽ ബുദ്ധിമുട്ടുള്ള ഒരു സൂചിക ആവശ്യമാണ്.

നിങ്ങൾ വാക്കുകൾക്കായി തിരയാതിരിക്കുമ്പോഴാണ് യഥാർത്ഥ ബുദ്ധിമുട്ട് വരുന്നത്. ബോട്ടുകളിൽ നിന്ന് എത്ര ട്രാഫിക്കാണ് വരുന്നതെന്ന് നിങ്ങൾക്ക് കാണണമെന്ന് പറയാം. ബോട്ട് എന്ന വാക്കിനായി ലോഗുകൾ തിരയുക എന്നതാണ് ആദ്യത്തെ ചിന്ത. ഇങ്ങനെയാണ് നിങ്ങൾ ചില ബോട്ടുകൾ കണ്ടെത്തുന്നത്: Googlebot, Bingbot എന്നിവയും മറ്റു പലതും. എന്നാൽ ഇവിടെ 'ബോട്ട്' എന്നത് ഒരു വാക്കല്ല, അതിന്റെ ഭാഗമാണ്. സൂചികയിൽ 'bot' എന്ന് തിരഞ്ഞാൽ, 'Googlebot' എന്ന വാക്ക് ഉള്ള പോസ്റ്റുകളൊന്നും നമുക്ക് കാണാനാകില്ല. നിങ്ങൾ സൂചികയിലെ എല്ലാ വാക്കും പരിശോധിച്ച്, കണ്ടെത്തിയ കീവേഡുകൾക്കായി സൂചിക സ്കാൻ ചെയ്താൽ, തിരയൽ വളരെ മന്ദഗതിയിലാകും. തൽഫലമായി, ചില ലോഗ് പ്രോഗ്രാമുകൾ പാർട്ട് വേഡ് തിരയലുകൾ അനുവദിക്കുന്നില്ല അല്ലെങ്കിൽ (മികച്ചത്) കുറഞ്ഞ പ്രകടനമുള്ള പ്രത്യേക വാക്യഘടനയെ അനുവദിക്കുന്നില്ല. ഇത് ഒഴിവാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

വിരാമചിഹ്നമാണ് മറ്റൊരു പ്രശ്നം. എന്നതിൽ നിന്നുള്ള എല്ലാ അഭ്യർത്ഥനകളും കണ്ടെത്താൻ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടോ 50.168.29.7? ലോഗുകൾ അടങ്ങിയ ഡീബഗ്ഗിംഗ് സംബന്ധിച്ചെന്ത് [error]? സബ്‌സ്‌ക്രിപ്റ്റുകൾ സാധാരണയായി വിരാമചിഹ്നങ്ങൾ ഒഴിവാക്കുന്നു.

അവസാനമായി, എഞ്ചിനീയർമാർ ശക്തമായ ഉപകരണങ്ങളെ ഇഷ്ടപ്പെടുന്നു, ചിലപ്പോൾ ഒരു സാധാരണ പദപ്രയോഗത്തിലൂടെ മാത്രമേ ഒരു പ്രശ്നം പരിഹരിക്കാൻ കഴിയൂ. കീവേഡ് സൂചിക ഇതിന് വളരെ അനുയോജ്യമല്ല.

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

കീവേഡ് സൂചികകളും ധാരാളം ഇടം എടുക്കുന്നു, കൂടാതെ ഒരു ലോഗ് മാനേജ്മെന്റ് സിസ്റ്റത്തിൽ സംഭരണം ഒരു പ്രധാന ചെലവാണ്.

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

നിങ്ങൾക്ക് ഒരു ക്രൂരമായ പ്രശ്‌നമുണ്ടെങ്കിൽ (കൂടുതൽ ശക്തിയും) ബ്രൂട്ട് ഫോഴ്‌സ് പ്രവർത്തിക്കുന്നു

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

ഞങ്ങളുടെ തിരയൽ കോഡിന് യഥാർത്ഥത്തിൽ സാമാന്യം വലിയ ആന്തരിക ലൂപ്പ് ഉണ്ടായിരുന്നു. ഞങ്ങൾ 4K-ൽ പേജുകളിൽ സന്ദേശങ്ങൾ സംഭരിക്കുന്നു; ഓരോ പേജിലും ചില സന്ദേശങ്ങളും (UTF-8 ൽ) ഓരോ സന്ദേശത്തിനും മെറ്റാഡാറ്റയും അടങ്ങിയിരിക്കുന്നു. മൂല്യത്തിന്റെ ദൈർഘ്യം, ആന്തരിക സന്ദേശ ഐഡി, മറ്റ് ഫീൽഡുകൾ എന്നിവ എൻകോഡ് ചെയ്യുന്ന ഒരു ഘടനയാണ് മെറ്റാഡാറ്റ. തിരയൽ സൈക്കിൾ ഇതുപോലെ കാണപ്പെട്ടു:

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

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

തുടക്കത്തിൽ, അത്തരം കോഡ് ബ്രൂട്ട് ഫോഴ്സ് ഒപ്റ്റിമൈസേഷന് അത്ര അനുയോജ്യമല്ലെന്ന് തോന്നി. "യഥാർത്ഥ ജോലി" ൽ String.indexOf() സിപിയു പ്രൊഫൈലിൽ പോലും ആധിപത്യം പുലർത്തിയില്ല. അതായത്, ഈ രീതി ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് മാത്രം കാര്യമായ ഫലം നൽകില്ല.

ഓരോ പേജിന്റെയും തുടക്കത്തിൽ ഞങ്ങൾ മെറ്റാഡാറ്റ സംഭരിക്കുന്നു, UTF-8 ലെ എല്ലാ സന്ദേശങ്ങളുടെയും വാചകം മറ്റേ അറ്റത്ത് പാക്ക് ചെയ്തിരിക്കുന്നു. ഇത് പ്രയോജനപ്പെടുത്തി, മുഴുവൻ പേജും ഒരേസമയം തിരയുന്നതിനായി ഞങ്ങൾ ലൂപ്പ് വീണ്ടും എഴുതി:

ഈ പതിപ്പ് കാഴ്ചയിൽ നേരിട്ട് പ്രവർത്തിക്കുന്നു raw byte[] കൂടാതെ 4K പേജിലുടനീളം എല്ലാ സന്ദേശങ്ങളും ഒരേസമയം തിരയുന്നു.

ബ്രൂട്ട് ഫോഴ്സ് രീതി ഒപ്റ്റിമൈസ് ചെയ്യാൻ ഇത് വളരെ എളുപ്പമാണ്. ആന്തരിക തിരയൽ ലൂപ്പിനെ ഓരോ പോസ്റ്റിലും വെവ്വേറെ വിളിക്കുന്നതിനുപകരം മുഴുവൻ 4K പേജിനും ഒരേസമയം വിളിക്കുന്നു. ഡാറ്റ പകർത്തുന്നില്ല, ഒബ്‌ജക്‌റ്റുകൾ അനുവദിക്കുന്നില്ല. കൂടുതൽ സങ്കീർണ്ണമായ മെറ്റാഡാറ്റ പ്രവർത്തനങ്ങൾ ഫലം പോസിറ്റീവ് ആയിരിക്കുമ്പോൾ മാത്രമേ വിളിക്കൂ, എല്ലാ സന്ദേശങ്ങളിലും അല്ല. ഈ രീതിയിൽ ഞങ്ങൾ ഒരു ടൺ ഓവർഹെഡ് ഒഴിവാക്കി, ബാക്കിയുള്ള ലോഡ് ഒരു ചെറിയ ആന്തരിക തിരയൽ ലൂപ്പിൽ കേന്ദ്രീകരിച്ചിരിക്കുന്നു, ഇത് കൂടുതൽ ഒപ്റ്റിമൈസേഷന് അനുയോജ്യമാണ്.

ഞങ്ങളുടെ യഥാർത്ഥ തിരയൽ അൽഗോരിതം അടിസ്ഥാനമാക്കിയുള്ളതാണ് ലിയോണിഡ് വോൾനിറ്റ്സ്കിയുടെ മികച്ച ആശയം. ഇത് ബോയർ-മൂർ അൽഗോരിതത്തിന് സമാനമാണ്, ഓരോ ഘട്ടത്തിലും തിരയൽ സ്ട്രിംഗിന്റെ ഏകദേശം നീളം ഒഴിവാക്കുന്നു. തെറ്റായ പൊരുത്തങ്ങൾ കുറയ്ക്കുന്നതിന് ഒരു സമയം രണ്ട് ബൈറ്റുകൾ പരിശോധിക്കുന്നു എന്നതാണ് പ്രധാന വ്യത്യാസം.

ഞങ്ങളുടെ നടപ്പാക്കലിന് ഓരോ തിരയലിനും ഒരു 64K ലുക്ക്അപ്പ് ടേബിൾ സൃഷ്‌ടിക്കേണ്ടതുണ്ട്, എന്നാൽ ഞങ്ങൾ തിരയുന്ന ജിഗാബൈറ്റ് ഡാറ്റയുമായി താരതമ്യം ചെയ്യുമ്പോൾ അത് ഒന്നുമല്ല. ആന്തരിക ലൂപ്പ് ഒരൊറ്റ കോറിൽ സെക്കൻഡിൽ നിരവധി ജിഗാബൈറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നു. പ്രായോഗികമായി, ഓരോ കോറിലും സ്ഥിരതയുള്ള പ്രകടനം സെക്കൻഡിൽ 1,25 GB ആണ്, കൂടാതെ മെച്ചപ്പെടുത്താനുള്ള ഇടവുമുണ്ട്. ആന്തരിക ലൂപ്പിന് പുറത്തുള്ള ചില ഓവർഹെഡ് ഇല്ലാതാക്കാൻ സാധിക്കും, കൂടാതെ ജാവയ്ക്ക് പകരം സിയിൽ ഒരു ആന്തരിക ലൂപ്പ് പരീക്ഷിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

ഞങ്ങൾ ബലം പ്രയോഗിക്കുന്നു

ലോഗ് സെർച്ചിംഗ് "ഏകദേശം" നടപ്പിലാക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ ചർച്ച ചെയ്തിട്ടുണ്ട്, എന്നാൽ നമുക്ക് എത്ര "പവർ" ഉണ്ട്? വളരെ ധാരാളം.

1 കോർ: ശരിയായി ഉപയോഗിക്കുമ്പോൾ, ഒരു ആധുനിക പ്രോസസറിന്റെ ഒരൊറ്റ കോർ അതിന്റേതായ രീതിയിൽ വളരെ ശക്തമാണ്.

8 കോറുകൾ: ഞങ്ങൾ നിലവിൽ Amazon hi1.4xlarge, i2.4xlarge SSD സെർവറുകളിൽ പ്രവർത്തിക്കുന്നു, ഓരോന്നിനും 8 കോറുകൾ (16 ത്രെഡുകൾ) ഉണ്ട്. മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, ഈ കോറുകൾ സാധാരണയായി പശ്ചാത്തല പ്രവർത്തനങ്ങളിൽ തിരക്കിലാണ്. ഉപയോക്താവ് ഒരു തിരയൽ നടത്തുമ്പോൾ, പശ്ചാത്തല പ്രവർത്തനങ്ങൾ താൽക്കാലികമായി നിർത്തി, തിരയലിനായി എല്ലാ 8 കോറുകളും സ്വതന്ത്രമാക്കുന്നു. തിരച്ചിൽ സാധാരണയായി ഒരു സ്പ്ലിറ്റ് സെക്കൻഡിൽ പൂർത്തിയാകും, അതിനുശേഷം പശ്ചാത്തല പ്രവർത്തനം പുനരാരംഭിക്കും (തിരയൽ അന്വേഷണങ്ങളുടെ ബാരേജ് പ്രധാനപ്പെട്ട പശ്ചാത്തല പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്തുന്നില്ലെന്ന് ത്രോട്ടിലിംഗ് പ്രോഗ്രാം ഉറപ്പാക്കുന്നു).

16 കോറുകൾ: വിശ്വാസ്യതയ്ക്കായി, ഞങ്ങൾ സെർവറുകൾ മാസ്റ്റർ/സ്ലേവ് ഗ്രൂപ്പുകളായി ക്രമീകരിക്കുന്നു. ഓരോ മാസ്റ്ററും അവന്റെ കമാൻഡിന് കീഴിൽ ഒരു എസ്എസ്ഡിയും ഒരു ഇബിഎസ് സെർവറും ഉണ്ട്. പ്രധാന സെർവർ തകരാറിലായാൽ, SSD സെർവർ ഉടനടി അതിന്റെ സ്ഥാനം പിടിക്കുന്നു. മിക്കവാറും എല്ലാ സമയത്തും, യജമാനനും സ്ലേവും നന്നായി പ്രവർത്തിക്കുന്നു, അതിനാൽ ഓരോ ഡാറ്റ ബ്ലോക്കും രണ്ട് വ്യത്യസ്ത സെർവറുകളിൽ തിരയാൻ കഴിയും (EBS സ്ലേവ് സെർവറിന് ഒരു ദുർബലമായ പ്രോസസർ ഉണ്ട്, അതിനാൽ ഞങ്ങൾ അത് പരിഗണിക്കുന്നില്ല). ഞങ്ങൾ അവയ്‌ക്കിടയിൽ ടാസ്‌ക് വിഭജിക്കുന്നു, അങ്ങനെ ഞങ്ങൾക്ക് ആകെ 16 കോറുകൾ ലഭ്യമാണ്.

നിരവധി കോറുകൾ: സമീപഭാവിയിൽ, നിസ്സാരമല്ലാത്ത എല്ലാ അഭ്യർത്ഥനകളും പ്രോസസ്സ് ചെയ്യുന്നതിൽ എല്ലാവരും പങ്കെടുക്കുന്ന തരത്തിൽ ഞങ്ങൾ സെർവറുകളിലുടനീളം ഡാറ്റ വിതരണം ചെയ്യും. എല്ലാ കാമ്പും പ്രവർത്തിക്കും. [കുറിപ്പ്: ഞങ്ങൾ പ്ലാൻ നടപ്പിലാക്കുകയും തിരയൽ വേഗത 1 TB/s ആയി വർദ്ധിപ്പിക്കുകയും ചെയ്തു, ലേഖനത്തിന്റെ അവസാനം ശ്രദ്ധിക്കുക].

ലാളിത്യം വിശ്വാസ്യത ഉറപ്പാക്കുന്നു

ബ്രൂട്ട് ഫോഴ്സ് രീതിയുടെ മറ്റൊരു നേട്ടം അതിന്റെ സ്ഥിരതയുള്ള പ്രകടനമാണ്. സാധാരണഗതിയിൽ, പ്രശ്‌നത്തിന്റെയും ഡാറ്റാ സെറ്റിന്റെയും വിശദാംശങ്ങളോട് തിരയൽ വളരെ സെൻസിറ്റീവ് അല്ല (അതുകൊണ്ടാണ് ഇതിനെ "കഠിനം" എന്ന് വിളിക്കുന്നത് എന്ന് ഞാൻ കരുതുന്നു).

കീവേഡ് സൂചിക ചിലപ്പോൾ അവിശ്വസനീയമാംവിധം വേഗത്തിലുള്ള ഫലങ്ങൾ നൽകുന്നു, മറ്റ് സമയങ്ങളിൽ അത് ഉണ്ടാകില്ല. നിങ്ങൾക്ക് 50 GB ലോഗുകൾ ഉണ്ടെന്ന് പറയുക, അതിൽ 'customer_5987235982' എന്ന പദം മൂന്ന് തവണ പ്രത്യക്ഷപ്പെടുന്നു. ഈ പദത്തിനായുള്ള തിരയൽ സൂചികയിൽ നിന്ന് നേരിട്ട് മൂന്ന് ലൊക്കേഷനുകൾ കണക്കാക്കുന്നു, അത് തൽക്ഷണം പൂർത്തിയാകും. എന്നാൽ സങ്കീർണ്ണമായ വൈൽഡ്കാർഡ് തിരയലുകൾക്ക് ആയിരക്കണക്കിന് കീവേഡുകൾ സ്കാൻ ചെയ്യാനും ദീർഘനേരം എടുക്കാനും കഴിയും.

മറുവശത്ത്, ഏത് അന്വേഷണത്തിനും ബ്രൂട്ട് ഫോഴ്‌സ് തിരയലുകൾ കൂടുതലോ കുറവോ ഒരേ വേഗതയിലാണ് പ്രവർത്തിക്കുന്നത്. ദൈർഘ്യമേറിയ വാക്കുകൾക്കായി തിരയുന്നതാണ് നല്ലത്, എന്നാൽ ഒരൊറ്റ പ്രതീകത്തിനായി തിരയുന്നത് പോലും വളരെ വേഗതയുള്ളതാണ്.

ബ്രൂട്ട് ഫോഴ്‌സ് രീതിയുടെ ലാളിത്യം അർത്ഥമാക്കുന്നത് അതിന്റെ പ്രകടനം അതിന്റെ സൈദ്ധാന്തിക പരമാവധിയോട് അടുത്താണ് എന്നാണ്. അപ്രതീക്ഷിത ഡിസ്ക് ഓവർലോഡുകൾ, ലോക്ക് തർക്കം, പോയിന്റർ ചേസിംഗ്, കൂടാതെ ആയിരക്കണക്കിന് മറ്റ് പരാജയ കാരണങ്ങൾ എന്നിവയ്‌ക്ക് ഓപ്‌ഷനുകൾ കുറവാണ്. ഞങ്ങളുടെ ഏറ്റവും തിരക്കേറിയ സെർവറിൽ കഴിഞ്ഞ ആഴ്ച Scalyr ഉപയോക്താക്കൾ നടത്തിയ അഭ്യർത്ഥനകൾ ഞാൻ ഇപ്പോൾ നോക്കി. 14 അപേക്ഷകളാണ് ലഭിച്ചത്. അവരിൽ കൃത്യം എട്ട് പേർ ഒരു സെക്കൻഡിൽ കൂടുതൽ സമയമെടുത്തു; 000% 99 മില്ലിസെക്കൻഡിനുള്ളിൽ പൂർത്തിയായി (നിങ്ങൾ ലോഗ് വിശകലന ടൂളുകൾ ഉപയോഗിച്ചിട്ടില്ലെങ്കിൽ, എന്നെ വിശ്വസിക്കൂ: അത് വേഗത്തിലാണ്).

സേവനത്തിന്റെ എളുപ്പത്തിലുള്ള ഉപയോഗത്തിന് സുസ്ഥിരവും വിശ്വസനീയവുമായ പ്രകടനം പ്രധാനമാണ്. കാലാകാലങ്ങളിൽ ഇത് കാലതാമസം നേരിടുന്നുണ്ടെങ്കിൽ, ഉപയോക്താക്കൾ അത് വിശ്വസനീയമല്ലെന്ന് മനസ്സിലാക്കുകയും അത് ഉപയോഗിക്കാൻ വിമുഖത കാണിക്കുകയും ചെയ്യും.

ലോഗ് തിരയൽ പ്രവർത്തനത്തിലാണ്

Scalyr തിരയൽ പ്രവർത്തനത്തിൽ കാണിക്കുന്ന ഒരു ചെറിയ ആനിമേഷൻ ഇതാ. എല്ലാ പൊതു Github ശേഖരണത്തിലും ഞങ്ങൾ എല്ലാ ഇവന്റുകളും ഇറക്കുമതി ചെയ്യുന്ന ഒരു ഡെമോ അക്കൗണ്ട് ഞങ്ങൾക്കുണ്ട്. ഈ ഡെമോയിൽ, ഞാൻ ഒരാഴ്ചത്തെ ഡാറ്റ പരിശോധിക്കുന്നു: ഏകദേശം 600 MB റോ ലോഗുകൾ.

പ്രത്യേക തയ്യാറെടുപ്പുകൾ കൂടാതെ, എന്റെ ഡെസ്‌ക്‌ടോപ്പിൽ (സെർവറിൽ നിന്ന് ഏകദേശം 5000 കിലോമീറ്റർ) വീഡിയോ തത്സമയം റെക്കോർഡുചെയ്‌തു. നിങ്ങൾ കാണേണ്ട പ്രകടനം പ്രധാനമായും കാരണമാണ് വെബ് ക്ലയന്റ് ഒപ്റ്റിമൈസേഷൻ, അതുപോലെ വേഗതയേറിയതും വിശ്വസനീയവുമായ ഒരു ബാക്കെൻഡ്. 'ലോഡിംഗ്' ഇൻഡിക്കേറ്റർ ഇല്ലാതെ താൽക്കാലികമായി നിർത്തുമ്പോഴെല്ലാം, അത് ഞാൻ താൽക്കാലികമായി നിർത്തുന്നു, അതിനാൽ ഞാൻ എന്താണ് അമർത്താൻ പോകുന്നതെന്ന് നിങ്ങൾക്ക് വായിക്കാനാകും.

ഉപസംഹാരമായി

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

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

ഒരു ബ്രൂട്ട് ഫോഴ്‌സ് രീതി ഉപയോഗിച്ച്, ഒരു കൂട്ടം ലോഗുകളിലുടനീളം ഞങ്ങൾ വേഗതയേറിയതും വിശ്വസനീയവും വഴക്കമുള്ളതുമായ തിരയൽ നടപ്പിലാക്കി. ഈ ആശയങ്ങൾ നിങ്ങളുടെ പ്രോജക്ടുകൾക്ക് ഉപയോഗപ്രദമാകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

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

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