ഇലാസ്റ്റിക് സെർച്ച് ക്ലസ്റ്റർ 200 TB+

ഇലാസ്റ്റിക് തിരയലുമായി പലരും പോരാടുന്നു. ലോഗുകൾ "പ്രത്യേകിച്ച് വലിയ അളവിൽ" സംഭരിക്കുന്നതിന് നിങ്ങൾ അത് ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ എന്ത് സംഭവിക്കും? കൂടാതെ നിരവധി ഡാറ്റാ സെൻ്ററുകളിൽ ഏതെങ്കിലുമൊരു പരാജയം അനുഭവപ്പെടുന്നത് വേദനയില്ലാത്തതാണോ? ഏത് തരത്തിലുള്ള വാസ്തുവിദ്യയാണ് നിങ്ങൾ നിർമ്മിക്കേണ്ടത്, എന്ത് അപകടങ്ങളിൽ നിങ്ങൾ ഇടറിവീഴും?

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

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

ഞാൻ ഒഡ്‌നോക്ലാസ്‌നിക്കിയിൽ വന്നപ്പോൾ, ഇലാസ്റ്റിക് സെർച്ചിൽ പ്രവർത്തിക്കാമെന്ന് ഞാൻ അഭിമുഖത്തിൽ അശ്രദ്ധമായി പറഞ്ഞു. എനിക്ക് പിടി കിട്ടുകയും ചില ലളിതമായ ജോലികൾ പൂർത്തിയാക്കുകയും ചെയ്ത ശേഷം, അക്കാലത്തുണ്ടായിരുന്ന ലോഗ് മാനേജ്മെൻ്റ് സിസ്റ്റം പരിഷ്കരിക്കുക എന്ന വലിയ ദൗത്യം എന്നെ ഏൽപ്പിച്ചു.

ആവശ്യകതകൾ

സിസ്റ്റം ആവശ്യകതകൾ ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്തി:

• ഗ്രെയ്‌ലോഗ് മുൻഭാഗമായി ഉപയോഗിക്കേണ്ടതായിരുന്നു. കമ്പനിക്ക് ഇതിനകം ഈ ഉൽപ്പന്നം ഉപയോഗിച്ച് അനുഭവം ഉണ്ടായിരുന്നതിനാൽ, പ്രോഗ്രാമർമാർക്കും ടെസ്റ്റർമാർക്കും അത് അറിയാമായിരുന്നു, അത് അവർക്ക് പരിചിതവും സൗകര്യപ്രദവുമായിരുന്നു.
• ഡാറ്റ വോളിയം: സെക്കൻഡിൽ ശരാശരി 50-80 ആയിരം സന്ദേശങ്ങൾ, പക്ഷേ എന്തെങ്കിലും തകരാറുണ്ടെങ്കിൽ, ട്രാഫിക്ക് ഒന്നിനും പരിമിതമല്ല, ഇത് സെക്കൻഡിൽ 2-3 ദശലക്ഷം വരികൾ ആകാം
• സെർച്ച് ക്വറികൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള വേഗതയുടെ ആവശ്യകതകളെക്കുറിച്ച് ഉപഭോക്താക്കളുമായി ചർച്ച ചെയ്ത ശേഷം, അത്തരമൊരു സിസ്റ്റം ഉപയോഗിക്കുന്നതിൻ്റെ സാധാരണ പാറ്റേൺ ഇതാണ് എന്ന് ഞങ്ങൾ മനസ്സിലാക്കി: ആളുകൾ കഴിഞ്ഞ രണ്ട് ദിവസമായി അവരുടെ അപേക്ഷയുടെ ലോഗുകൾക്കായി തിരയുന്നു, ഒരു ദിവസത്തിൽ കൂടുതൽ കാത്തിരിക്കാൻ ആഗ്രഹിക്കുന്നില്ല. ഒരു രൂപപ്പെടുത്തിയ ചോദ്യത്തിൻ്റെ ഫലത്തിന് രണ്ടാമത്തേത്.
• സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് ആഴത്തിൽ പരിശോധിക്കേണ്ടതില്ല, ആവശ്യമെങ്കിൽ അത് എളുപ്പത്തിൽ അളക്കാൻ കഴിയുമെന്ന് അഡ്മിനിസ്ട്രേറ്റർമാർ നിർബന്ധിച്ചു.
• അതിനാൽ, ഈ സിസ്റ്റങ്ങൾക്ക് ഇടയ്ക്കിടെ ആവശ്യമുള്ള ഒരേയൊരു അറ്റകുറ്റപ്പണി ചില ഹാർഡ്‌വെയർ മാറ്റുക എന്നതാണ്.
• കൂടാതെ, Odnoklassniki-ക്ക് ഒരു മികച്ച സാങ്കേതിക പാരമ്പര്യമുണ്ട്: ഞങ്ങൾ സമാരംഭിക്കുന്ന ഏതൊരു സേവനവും ഒരു ഡാറ്റാ സെൻ്റർ പരാജയത്തെ അതിജീവിക്കണം (പെട്ടെന്ന്, ആസൂത്രണം ചെയ്യാത്തതും തികച്ചും എപ്പോൾ വേണമെങ്കിലും).

ഈ പ്രോജക്റ്റ് നടപ്പിലാക്കുന്നതിനുള്ള അവസാന ആവശ്യകത ഞങ്ങൾക്ക് ഏറ്റവും ചെലവേറിയതാണ്, അത് ഞാൻ കൂടുതൽ വിശദമായി സംസാരിക്കും.

ബുധൻ

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

ഈ നാല് ഡാറ്റാ സെൻ്ററുകളിൽ ഏകദേശം 18 ആയിരം വ്യത്യസ്ത ലോഗ് ഉറവിടങ്ങൾ അടങ്ങിയിരിക്കുന്നു - ഹാർഡ്‌വെയർ, കണ്ടെയ്‌നറുകൾ, വെർച്വൽ മെഷീനുകൾ.

പ്രധാന സവിശേഷത: കണ്ടെയ്നറുകളിൽ ക്ലസ്റ്റർ ആരംഭിക്കുന്നു പോഡ്മാൻ ഫിസിക്കൽ മെഷീനുകളിലല്ല, മറിച്ച് സ്വന്തം ക്ലൗഡ് ഉൽപ്പന്നം ഒരു-ക്ലൗഡ്. കണ്ടെയ്‌നറുകൾക്ക് 2Ghz v2.0-ന് സമാനമായ 4 കോറുകൾ ഉറപ്പുനൽകുന്നു, അവ നിഷ്‌ക്രിയമാണെങ്കിൽ ശേഷിക്കുന്ന കോറുകൾ റീസൈക്കിൾ ചെയ്യാനുള്ള സാധ്യതയും ഉണ്ട്.

മറ്റൊരു വാക്കിൽ:

ടോപ്പോളജി

പരിഹാരത്തിൻ്റെ പൊതുവായ രൂപം ഞാൻ ആദ്യം കണ്ടു:

• ഗ്രേലോഗ് ഡൊമെയ്‌നിൻ്റെ എ-റെക്കോർഡിന് പിന്നിൽ 3-4 വിഐപികൾ ഉണ്ട്, ലോഗുകൾ അയച്ച വിലാസമാണിത്.
• ഓരോ വിഐപിയും ഒരു എൽവിഎസ് ബാലൻസറാണ്.
• അതിനുശേഷം, ലോഗുകൾ ഗ്രേലോഗ് ബാറ്ററിയിലേക്ക് പോകുന്നു, ചില ഡാറ്റ GELF ഫോർമാറ്റിലാണ്, ചിലത് syslog ഫോർമാറ്റിലാണ്.
• അപ്പോൾ ഇതെല്ലാം വലിയ ബാച്ചുകളായി ഇലാസ്റ്റിക് സെർച്ച് കോർഡിനേറ്ററുകളുടെ ബാറ്ററിയിലേക്ക് എഴുതിയിരിക്കുന്നു.
• കൂടാതെ, അവർ പ്രസക്തമായ ഡാറ്റ നോഡുകളിലേക്ക് എഴുതാനും വായിക്കാനും അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു.

പദാവലി

ഒരുപക്ഷേ എല്ലാവരും പദാവലി വിശദമായി മനസ്സിലാക്കുന്നില്ല, അതിനാൽ ഞാൻ അതിൽ അൽപ്പം താമസിക്കാൻ ആഗ്രഹിക്കുന്നു.

ഇലാസ്റ്റിക് സെർച്ചിന് നിരവധി തരം നോഡുകൾ ഉണ്ട് - മാസ്റ്റർ, കോർഡിനേറ്റർ, ഡാറ്റ നോഡ്. വ്യത്യസ്‌ത ലോഗ് പരിവർത്തനങ്ങൾക്കും വ്യത്യസ്ത ക്ലസ്റ്ററുകൾ തമ്മിലുള്ള ആശയവിനിമയത്തിനും മറ്റ് രണ്ട് തരങ്ങളുണ്ട്, പക്ഷേ ഞങ്ങൾ ലിസ്‌റ്റ് ചെയ്‌തവ മാത്രമാണ് ഉപയോഗിച്ചത്.

യജമാനന്
ഇത് ക്ലസ്റ്ററിലുള്ള എല്ലാ നോഡുകളും പിംഗ് ചെയ്യുന്നു, കാലികമായ ഒരു ക്ലസ്റ്റർ മാപ്പ് പരിപാലിക്കുകയും നോഡുകൾക്കിടയിൽ വിതരണം ചെയ്യുകയും ഇവൻ്റ് ലോജിക് പ്രോസസ്സ് ചെയ്യുകയും വിവിധ തരത്തിലുള്ള ക്ലസ്റ്റർ വൈഡ് ഹൗസ് കീപ്പിംഗ് നടത്തുകയും ചെയ്യുന്നു.

കോർഡിനേറ്റർ
ഒരൊറ്റ ടാസ്‌ക്ക് ചെയ്യുന്നു: ക്ലയൻ്റുകളിൽ നിന്നുള്ള റീഡ് അല്ലെങ്കിൽ റൈറ്റ് അഭ്യർത്ഥനകൾ സ്വീകരിക്കുകയും ഈ ട്രാഫിക്കിനെ റൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു. ഒരു എഴുത്ത് അഭ്യർത്ഥന ഉണ്ടെങ്കിൽ, മിക്കവാറും, അത് പ്രസക്തമായ സൂചികയുടെ ഏത് ഷാർഡിൽ ഇടണമെന്ന് അത് മാസ്റ്ററോട് ചോദിക്കുകയും അഭ്യർത്ഥന കൂടുതൽ റീഡയറക്ട് ചെയ്യുകയും ചെയ്യും.

ഡാറ്റ നോഡ്
ഡാറ്റ സംഭരിക്കുന്നു, പുറത്ത് നിന്ന് വരുന്ന തിരയൽ അന്വേഷണങ്ങൾ നടത്തുന്നു, അതിൽ സ്ഥിതിചെയ്യുന്ന ഷാർഡുകളിൽ പ്രവർത്തനങ്ങൾ നടത്തുന്നു.

ഗ്രേലോഗ്
ഇത് ഒരു ELK സ്റ്റാക്കിലെ ലോഗ്സ്റ്റാഷിനൊപ്പം കിബാനയുടെ സംയോജനം പോലെയാണ്. ഗ്രേലോഗ് ഒരു യുഐയും ലോഗ് പ്രോസസ്സിംഗ് പൈപ്പ്ലൈനും സംയോജിപ്പിക്കുന്നു. ഹുഡിന് കീഴിൽ, ഗ്രേലോഗ് കാഫ്കയും സൂക്കീപ്പറും പ്രവർത്തിപ്പിക്കുന്നു, ഇത് ഗ്രേലോഗിന് ഒരു ക്ലസ്റ്ററായി കണക്റ്റിവിറ്റി നൽകുന്നു. ഇലാസ്റ്റിക് സെർച്ച് ലഭ്യമല്ലാത്ത സാഹചര്യത്തിൽ ഗ്രെയ്‌ലോഗിന് ലോഗുകൾ (കാഫ്ക) കാഷെ ചെയ്യാൻ കഴിയും, കൂടാതെ റീഡ് ആൻഡ് റൈറ്റ് അഭ്യർത്ഥനകൾ ആവർത്തിക്കുകയും നിർദ്ദിഷ്ട നിയമങ്ങൾക്കനുസരിച്ച് ലോഗുകൾ ഗ്രൂപ്പുചെയ്യുകയും അടയാളപ്പെടുത്തുകയും ചെയ്യും. Logstash പോലെ, Graylog-ന് ഇലാസ്റ്റിക് സെർച്ചിൽ എഴുതുന്നതിന് മുമ്പ് വരികൾ പരിഷ്കരിക്കാനുള്ള പ്രവർത്തനമുണ്ട്.

കൂടാതെ, ഗ്രെയ്‌ലോഗിന് ഒരു ബിൽറ്റ്-ഇൻ സേവന കണ്ടെത്തൽ ഉണ്ട്, അത് ലഭ്യമായ ഒരു ഇലാസ്റ്റിക് സെർച്ച് നോഡിനെ അടിസ്ഥാനമാക്കി, മുഴുവൻ ക്ലസ്റ്റർ മാപ്പും നേടാനും ഒരു നിർദ്ദിഷ്ട ടാഗ് ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യാനും അനുവദിക്കുന്നു, ഇത് നിർദ്ദിഷ്ട കണ്ടെയ്‌നറുകളിലേക്ക് അഭ്യർത്ഥനകൾ നയിക്കുന്നത് സാധ്യമാക്കുന്നു.

കാഴ്ചയിൽ ഇത് ഇതുപോലെ കാണപ്പെടുന്നു:

ഇത് ഒരു പ്രത്യേക സംഭവത്തിൽ നിന്നുള്ള സ്ക്രീൻഷോട്ടാണ്. തിരയൽ അന്വേഷണത്തെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ ഇവിടെ ഒരു ഹിസ്റ്റോഗ്രാം നിർമ്മിക്കുകയും പ്രസക്തമായ വരികൾ പ്രദർശിപ്പിക്കുകയും ചെയ്യുന്നു.

സൂചികകൾ

സിസ്റ്റം ആർക്കിടെക്ചറിലേക്ക് മടങ്ങുമ്പോൾ, ഞങ്ങൾ എങ്ങനെ ഇൻഡക്സ് മോഡൽ നിർമ്മിച്ചു എന്നതിനെക്കുറിച്ച് കൂടുതൽ വിശദമായി സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, അങ്ങനെ എല്ലാം ശരിയായി പ്രവർത്തിക്കുന്നു.

മുകളിലുള്ള ഡയഗ്രാമിൽ, ഇത് ഏറ്റവും താഴ്ന്ന നിലയാണ്: ഇലാസ്റ്റിക് സെർച്ച് ഡാറ്റ നോഡുകൾ.

ഇലാസ്റ്റിക് സെർച്ച് ഷാർഡുകൾ കൊണ്ട് നിർമ്മിച്ച ഒരു വലിയ വെർച്വൽ എൻ്റിറ്റിയാണ് സൂചിക. അതിൽത്തന്നെ, ഓരോ ചില്ലുകളും ഒരു ലൂസീൻ സൂചികയല്ലാതെ മറ്റൊന്നുമല്ല. ഓരോ ലൂസീൻ സൂചികയും ഒന്നോ അതിലധികമോ സെഗ്‌മെൻ്റുകൾ ഉൾക്കൊള്ളുന്നു.

രൂപകൽപന ചെയ്യുമ്പോൾ, വലിയ അളവിലുള്ള ഡാറ്റയിൽ വായനാ വേഗതയുടെ ആവശ്യകത നിറവേറ്റുന്നതിന്, ഡാറ്റാ നോഡുകളിലുടനീളം ഈ ഡാറ്റ തുല്യമായി "പ്രചരിപ്പിക്കേണ്ടതുണ്ട്" എന്ന് ഞങ്ങൾ കണ്ടെത്തി.

ഓരോ സൂചികയിലെയും (പകർപ്പുകളുള്ള) ഷാർഡുകളുടെ എണ്ണം ഡാറ്റാ നോഡുകളുടെ എണ്ണത്തിന് കർശനമായി തുല്യമായിരിക്കണം എന്ന വസ്തുത ഇത് കാരണമായി. ഒന്നാമതായി, രണ്ടിന് തുല്യമായ ഒരു പകർപ്പെടുക്കൽ ഘടകം ഉറപ്പാക്കുന്നതിന് (അതായത്, നമുക്ക് ക്ലസ്റ്ററിൻ്റെ പകുതി നഷ്ടപ്പെടാം). രണ്ടാമതായി, ക്ലസ്റ്ററിൻ്റെ പകുതിയിലെങ്കിലും റീഡ് ആൻഡ് റൈറ്റ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന്.

ഞങ്ങൾ ആദ്യം സംഭരണ ​​സമയം 30 ദിവസമായി നിശ്ചയിച്ചു.

ചില്ലുകളുടെ വിതരണത്തെ ഗ്രാഫിക്കായി ഇനിപ്പറയുന്ന രീതിയിൽ പ്രതിനിധീകരിക്കാം:

ഇരുണ്ട ചാരനിറത്തിലുള്ള ദീർഘചതുരം മുഴുവൻ ഒരു സൂചികയാണ്. അതിൽ ഇടത് ചുവന്ന ചതുരം പ്രൈമറി ഷാർഡ് ആണ്, സൂചികയിലെ ആദ്യത്തേത്. നീല ചതുരം ഒരു പകർപ്പാണ്. അവ വ്യത്യസ്ത ഡാറ്റാ സെൻ്ററുകളിലാണ് സ്ഥിതി ചെയ്യുന്നത്.

നമ്മൾ മറ്റൊരു ഷാർഡ് ചേർക്കുമ്പോൾ, അത് മൂന്നാമത്തെ ഡാറ്റാ സെൻ്ററിലേക്ക് പോകുന്നു. കൂടാതെ, അവസാനം, ഞങ്ങൾക്ക് ഈ ഘടന ലഭിക്കുന്നു, ഇത് ഡാറ്റയുടെ സ്ഥിരത നഷ്‌ടപ്പെടാതെ DC നഷ്‌ടപ്പെടുത്തുന്നത് സാധ്യമാക്കുന്നു:

സൂചികകളുടെ റൊട്ടേഷൻ, അതായത്. ഒരു പുതിയ സൂചിക സൃഷ്‌ടിക്കുകയും ഏറ്റവും പഴയത് ഇല്ലാതാക്കുകയും ചെയ്‌താൽ, ഞങ്ങൾ അത് 48 മണിക്കൂറിന് തുല്യമാക്കി (സൂചിക ഉപയോഗത്തിൻ്റെ പാറ്റേൺ അനുസരിച്ച്: അവസാന 48 മണിക്കൂർ ഏറ്റവും കൂടുതൽ തിരഞ്ഞത്).

ഈ സൂചിക റൊട്ടേഷൻ ഇടവേള ഇനിപ്പറയുന്ന കാരണങ്ങളാൽ സംഭവിക്കുന്നു:

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

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

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

തൽഫലമായി, ശരാശരി ഒരു ഷാർഡിൻ്റെ ഭാരം ഏകദേശം 20 ജിഗാബൈറ്റ് ആണെന്നും ഒരു സൂചികയിൽ 1 ഷാർഡുകൾ ഉണ്ടെന്നും ഞങ്ങൾ കണ്ടെത്തി. അതനുസരിച്ച്, ഓരോ 360 മണിക്കൂറിലും ഒരിക്കൽ ഞങ്ങൾ അവയെ തിരിക്കുകയാണെങ്കിൽ, നമുക്ക് അവയിൽ 48 എണ്ണം ഉണ്ട്. ഓരോ സൂചികയിലും 15 ദിവസത്തേക്കുള്ള ഡാറ്റ അടങ്ങിയിരിക്കുന്നു.

ഡാറ്റ റൈറ്റിംഗ്, റീഡിംഗ് സർക്യൂട്ടുകൾ

ഈ സിസ്റ്റത്തിൽ ഡാറ്റ രേഖപ്പെടുത്തുന്നത് എങ്ങനെയെന്ന് നമുക്ക് നോക്കാം.

ഗ്രേലോഗിൽ നിന്ന് കോർഡിനേറ്ററിലേക്ക് ചില അഭ്യർത്ഥനകൾ എത്തിയെന്ന് പറയാം. ഉദാഹരണത്തിന്, ഞങ്ങൾ 2-3 ആയിരം വരികൾ സൂചികയിലാക്കാൻ ആഗ്രഹിക്കുന്നു.

ഗ്രേലോഗിൽ നിന്ന് ഒരു അഭ്യർത്ഥന ലഭിച്ച കോർഡിനേറ്റർ, മാസ്റ്ററെ ചോദ്യം ചെയ്യുന്നു: "ഇൻഡക്സിംഗ് അഭ്യർത്ഥനയിൽ, ഞങ്ങൾ ഒരു സൂചിക പ്രത്യേകം വ്യക്തമാക്കിയിട്ടുണ്ട്, എന്നാൽ ഏത് ഷാർഡിൽ അത് എഴുതണമെന്ന് വ്യക്തമാക്കിയിട്ടില്ല."

മാസ്റ്റർ പ്രതികരിക്കുന്നു: "ഈ വിവരങ്ങൾ ഷാർഡ് നമ്പർ 71 ലേക്ക് എഴുതുക", അതിനുശേഷം അത് പ്രാഥമിക-ഷാർഡ് നമ്പർ 71 സ്ഥിതി ചെയ്യുന്ന പ്രസക്തമായ ഡാറ്റ നോഡിലേക്ക് നേരിട്ട് അയയ്ക്കുന്നു.

അതിനുശേഷം ഇടപാട് ലോഗ് മറ്റൊരു ഡാറ്റാ സെൻ്ററിൽ സ്ഥിതി ചെയ്യുന്ന ഒരു റെപ്ലിക്ക-ഷാർഡിലേക്ക് പകർത്തുന്നു.

ഗ്രേലോഗിൽ നിന്ന് കോർഡിനേറ്റർക്ക് ഒരു തിരയൽ അഭ്യർത്ഥന വരുന്നു. കോർഡിനേറ്റർ അത് സൂചിക അനുസരിച്ച് റീഡയറക്‌ടുചെയ്യുന്നു, അതേസമയം ഇലാസ്റ്റിക് തിരയൽ റൗണ്ട്-റോബിൻ തത്വം ഉപയോഗിച്ച് പ്രാഥമിക-ഷാർഡിനും റെപ്ലിക്ക-ഷാർഡിനും ഇടയിൽ അഭ്യർത്ഥനകൾ വിതരണം ചെയ്യുന്നു.

180 നോഡുകൾ അസമമായി പ്രതികരിക്കുന്നു, അവർ പ്രതികരിക്കുമ്പോൾ, വേഗതയേറിയ ഡാറ്റ നോഡുകൾ വഴി ഇതിനകം "തുപ്പിയ" വിവരങ്ങൾ കോർഡിനേറ്റർ ശേഖരിക്കുന്നു. ഇതിനുശേഷം, ഒന്നുകിൽ എല്ലാ വിവരങ്ങളും എത്തുമ്പോൾ, അല്ലെങ്കിൽ അഭ്യർത്ഥന കാലഹരണപ്പെടുമ്പോൾ, അത് ക്ലയൻ്റിന് നേരിട്ട് എല്ലാം നൽകുന്നു.

ഒരു മുൻനിര വൈൽഡ്കാർഡ് ഉപയോഗിച്ചുള്ള അന്വേഷണങ്ങൾ ഒഴികെ, ശരാശരി ഈ മുഴുവൻ സിസ്റ്റവും കഴിഞ്ഞ 48 മണിക്കൂറിനുള്ളിൽ 300-400 മി.സി.യിൽ തിരയൽ അന്വേഷണങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നു.

ഇലാസ്റ്റിക് സെർച്ച് ഉള്ള പൂക്കൾ: ജാവ സജ്ജീകരണം

ഞങ്ങൾ ആദ്യം ആഗ്രഹിച്ച രീതിയിൽ എല്ലാം പ്രവർത്തിക്കുന്നതിന്, ക്ലസ്റ്ററിലെ വൈവിധ്യമാർന്ന കാര്യങ്ങൾ ഡീബഗ്ഗ് ചെയ്യാൻ ഞങ്ങൾ വളരെക്കാലം ചെലവഴിച്ചു.

കണ്ടെത്തിയ പ്രശ്‌നങ്ങളുടെ ആദ്യഭാഗം ഇലാസ്റ്റിക് സെർച്ചിൽ ഡിഫോൾട്ടായി ജാവ പ്രീ-കോൺഫിഗർ ചെയ്യുന്ന രീതിയുമായി ബന്ധപ്പെട്ടതാണ്.

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

ലൂസീൻ സൂചിക ലയനം ഹിപ്പിന് പുറത്ത് സംഭവിക്കുന്നതായി ഇത് മാറി. ഉപഭോഗം ചെയ്യുന്ന വിഭവങ്ങളുടെ കാര്യത്തിൽ കണ്ടെയ്നറുകൾ കർശനമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഈ സ്രോതസ്സുകളിലേക്ക് ഹീപ്പിന് മാത്രമേ ഉൾക്കൊള്ളാൻ കഴിയൂ (heap.size മൂല്യം ഏകദേശം RAM-ന് തുല്യമായിരുന്നു), ചില കാരണങ്ങളാൽ അവ പരിധിക്ക് മുമ്പുള്ള ~500MB-യുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, ചില ഓഫ്-ഹീപ്പ് പ്രവർത്തനങ്ങൾ മെമ്മറി അലോക്കേഷൻ പിശക് മൂലം ക്രാഷ് ചെയ്തു.

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

പ്രശ്നം രണ്ട്
ക്ലസ്റ്ററിൻ്റെ സമാരംഭത്തിന് 4-5 ദിവസങ്ങൾക്ക് ശേഷം, ഡാറ്റ നോഡുകൾ ഇടയ്ക്കിടെ ക്ലസ്റ്ററിൽ നിന്ന് വീഴുകയും 10-20 സെക്കൻഡിനുശേഷം അതിൽ പ്രവേശിക്കുകയും ചെയ്യുന്നത് ഞങ്ങൾ ശ്രദ്ധിച്ചു.

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

ചില സാഹചര്യങ്ങളിൽ, ഈ പ്രവർത്തനത്തിന് വളരെയധികം സമയമെടുത്തു, ഈ സമയത്ത് ക്ലസ്റ്ററിന് ഈ നോഡ് ഇതിനകം പുറത്തുകടന്നതായി അടയാളപ്പെടുത്താൻ കഴിഞ്ഞു. ഈ പ്രശ്നം നന്നായി വിവരിച്ചിരിക്കുന്നു ഇവിടെ.

പരിഹാരം ഇപ്രകാരമായിരുന്നു: ഈ പ്രവർത്തനങ്ങൾക്ക് കൂമ്പാരത്തിന് പുറത്ത് മെമ്മറിയുടെ ബൾക്ക് ഉപയോഗിക്കാനുള്ള ജാവയുടെ കഴിവ് ഞങ്ങൾ പരിമിതപ്പെടുത്തി. ഞങ്ങൾ ഇത് 16 ജിഗാബൈറ്റായി (-XX:MaxDirectMemorySize=16g) പരിമിതപ്പെടുത്തി, വ്യക്തമായ GC കൂടുതൽ തവണ വിളിക്കുകയും വളരെ വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു, അതുവഴി ക്ലസ്റ്ററിനെ അസ്ഥിരപ്പെടുത്തുന്നില്ലെന്ന് ഉറപ്പാക്കുന്നു.

പ്രശ്നം മൂന്ന്
"ഏറ്റവും അപ്രതീക്ഷിതമായ നിമിഷത്തിൽ ക്ലസ്റ്ററിൽ നിന്ന് പുറത്തുപോകുന്ന നോഡുകൾ" എന്നതിലെ പ്രശ്നങ്ങൾ അവസാനിച്ചുവെന്ന് നിങ്ങൾ കരുതുന്നുവെങ്കിൽ, നിങ്ങൾ തെറ്റിദ്ധരിക്കപ്പെടുന്നു.

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

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

പ്രശ്നം നാല്
പിന്നീട് ഞങ്ങൾ റെക്കോർഡ് സമയത്തേക്ക് ചികിത്സിച്ച വളരെ രസകരമായ മറ്റൊരു പ്രശ്നം ഉണ്ടായിരുന്നു. 2-3 മാസത്തേക്ക് ഞങ്ങൾ അതിനെ പിടികൂടി, കാരണം അതിൻ്റെ പാറ്റേൺ തികച്ചും മനസ്സിലാക്കാൻ കഴിയാത്തതാണ്.

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

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

തൽഫലമായി, ഒരു ഉപയോക്താവ് ഒരു വലിയ അഭ്യർത്ഥന സമാരംഭിക്കുകയും അത് ഒരു നിർദ്ദിഷ്ട ഇലാസ്റ്റിക് തിരയൽ കോർഡിനേറ്ററിലേക്ക് എത്തുകയും ചെയ്യുന്ന നിമിഷത്തിൽ, ചില നോഡുകൾ മറ്റുള്ളവയേക്കാൾ കൂടുതൽ സമയം പ്രതികരിക്കുന്നു.

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

ഈ സാഹചര്യത്തിൽ ക്ലസ്റ്ററിൻ്റെ സ്വഭാവം മാറ്റാൻ ഞങ്ങൾ കണ്ടെത്തിയ ഒരേയൊരു പരിഹാരം JDK13-ലേക്കുള്ള മൈഗ്രേഷനും Shenandoah garbage ശേഖരണത്തിൻ്റെ ഉപയോഗവുമാണ്. ഇത് പ്രശ്നം പരിഹരിച്ചു, ഞങ്ങളുടെ കോർഡിനേറ്റർമാർ വീഴുന്നത് നിർത്തി.

ഇവിടെയാണ് ജാവയിലെ പ്രശ്‌നങ്ങൾ അവസാനിക്കുന്നതും ബാൻഡ്‌വിഡ്ത്ത് പ്രശ്‌നങ്ങൾ ആരംഭിക്കുന്നതും.

ഇലാസ്റ്റിക് സെർച്ചിനൊപ്പം "ബെറികൾ": ത്രൂപുട്ട്

ത്രൂപുട്ടിലെ പ്രശ്‌നങ്ങൾ അർത്ഥമാക്കുന്നത് ഞങ്ങളുടെ ക്ലസ്റ്റർ സ്ഥിരതയോടെ പ്രവർത്തിക്കുന്നു, എന്നാൽ സൂചികയിലാക്കിയ പ്രമാണങ്ങളുടെ എണ്ണത്തിൽ ഏറ്റവും ഉയർന്ന നിലയിലും കുസൃതികളിൽ പ്രകടനം അപര്യാപ്തമാണ്.

നേരിട്ട ആദ്യ ലക്ഷണം: ഉൽപ്പാദനത്തിലെ ചില "സ്ഫോടനങ്ങൾ" സമയത്ത്, വളരെ വലിയ ലോഗുകൾ പെട്ടെന്ന് ജനറേറ്റുചെയ്യുമ്പോൾ, es_rejected_execution എന്ന ഇൻഡെക്സിംഗ് പിശക് ഗ്രേലോഗിൽ ഇടയ്ക്കിടെ ഫ്ലാഷ് ചെയ്യാൻ തുടങ്ങുന്നു.

ഒരു ഡാറ്റാ നോഡിൽ thread_pool.write.queue എന്നത് ഇൻഡക്‌സിംഗ് അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യാനും ഡിസ്കിലെ ഷാർഡിലേക്ക് വിവരങ്ങൾ അപ്‌ലോഡ് ചെയ്യാനും കഴിയുന്ന നിമിഷം വരെ, സ്ഥിരസ്ഥിതിയായി 200 അഭ്യർത്ഥനകൾ മാത്രമേ കാഷെ ചെയ്യാൻ കഴിയൂ എന്നതാണ് ഇതിന് കാരണം. ഒപ്പം അകത്തും ഇലാസ്റ്റിക് സെർച്ച് ഡോക്യുമെൻ്റേഷൻ ഈ പരാമീറ്ററിനെക്കുറിച്ച് വളരെ കുറച്ച് മാത്രമേ പറഞ്ഞിട്ടുള്ളൂ. പരമാവധി എണ്ണം ത്രെഡുകളും ഡിഫോൾട്ട് വലുപ്പവും മാത്രമേ സൂചിപ്പിച്ചിട്ടുള്ളൂ.

തീർച്ചയായും, ഞങ്ങൾ ഈ മൂല്യം വളച്ചൊടിക്കാൻ പോയി ഇനിപ്പറയുന്നവ കണ്ടെത്തി: പ്രത്യേകിച്ചും, ഞങ്ങളുടെ സജ്ജീകരണത്തിൽ, 300 അഭ്യർത്ഥനകൾ വരെ നന്നായി കാഷെ ചെയ്‌തിരിക്കുന്നു, മാത്രമല്ല ഉയർന്ന മൂല്യം ഞങ്ങൾ വീണ്ടും ഫുൾ ജിസിയിലേക്ക് പറക്കുന്നു എന്ന വസ്തുതയാൽ നിറഞ്ഞതാണ്.

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

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

കൂടാതെ, ഉൽപ്പാദനത്തിൽ സമാനമായ സ്ഫോടനങ്ങൾ ഉണ്ടായപ്പോൾ, പ്രോഗ്രാമർമാരിൽ നിന്നും ടെസ്റ്റർമാരിൽ നിന്നും ഞങ്ങൾക്ക് പരാതികൾ ലഭിച്ചു: അവർക്ക് ഈ ലോഗുകൾ ശരിക്കും ആവശ്യമുള്ള നിമിഷത്തിൽ, അവർക്ക് വളരെ സാവധാനം നൽകി.

അവർ അത് മനസ്സിലാക്കാൻ തുടങ്ങി. ഒരു വശത്ത്, തിരയൽ അന്വേഷണങ്ങളും ഇൻഡക്‌സിംഗ് അന്വേഷണങ്ങളും പ്രോസസ്സ് ചെയ്തിരിക്കുന്നത്, പ്രധാനമായും, ഒരേ ഫിസിക്കൽ മെഷീനുകളിലാണ്, ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ ചില കുറവുകൾ ഉണ്ടാകും.

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

വായനാ ചിത്രം ഇതുപോലെ കാണപ്പെടുന്നു:

ഈ അൽഗോരിതത്തിലേക്കുള്ള മാറ്റം, ഞങ്ങൾക്ക് എഴുതാൻ ലോഗുകളുടെ ഒരു വലിയ ഒഴുക്ക് ഉണ്ടായിരുന്ന ആ നിമിഷങ്ങളിൽ അന്വേഷണ സമയം ഗണ്യമായി മെച്ചപ്പെടുത്താൻ സാധിച്ചു.

ഒടുവിൽ, പ്രധാന പ്രശ്നം ഡാറ്റാ സെൻ്റർ വേദനയില്ലാതെ നീക്കം ചെയ്യലായിരുന്നു.

ഒരു ഡിസിയുമായുള്ള ബന്ധം നഷ്ടപ്പെട്ട ഉടൻ ക്ലസ്റ്ററിൽ നിന്ന് ഞങ്ങൾക്ക് വേണ്ടത്:

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

അത് മാറിയതുപോലെ, ഞങ്ങൾക്ക് ഇതുപോലൊന്ന് വേണം:

ഞങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ലഭിച്ചു:

ഇത് എങ്ങനെ സംഭവിച്ചു?

ഡാറ്റാ സെൻ്റർ വീണപ്പോൾ, ഞങ്ങളുടെ യജമാനൻ തടസ്സമായി.

എന്തുകൊണ്ട്?

ക്ലസ്റ്ററിലെ ചില ടാസ്‌ക്കുകളും ഇവൻ്റുകളും വിതരണം ചെയ്യുന്നതിന് മാസ്റ്ററിന് ഒരു ടാസ്ക്ബാച്ചർ ഉണ്ട് എന്നതാണ് വസ്തുത. ഏതെങ്കിലും നോഡ് എക്സിറ്റ്, പകർപ്പിൽ നിന്ന് പ്രൈമറിയിലേക്ക് ഒരു ഷാർഡിൻ്റെ ഏത് പ്രമോഷനും, എവിടെയെങ്കിലും ഒരു ഷാർഡ് സൃഷ്ടിക്കുന്നതിനുള്ള ഏത് ജോലിയും - ഇതെല്ലാം ആദ്യം ടാസ്ക്ബാച്ചറിലേക്ക് പോകുന്നു, അവിടെ അത് തുടർച്ചയായും ഒരു ത്രെഡിലും പ്രോസസ്സ് ചെയ്യുന്നു.

ഒരു ഡാറ്റാ സെൻ്റർ പിൻവലിക്കുന്ന സമയത്ത്, നിലനിൽക്കുന്ന ഡാറ്റാ സെൻ്ററുകളിലെ എല്ലാ ഡാറ്റാ നോഡുകളും "ഞങ്ങൾക്ക് അത്തരം ചില്ലുകളും അത്തരം ഡാറ്റ നോഡുകളും നഷ്ടപ്പെട്ടു" എന്ന് മാസ്റ്ററെ അറിയിക്കേണ്ടത് തങ്ങളുടെ കടമയാണെന്ന് കണ്ടെത്തി.

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

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

ഞങ്ങൾ അളവുകൾ എടുത്തു, ഇത് പരിഹരിച്ച പതിപ്പ് 6.4.0 ന് മുമ്പ്, ക്ലസ്റ്റർ പൂർണ്ണമായും അടച്ചുപൂട്ടുന്നതിന് 10-ൽ നിന്ന് 360 ഡാറ്റ നോഡുകൾ മാത്രം ഒരേസമയം ഔട്ട്പുട്ട് ചെയ്താൽ മതിയായിരുന്നു.

ഇത് ഇതുപോലെ ഒന്ന് കാണപ്പെട്ടു:

ഈ ഭയാനകമായ ബഗ് പരിഹരിച്ച പതിപ്പ് 6.4.0 ന് ശേഷം, ഡാറ്റ നോഡുകൾ മാസ്റ്ററെ കൊല്ലുന്നത് നിർത്തി. എന്നാൽ അത് അവനെ "സ്മാർട്ടർ" ആക്കിയില്ല. അതായത്: നമ്മൾ 2, 3 അല്ലെങ്കിൽ 10 (ഒന്നല്ലാതെ മറ്റേതെങ്കിലും നമ്പർ) ഡാറ്റാ നോഡുകൾ ഔട്ട്‌പുട്ട് ചെയ്യുമ്പോൾ, നോഡ് എ ഉപേക്ഷിച്ചുവെന്ന് പറയുന്ന ചില ആദ്യ സന്ദേശം മാസ്റ്ററിന് ലഭിക്കുന്നു, കൂടാതെ നോഡ് ബി, നോഡ് സി, നോഡ് ഡി എന്നിവയെക്കുറിച്ച് പറയാൻ ശ്രമിക്കുന്നു.

ഇപ്പോൾ, ഏകദേശം 20-30 സെക്കൻഡിന് തുല്യമായ എന്തെങ്കിലും ആരോടെങ്കിലും പറയാനുള്ള ശ്രമങ്ങൾക്ക് സമയപരിധി സജ്ജീകരിച്ച് മാത്രമേ ഇത് കൈകാര്യം ചെയ്യാൻ കഴിയൂ, അങ്ങനെ ക്ലസ്റ്ററിന് പുറത്തേക്ക് നീങ്ങുന്ന ഡാറ്റാ സെൻ്ററിൻ്റെ വേഗത നിയന്ത്രിക്കുക.

തത്വത്തിൽ, പ്രോജക്റ്റിൻ്റെ ഭാഗമായി അന്തിമ ഉൽപ്പന്നത്തിലേക്ക് ആദ്യം അവതരിപ്പിച്ച ആവശ്യകതകളുമായി ഇത് യോജിക്കുന്നു, എന്നാൽ "ശുദ്ധമായ ശാസ്ത്രത്തിൻ്റെ" വീക്ഷണകോണിൽ ഇത് ഒരു ബഗ് ആണ്. ഏത്, വഴി, പതിപ്പ് 7.2 ൽ ഡവലപ്പർമാർ വിജയകരമായി പരിഹരിച്ചു.

മാത്രമല്ല, ഒരു നിശ്ചിത ഡാറ്റാ നോഡ് പുറത്തുപോയപ്പോൾ, അതിൻ്റെ എക്സിറ്റ് സംബന്ധിച്ച വിവരങ്ങൾ പ്രചരിപ്പിക്കുന്നത് മുഴുവൻ ക്ലസ്റ്ററിനോടും പറയുന്നതിനേക്കാൾ പ്രധാനമാണെന്ന് തെളിഞ്ഞു പ്രാഥമിക കേന്ദ്രത്തിലും വിവരങ്ങളിലും അവയിൽ എഴുതാം).

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

തൽഫലമായി, ഇന്ന് ഒരു ഡാറ്റാ സെൻ്റർ പിൻവലിക്കാനുള്ള പ്രവർത്തനത്തിന് തിരക്കുള്ള സമയത്ത് ഏകദേശം 5 മിനിറ്റ് എടുക്കും. ഇത്രയും വലുതും വിചിത്രവുമായ കൊളോസസിന്, ഇത് വളരെ നല്ല ഫലമാണ്.

തൽഫലമായി, ഞങ്ങൾ ഇനിപ്പറയുന്ന തീരുമാനത്തിലെത്തി:

• ഞങ്ങൾക്ക് 360 ജിഗാബൈറ്റ് ഡിസ്കുകളുള്ള 700 ഡാറ്റ നോഡുകൾ ഉണ്ട്.
• ഇതേ ഡാറ്റ നോഡുകളിലൂടെ ട്രാഫിക് റൂട്ട് ചെയ്യുന്നതിനുള്ള 60 കോർഡിനേറ്റർമാർ.
• 40-ന് മുമ്പുള്ള പതിപ്പുകൾ മുതൽ ഞങ്ങൾ ഒരുതരം പാരമ്പര്യമായി അവശേഷിപ്പിച്ച 6.4.0 മാസ്റ്റർമാർ - ഡാറ്റാ സെൻ്റർ പിൻവലിക്കലിനെ അതിജീവിക്കാൻ, മാസ്റ്റേഴ്സിൻ്റെ കോറം ഉണ്ടെന്ന് ഉറപ്പുനൽകുന്നതിനായി നിരവധി മെഷീനുകൾ നഷ്ടപ്പെടുത്താൻ ഞങ്ങൾ മാനസികമായി തയ്യാറായിരുന്നു. ഏറ്റവും മോശം സാഹചര്യം
• ഒരു കണ്ടെയ്‌നറിൽ റോളുകൾ സംയോജിപ്പിക്കാനുള്ള ഏതൊരു ശ്രമവും എത്രയും വേഗം അല്ലെങ്കിൽ പിന്നീട് നോഡ് ലോഡിന് കീഴിൽ തകരുമെന്ന വസ്തുതയെ അഭിമുഖീകരിച്ചു.
• മുഴുവൻ ക്ലസ്റ്ററും 31 ജിഗാബൈറ്റിൻ്റെ ഹീപ്പ്.സൈസ് ഉപയോഗിക്കുന്നു: വലുപ്പം കുറയ്ക്കാനുള്ള എല്ലാ ശ്രമങ്ങളും മുൻനിര വൈൽഡ്കാർഡ് ഉപയോഗിച്ചുള്ള കനത്ത തിരയൽ അന്വേഷണങ്ങളിൽ ചില നോഡുകളെ നശിപ്പിക്കുന്നതിനോ അല്ലെങ്കിൽ ഇലാസ്റ്റിക് സെർച്ചിൽ തന്നെ സർക്യൂട്ട് ബ്രേക്കർ ലഭിക്കുന്നതിനോ കാരണമായി.
• കൂടാതെ, തിരയൽ പ്രകടനം ഉറപ്പാക്കാൻ, ക്ലസ്റ്ററിലെ ഒബ്‌ജക്റ്റുകളുടെ എണ്ണം കഴിയുന്നത്ര ചെറുതാക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു, മാസ്റ്ററിൽ ഞങ്ങൾക്ക് ലഭിച്ച തടസ്സത്തിൽ കഴിയുന്നത്ര കുറച്ച് ഇവൻ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന്.

ഒടുവിൽ നിരീക്ഷണത്തെക്കുറിച്ച്

ഇതെല്ലാം ഉദ്ദേശിച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ, ഞങ്ങൾ ഇനിപ്പറയുന്നവ നിരീക്ഷിക്കുന്നു:

• ഓരോ ഡാറ്റാ നോഡും അത് നിലവിലുണ്ടെന്ന് ഞങ്ങളുടെ ക്ലൗഡിലേക്ക് റിപ്പോർട്ടുചെയ്യുന്നു, അതിൽ അത്തരം കഷണങ്ങൾ ഉണ്ട്. നമ്മൾ എവിടെയെങ്കിലും എന്തെങ്കിലും കെടുത്തിക്കളയുമ്പോൾ, 2-3 സെക്കൻഡുകൾക്ക് ശേഷം ക്ലസ്റ്റർ റിപ്പോർട്ട് ചെയ്യുന്നു, A കേന്ദ്രത്തിൽ ഞങ്ങൾ 2, 3, 4 എന്നീ നോഡുകൾ കെടുത്തി - ഇതിനർത്ഥം മറ്റ് ഡാറ്റാ സെൻ്ററുകളിൽ ഒരു കഷണം മാത്രമുള്ള നോഡുകൾ ഒരു സാഹചര്യത്തിലും കെടുത്തിക്കളയാൻ കഴിയില്ല എന്നാണ്. ഇടത്തെ.
• യജമാനൻ്റെ പെരുമാറ്റത്തിൻ്റെ സ്വഭാവം അറിയുന്നത്, തീർപ്പാക്കാത്ത ജോലികളുടെ എണ്ണം ഞങ്ങൾ വളരെ ശ്രദ്ധാപൂർവ്വം നോക്കുന്നു. കാരണം, ഒരു സ്റ്റക്ക് ടാസ്‌ക് പോലും, അത് സമയബന്ധിതമായി തീർന്നില്ലെങ്കിൽ, സൈദ്ധാന്തികമായി ചില അടിയന്തിര സാഹചര്യങ്ങളിൽ, ഉദാഹരണത്തിന്, പ്രൈമറിയിലെ ഒരു പകർപ്പ് ഷാർഡിൻ്റെ പ്രമോഷൻ പ്രവർത്തിക്കാത്തതിൻ്റെ കാരണമായി മാറിയേക്കാം, അതിനാലാണ് ഇൻഡക്‌സിംഗ് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നത്.
• ഒപ്റ്റിമൈസേഷൻ സമയത്ത് ഞങ്ങൾക്ക് ഇതിനകം തന്നെ വലിയ ബുദ്ധിമുട്ടുകൾ നേരിട്ടതിനാൽ, മാലിന്യം ശേഖരിക്കുന്നവരുടെ കാലതാമസവും ഞങ്ങൾ വളരെ സൂക്ഷ്മമായി നിരീക്ഷിക്കുന്നു.
• തടസ്സം എവിടെയാണെന്ന് മുൻകൂട്ടി മനസ്സിലാക്കാൻ ത്രെഡ് വഴി നിരസിക്കുന്നു.
• ശരി, ഹീപ്പ്, റാം, I/O എന്നിവ പോലുള്ള സ്റ്റാൻഡേർഡ് മെട്രിക്കുകൾ.

മോണിറ്ററിംഗ് നിർമ്മിക്കുമ്പോൾ, ഇലാസ്റ്റിക് സെർച്ചിലെ ത്രെഡ് പൂളിൻ്റെ സവിശേഷതകൾ നിങ്ങൾ കണക്കിലെടുക്കണം. ഇലാസ്റ്റിക് സെർച്ച് ഡോക്യുമെൻ്റേഷൻ കോൺഫിഗറേഷൻ ഓപ്‌ഷനുകളും തിരയലിനും ഇൻഡെക്‌സിംഗിനുമുള്ള ഡിഫോൾട്ട് മൂല്യങ്ങൾ വിവരിക്കുന്നു, പക്ഷേ thread_pool.management-നെ കുറിച്ച് പൂർണ്ണമായും നിശബ്ദമാണ്, ഈ ത്രെഡുകൾ പ്രോസസ്സ് ചെയ്യുന്നു, പ്രത്യേകിച്ചും, _cat/shards പോലുള്ള ചോദ്യങ്ങളും മറ്റ് സമാനമായവയും, നിരീക്ഷണം എഴുതുമ്പോൾ ഉപയോഗിക്കാൻ സൗകര്യപ്രദമാണ്. വലിയ ക്ലസ്റ്റർ, ഓരോ യൂണിറ്റ് സമയത്തിനും അത്തരം കൂടുതൽ അഭ്യർത്ഥനകൾ നടപ്പിലാക്കുന്നു, കൂടാതെ മേൽപ്പറഞ്ഞ Thread_pool.management ഔദ്യോഗിക ഡോക്യുമെൻ്റേഷനിൽ അവതരിപ്പിക്കപ്പെടുക മാത്രമല്ല, സ്ഥിരസ്ഥിതിയായി 5 ത്രെഡുകളിലേക്ക് പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നു, അത് വളരെ വേഗത്തിൽ നീക്കം ചെയ്യപ്പെടും. ഏത് നിരീക്ഷണം ശരിയായി പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു.

ഉപസംഹാരമായി ഞാൻ പറയാൻ ആഗ്രഹിക്കുന്നത്: ഞങ്ങൾ അത് ചെയ്തു! ഞങ്ങളുടെ പ്രോഗ്രാമർമാർക്കും ഡവലപ്പർമാർക്കും, ഏത് സാഹചര്യത്തിലും, ഉൽപ്പാദനത്തിൽ എന്താണ് സംഭവിക്കുന്നത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ വേഗത്തിലും വിശ്വസനീയമായും നൽകാൻ കഴിയുന്ന ഒരു ഉപകരണം നൽകാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു.

അതെ, ഇത് വളരെ സങ്കീർണ്ണമായി മാറി, എന്നിരുന്നാലും, നിലവിലുള്ള ഉൽപ്പന്നങ്ങളിലേക്ക് ഞങ്ങളുടെ ആഗ്രഹങ്ങൾ ഉൾക്കൊള്ളാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു, അത് ഞങ്ങൾക്കായി പാച്ച് ചെയ്ത് മാറ്റിയെഴുതേണ്ടതില്ല.

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