TL;DR: நான்கு ஆண்டுகளுக்கு முன்பு, புதிய சர்வர் கண்காணிப்பு கருவிக்கான யோசனையுடன் Google ஐ விட்டுவிட்டேன். பொதுவாக தனிமைப்படுத்தப்பட்ட செயல்பாடுகளை ஒரு சேவையாக இணைப்பதே யோசனை சேகரிப்பு மற்றும் பதிவு பகுப்பாய்வு, அளவீடுகள் சேகரிப்பு, எச்சரிக்கைகள் மற்றும் டாஷ்போர்டுகள். சேவை உண்மையாக இருக்க வேண்டும் என்பது கொள்கைகளில் ஒன்று வேகமாக, டெவொப்களுக்கு எளிதான, ஊடாடும், மகிழ்ச்சிகரமான அனுபவத்தை வழங்குகிறது. பட்ஜெட்டுக்குள் இருக்கும் போது, ​​மல்டி-ஜிகாபைட் தரவுத் தொகுப்புகளை ஒரு நொடியின் பின்னங்களில் செயலாக்க வேண்டும். தற்போதுள்ள பதிவு மேலாண்மை கருவிகள் பெரும்பாலும் மெதுவாகவும் குழப்பமாகவும் இருக்கும், எனவே நாங்கள் ஒரு நல்ல சவாலை எதிர்கொண்டோம்: பயனர்களுக்கு புதிய அனுபவத்தை வழங்க ஒரு கருவியை புத்திசாலித்தனமாக வடிவமைத்தல்.

பழைய பள்ளி முறைகள், முரட்டுத்தனமான அணுகுமுறை, தேவையற்ற அடுக்குகளை நீக்குதல் மற்றும் சிக்கலான தரவு கட்டமைப்புகளைத் தவிர்ப்பதன் மூலம் ஸ்கேலிரில் நாங்கள் இந்த சிக்கலை எவ்வாறு தீர்த்தோம் என்பதை இந்தக் கட்டுரை விவரிக்கிறது. இந்த பாடங்களை உங்கள் சொந்த பொறியியல் சிக்கல்களுக்குப் பயன்படுத்தலாம்.

பழைய பள்ளி சக்தி

பதிவு பகுப்பாய்வு பொதுவாக ஒரு தேடலுடன் தொடங்குகிறது: ஒரு குறிப்பிட்ட வடிவத்துடன் பொருந்தக்கூடிய அனைத்து செய்திகளையும் கண்டறியவும். Scalyr இல், இவை பல சேவையகங்களிலிருந்து பத்து அல்லது நூற்றுக்கணக்கான ஜிகாபைட் பதிவுகள். நவீன அணுகுமுறைகள், ஒரு விதியாக, தேடலுக்கு உகந்ததாக சில சிக்கலான தரவு கட்டமைப்பை உருவாக்குவதை உள்ளடக்கியது. நான் நிச்சயமாக இதை கூகிளில் பார்த்திருக்கிறேன், அங்கு அவர்கள் இந்த வகையான விஷயங்களில் நல்லவர்கள். ஆனால் நாங்கள் மிகவும் கடினமான அணுகுமுறையில் குடியேறினோம்: பதிவுகளின் நேரியல் ஸ்கேனிங். அது வேலை செய்தது - நாங்கள் தேடக்கூடிய இடைமுகத்தை வழங்குகிறோம், இது எங்கள் போட்டியாளர்களை விட வேகமான ஆர்டர்களைக் கொண்டுள்ளது (இறுதியில் அனிமேஷனைப் பார்க்கவும்).

முக்கிய நுண்ணறிவு என்னவென்றால், நவீன செயலிகள் உண்மையில் எளிமையான, நேரடியான செயல்பாடுகளில் மிக வேகமாக இருக்கும். I/O வேகம் மற்றும் நெட்வொர்க் செயல்பாடுகளை நம்பியிருக்கும் சிக்கலான, பல அடுக்கு அமைப்புகளில் இதைத் தவறவிடுவது எளிது, மேலும் இதுபோன்ற அமைப்புகள் இன்று மிகவும் பொதுவானவை. எனவே அடுக்குகள் மற்றும் அதிகப்படியான குப்பைகளை குறைக்கும் வடிவமைப்பை நாங்கள் உருவாக்கினோம். பல செயலிகள் மற்றும் சேவையகங்களுடன் இணையாக, தேடல் வேகம் வினாடிக்கு 1 TB ஐ அடைகிறது.

இந்த கட்டுரையில் இருந்து முக்கிய குறிப்புகள்:

• ப்ரூட்-ஃபோர்ஸ் தேடல் என்பது நிஜ உலக, பெரிய அளவிலான சிக்கல்களைத் தீர்ப்பதற்கான ஒரு சாத்தியமான அணுகுமுறையாகும்.
• ப்ரூட் ஃபோர்ஸ் என்பது ஒரு வடிவமைப்பு நுட்பம், வேலை இல்லாத தீர்வு அல்ல. எந்தவொரு நுட்பத்தையும் போலவே, இது மற்றவர்களை விட சில சிக்கல்களுக்கு மிகவும் பொருத்தமானது, மேலும் மோசமாக அல்லது நன்றாக செயல்படுத்தப்படலாம்.
• முரட்டு சக்தி குறிப்பாக சாதிக்க நல்லது நிலையான உற்பத்தித்திறன்.
• ப்ரூட் ஃபோர்ஸை திறம்பட பயன்படுத்த, குறியீட்டை மேம்படுத்துதல் மற்றும் சரியான நேரத்தில் போதுமான ஆதாரங்களைப் பயன்படுத்துவது அவசியம். உங்கள் சேவையகங்கள் அதிக பயனர் அல்லாத சுமையில் இருந்தால் மற்றும் பயனர் செயல்பாடுகள் முன்னுரிமையாக இருந்தால் இது பொருத்தமானது.
• செயல்திறன் உள் லூப் அல்காரிதம் மட்டுமல்ல, முழு அமைப்பின் வடிவமைப்பைப் பொறுத்தது.

(இந்த கட்டுரை நினைவகத்தில் தரவைத் தேடுவதை விவரிக்கிறது. பெரும்பாலான சந்தர்ப்பங்களில், ஒரு பயனர் பதிவுத் தேடலைச் செய்யும்போது, ​​Scalyr சேவையகங்கள் அதை ஏற்கனவே தேக்ககப்படுத்தியுள்ளன. அடுத்த கட்டுரையில் சேமிக்கப்படாத பதிவுகளைத் தேடுவது பற்றி விவாதிக்கப்படும். அதே கொள்கைகள் பொருந்தும்: திறமையான குறியீடு, முரட்டு சக்தி பெரிய கணக்கீட்டு வளங்களுடன்).

ப்ரூட் ஃபோர்ஸ் முறை

பாரம்பரியமாக, ஒரு பெரிய தரவுத் தொகுப்பு ஒரு முக்கிய குறியீட்டைப் பயன்படுத்தி தேடப்படுகிறது. சேவையகப் பதிவுகளுக்குப் பயன்படுத்தும்போது, ​​பதிவில் உள்ள ஒவ்வொரு தனிப்பட்ட வார்த்தையையும் தேடுவது இதன் பொருள். ஒவ்வொரு வார்த்தைக்கும், நீங்கள் அனைத்து சேர்த்தல்களின் பட்டியலை உருவாக்க வேண்டும். இந்த வார்த்தையுடன் அனைத்து செய்திகளையும் எளிதாகக் கண்டறியலாம், எடுத்துக்காட்டாக, 'பிழை', 'ஃபயர்பாக்ஸ்' அல்லது "பரிவர்த்தனை_16851951" - குறியீட்டில் பாருங்கள்.

நான் இந்த அணுகுமுறையை Google இல் பயன்படுத்தினேன், அது நன்றாக வேலை செய்தது. ஆனால் Scalyrல் நாம் logs byteஐ byte மூலம் தேடுகிறோம்.

ஏன்? சுருக்கமான அல்காரிதம் பார்வையில், முக்கிய குறியீடுகள் முரட்டுத்தனமான தேடல்களை விட மிகவும் திறமையானவை. இருப்பினும், நாங்கள் அல்காரிதம்களை விற்கவில்லை, செயல்திறனை விற்கிறோம். மேலும் செயல்திறன் என்பது அல்காரிதம்களைப் பற்றியது மட்டுமல்ல, சிஸ்டம்ஸ் இன்ஜினியரிங் பற்றியது. நாம் எல்லாவற்றையும் கருத்தில் கொள்ள வேண்டும்: தரவு அளவு, தேடலின் வகை, கிடைக்கக்கூடிய வன்பொருள் மற்றும் மென்பொருள் சூழல். எங்கள் குறிப்பிட்ட பிரச்சனைக்கு, குறியீட்டை விட 'grep' போன்றது மிகவும் பொருத்தமானது என்று முடிவு செய்தோம்.

குறியீடுகள் சிறந்தவை, ஆனால் அவற்றுக்கு வரம்புகள் உள்ளன. ஒரு வார்த்தை கண்டுபிடிக்க எளிதானது. ஆனால் 'googlebot' மற்றும் '404' போன்ற பல வார்த்தைகளைக் கொண்ட செய்திகளைத் தேடுவது மிகவும் கடினம். 'பிடிக்கப்படாத விதிவிலக்கு' போன்ற சொற்றொடரைத் தேட, அந்த வார்த்தையுடன் அனைத்து செய்திகளையும் பதிவுசெய்யும், ஆனால் வார்த்தையின் குறிப்பிட்ட இடத்தையும் பதிவுசெய்யும் மிகவும் சிக்கலான குறியீடு தேவைப்படுகிறது.

நீங்கள் வார்த்தைகளைத் தேடாதபோது உண்மையான சிரமம் வருகிறது. போட்களில் இருந்து எவ்வளவு ட்ராஃபிக் வருகிறது என்பதைப் பார்க்க வேண்டும் என்று வைத்துக்கொள்வோம். முதல் எண்ணம் 'போட்' என்ற வார்த்தைக்கான பதிவுகளைத் தேடுவது. இப்படித்தான் நீங்கள் சில போட்களைக் காணலாம்: Googlebot, Bingbot மற்றும் பல. ஆனால் இங்கே 'போட்' என்பது ஒரு வார்த்தை அல்ல, ஆனால் அதன் ஒரு பகுதி. குறியீட்டில் 'bot' என்று தேடினால், 'Googlebot' என்ற வார்த்தையுடன் எந்த இடுகைகளையும் காண முடியாது. குறியீட்டில் உள்ள ஒவ்வொரு வார்த்தையையும் சரிபார்த்து, பின்னர் காணப்படும் முக்கிய வார்த்தைகளுக்கான குறியீட்டை ஸ்கேன் செய்தால், தேடல் வெகுவாகக் குறையும். இதன் விளைவாக, சில பதிவு நிரல்கள் பகுதி-சொல் தேடல்களை அனுமதிக்காது அல்லது (சிறந்தது) குறைந்த செயல்திறன் கொண்ட சிறப்பு தொடரியல் அனுமதிக்கும். இதைத் தவிர்க்க விரும்புகிறோம்.

மற்றொரு சிக்கல் நிறுத்தற்குறிகள். இலிருந்து அனைத்து கோரிக்கைகளையும் கண்டறிய விரும்புகிறீர்களா 50.168.29.7? பிழைத்திருத்தம் கொண்ட பதிவுகள் பற்றி என்ன [error]? சப்ஸ்கிரிப்டுகள் பொதுவாக நிறுத்தற்குறிகளைத் தவிர்க்கும்.

இறுதியாக, பொறியியலாளர்கள் சக்திவாய்ந்த கருவிகளை விரும்புகிறார்கள், சில சமயங்களில் ஒரு சிக்கலை வழக்கமான வெளிப்பாடு மூலம் மட்டுமே தீர்க்க முடியும். முக்கிய குறியீடு இதற்கு மிகவும் பொருத்தமானது அல்ல.

கூடுதலாக, குறியீடுகள் சிக்கலான. ஒவ்வொரு செய்தியும் பல முக்கிய வார்த்தை பட்டியல்களில் சேர்க்கப்பட வேண்டும். இந்தப் பட்டியல்கள் எல்லா நேரங்களிலும் எளிதில் தேடக்கூடிய வடிவத்தில் வைக்கப்பட வேண்டும். சொற்றொடர்கள், வார்த்தை துண்டுகள் அல்லது வழக்கமான வெளிப்பாடுகள் கொண்ட வினவல்கள் பல பட்டியல் செயல்பாடுகளாக மொழிபெயர்க்கப்பட வேண்டும், மேலும் முடிவுகளை ஸ்கேன் செய்து ஒருங்கிணைத்து முடிவு தொகுப்பை உருவாக்க வேண்டும். ஒரு பெரிய அளவிலான, பல குத்தகைதாரர் சேவையின் பின்னணியில், இந்த சிக்கலானது, அல்காரிதம்களை பகுப்பாய்வு செய்யும் போது தெரியாத செயல்திறன் சிக்கல்களை உருவாக்குகிறது.

முக்கிய குறியீடுகள் அதிக இடத்தை எடுத்துக்கொள்கின்றன, மேலும் பதிவு மேலாண்மை அமைப்பில் சேமிப்பகம் ஒரு பெரிய செலவாகும்.

மறுபுறம், ஒவ்வொரு தேடலும் நிறைய கணினி சக்தியை உட்கொள்ளும். தனித்துவமான வினவல்களுக்கான அதிவேகத் தேடல்களை எங்கள் பயனர்கள் பாராட்டுகிறார்கள், ஆனால் இதுபோன்ற வினவல்கள் ஒப்பீட்டளவில் அரிதாகவே செய்யப்படுகின்றன. வழக்கமான தேடல் வினவல்களுக்கு, எடுத்துக்காட்டாக, டாஷ்போர்டுக்கு, நாங்கள் சிறப்பு நுட்பங்களைப் பயன்படுத்துகிறோம் (அவற்றை அடுத்த கட்டுரையில் விவரிப்போம்). மற்ற கோரிக்கைகள் மிகவும் அரிதாகவே உள்ளன, நீங்கள் ஒரு நேரத்தில் ஒன்றுக்கு மேற்பட்டவற்றைச் செயலாக்குவது அரிது. ஆனால் இது எங்கள் சேவையகங்கள் பிஸியாக இல்லை என்று அர்த்தமல்ல: அவை புதிய செய்திகளைப் பெறுதல், பகுப்பாய்வு செய்தல் மற்றும் சுருக்குதல், விழிப்பூட்டல்களை மதிப்பீடு செய்தல், பழைய தரவை சுருக்குதல் மற்றும் பலவற்றில் பிஸியாக உள்ளன. எனவே, வினவல்களை இயக்கப் பயன்படும் செயலிகளின் குறிப்பிடத்தக்க விநியோகம் எங்களிடம் உள்ளது.

உங்களுக்கு முரட்டுத்தனமான பிரச்சனை இருந்தால் ப்ரூட் ஃபோர்ஸ் வேலை செய்யும் (மற்றும் அதிக சக்தி)

சிறிய உள் சுழல்கள் கொண்ட எளிய பிரச்சனைகளில் ப்ரூட் ஃபோர்ஸ் சிறப்பாக செயல்படுகிறது. பெரும்பாலும் நீங்கள் மிக அதிக வேகத்தில் இயக்க உள் வளையத்தை மேம்படுத்தலாம். குறியீடு சிக்கலானதாக இருந்தால், அதை மேம்படுத்துவது மிகவும் கடினம்.

எங்கள் தேடல் குறியீடு முதலில் ஒரு பெரிய உள் சுழற்சியைக் கொண்டிருந்தது. செய்திகளை 4K இல் பக்கங்களில் சேமிக்கிறோம்; ஒவ்வொரு பக்கத்திலும் சில செய்திகள் (UTF-8 இல்) மற்றும் ஒவ்வொரு செய்திக்கும் மெட்டாடேட்டா உள்ளது. மெட்டாடேட்டா என்பது மதிப்பு, உள் செய்தி ஐடி மற்றும் பிற புலங்களின் நீளத்தை குறியாக்கம் செய்யும் கட்டமைப்பாகும். தேடல் சுழற்சி இப்படி இருந்தது:

இது உண்மையான குறியீட்டின் எளிமைப்படுத்தப்பட்ட பதிப்பாகும். ஆனால் இங்கே கூட, பல பொருள் இடங்கள், தரவு நகல் மற்றும் செயல்பாட்டு அழைப்புகள் தெரியும். செயல்பாட்டு அழைப்புகளை மேம்படுத்துவதிலும், இடைக்கால பொருட்களை ஒதுக்குவதிலும் JVM மிகவும் சிறப்பாக உள்ளது, எனவே இந்த குறியீடு நாம் தகுதியானதை விட சிறப்பாக செயல்பட்டது. சோதனையின் போது, ​​வாடிக்கையாளர்கள் அதை மிகவும் வெற்றிகரமாக பயன்படுத்தினர். ஆனால் இறுதியில் அதை அடுத்த கட்டத்திற்கு கொண்டு சென்றோம்.

(பதிவுகளுடன் நேரடியாக வேலை செய்வதை விட, 4K பக்கங்கள், உரை மற்றும் மெட்டாடேட்டாவுடன் இந்த வடிவத்தில் செய்திகளை ஏன் சேமிக்கிறோம் என்று நீங்கள் கேட்கலாம். Scalyr இன்ஜின் ஒரு விநியோகிக்கப்பட்ட தரவுத்தளத்தை விட உள்நாட்டில் அதிகமாக உள்ளது என்பதற்கு பல காரணங்கள் உள்ளன. கோப்பு முறைமை, லாக் பாகுபடுத்தலுக்குப் பிறகு ஓரங்களில் உள்ள டிபிஎம்எஸ்-பாணி வடிப்பான்களுடன் உரைத் தேடல் பெரும்பாலும் இணைக்கப்படுகிறது. ஒரே நேரத்தில் பல ஆயிரக்கணக்கான பதிவுகளை ஒரே நேரத்தில் தேடலாம், மேலும் எளிமையான உரைக் கோப்புகள் நமது பரிவர்த்தனை, பிரதி, விநியோகிக்கப்பட்ட தரவு மேலாண்மைக்கு ஏற்றவை அல்ல).

ஆரம்பத்தில், அத்தகைய குறியீடு முரட்டுத்தனமான தேர்வுமுறைக்கு மிகவும் பொருத்தமானது அல்ல என்று தோன்றியது. "உண்மையான வேலை" இல் String.indexOf() CPU சுயவிவரத்தில் கூட ஆதிக்கம் செலுத்தவில்லை. அதாவது, இந்த முறையை மட்டும் மேம்படுத்துவது குறிப்பிடத்தக்க விளைவைக் கொண்டுவராது.

ஒவ்வொரு பக்கத்தின் தொடக்கத்திலும் மெட்டாடேட்டாவை சேமித்து வைக்கிறோம், மேலும் UTF-8 இல் உள்ள அனைத்து செய்திகளின் உரையும் மறுமுனையில் நிரம்பியுள்ளது. இதைப் பயன்படுத்தி, முழுப் பக்கத்தையும் ஒரே நேரத்தில் தேட, சுழற்சியை மீண்டும் எழுதினோம்:

இந்த பதிப்பு பார்வையில் நேரடியாக வேலை செய்கிறது raw byte[] மேலும் 4K பக்கம் முழுவதும் ஒரே நேரத்தில் அனைத்து செய்திகளையும் தேடுகிறது.

ப்ரூட் ஃபோர்ஸ் முறையை மேம்படுத்த இது மிகவும் எளிதானது. ஒவ்வொரு இடுகையிலும் தனித்தனியாக இல்லாமல், முழு 4K பக்கத்திற்கும் உள்ளக தேடல் வளையம் ஒரே நேரத்தில் அழைக்கப்படுகிறது. தரவை நகலெடுப்பது இல்லை, பொருள்களின் ஒதுக்கீடு இல்லை. மேலும் சிக்கலான மெட்டாடேட்டா செயல்பாடுகள் முடிவு நேர்மறையாக இருக்கும்போது மட்டுமே அழைக்கப்படும், ஒவ்வொரு செய்தியிலும் அல்ல. இந்த வழியில் நாங்கள் ஒரு டன் மேல்நிலையை அகற்றிவிட்டோம், மீதமுள்ள சுமை ஒரு சிறிய உள் தேடல் வளையத்தில் குவிந்துள்ளது, இது மேலும் மேம்படுத்தலுக்கு மிகவும் பொருத்தமானது.

எங்கள் உண்மையான தேடல் அல்காரிதம் அடிப்படையாக கொண்டது லியோனிட் வோல்னிட்ஸ்கியின் சிறந்த யோசனை. இது Boyer-Moore அல்காரிதம் போன்றது, ஒவ்வொரு அடியிலும் தேடல் சரத்தின் நீளத்தை தோராயமாக தவிர்க்கிறது. முக்கிய வேறுபாடு என்னவென்றால், தவறான பொருத்தங்களைக் குறைக்க ஒரே நேரத்தில் இரண்டு பைட்டுகளைச் சரிபார்க்கிறது.

எங்கள் செயலாக்கத்திற்கு ஒவ்வொரு தேடலுக்கும் 64K தேடல் அட்டவணையை உருவாக்க வேண்டும், ஆனால் நாங்கள் தேடும் ஜிகாபைட் தரவுகளுடன் ஒப்பிடும்போது இது ஒன்றும் இல்லை. உள் வளையமானது ஒரு மையத்தில் வினாடிக்கு பல ஜிகாபைட்களை செயலாக்குகிறது. நடைமுறையில், ஒவ்வொரு மையத்திலும் நிலையான செயல்திறன் வினாடிக்கு 1,25 ஜிபி ஆகும், மேலும் முன்னேற்றத்திற்கான இடமும் உள்ளது. உள் சுழலுக்கு வெளியே உள்ள சில மேல்நிலைகளை அகற்றுவது சாத்தியம், மேலும் ஜாவாவிற்கு பதிலாக C இல் உள் சுழற்சியை பரிசோதிக்க திட்டமிட்டுள்ளோம்.

நாங்கள் சக்தியைப் பயன்படுத்துகிறோம்

பதிவு தேடலை "தோராயமாக" செயல்படுத்தலாம் என்று நாங்கள் விவாதித்தோம், ஆனால் நம்மிடம் எவ்வளவு "சக்தி" உள்ளது? நிறைய.

1 கோர்: சரியாகப் பயன்படுத்தும் போது, ​​ஒரு நவீன செயலியின் ஒற்றை மையமானது அதன் சொந்த உரிமையில் மிகவும் சக்தி வாய்ந்தது.

8 கோர்கள்: நாங்கள் தற்போது Amazon hi1.4xlarge மற்றும் i2.4xlarge SSD சேவையகங்களில் இயங்கி வருகிறோம், ஒவ்வொன்றும் 8 கோர்கள் (16 நூல்கள்) கொண்டவை. மேலே குறிப்பிட்டுள்ளபடி, இந்த கோர்கள் பொதுவாக பின்னணி செயல்பாடுகளில் பிஸியாக இருக்கும். பயனர் தேடலைச் செய்யும்போது, ​​பின்னணி செயல்பாடுகள் இடைநிறுத்தப்பட்டு, தேடலுக்கான அனைத்து 8 கோர்களையும் விடுவிக்கும். தேடல் பொதுவாக ஒரு பிளவு வினாடியில் முடிவடைகிறது, அதன் பிறகு பின்னணி வேலை மீண்டும் தொடங்கும் (திராட்லிங் நிரல் தேடல் வினவல்களின் சரமாரியானது முக்கியமான பின்னணி வேலைகளில் தலையிடாது என்பதை உறுதி செய்கிறது).

16 கோர்கள்: நம்பகத்தன்மைக்காக, நாங்கள் சர்வர்களை மாஸ்டர்/ஸ்லேவ் குழுக்களாக ஒழுங்கமைக்கிறோம். ஒவ்வொரு மாஸ்டருக்கும் அவரது கட்டளையின் கீழ் ஒரு SSD மற்றும் ஒரு EBS சர்வர் உள்ளது. பிரதான சேவையகம் செயலிழந்தால், SSD சேவையகம் உடனடியாக அதன் இடத்தைப் பிடிக்கும். கிட்டத்தட்ட எல்லா நேரத்திலும், மாஸ்டர் மற்றும் ஸ்லேவ் நன்றாக வேலை செய்கிறார்கள், இதனால் ஒவ்வொரு தரவுத் தொகுதியும் இரண்டு வெவ்வேறு சர்வர்களில் தேடக்கூடியதாக இருக்கும் (EBS ஸ்லேவ் சர்வரில் பலவீனமான செயலி உள்ளது, எனவே நாங்கள் அதைக் கருத்தில் கொள்ளவில்லை). அவற்றுக்கிடையே பணியை நாங்கள் பிரிக்கிறோம், இதனால் மொத்தம் 16 கோர்கள் கிடைக்கும்.

பல கோர்கள்: எதிர்காலத்தில், நாங்கள் சர்வர்கள் முழுவதும் டேட்டாவை விநியோகிப்போம், அவர்கள் அனைவரும் ஒவ்வொரு அற்பமான கோரிக்கையைச் செயல்படுத்துவதில் பங்கேற்கும் வகையில். ஒவ்வொரு மையமும் வேலை செய்யும். [குறிப்பு: நாங்கள் திட்டத்தை செயல்படுத்தி, தேடல் வேகத்தை 1 TB/s ஆக அதிகரித்தோம், கட்டுரையின் முடிவில் உள்ள குறிப்பைப் பார்க்கவும்].

எளிமை நம்பகத்தன்மையை உறுதி செய்கிறது

ப்ரூட் ஃபோர்ஸ் முறையின் மற்றொரு நன்மை அதன் மிகவும் சீரான செயல்திறன் ஆகும். பொதுவாக, சிக்கல் மற்றும் தரவுத் தொகுப்பின் விவரங்களுக்கு தேடல் மிகவும் உணர்திறன் இல்லை (அதனால்தான் இது "கரடு" என்று அழைக்கப்படுகிறது).

முக்கிய குறியீடு சில நேரங்களில் நம்பமுடியாத வேகமான முடிவுகளை உருவாக்குகிறது, மற்ற நேரங்களில் அது இல்லை. உங்களிடம் 50 ஜிபி பதிவுகள் உள்ளன, அதில் 'வாடிக்கையாளர்_5987235982' என்ற சொல் சரியாக மூன்று முறை தோன்றும். இந்தச் சொல்லுக்கான தேடலானது, குறியீட்டிலிருந்து நேரடியாக மூன்று இடங்களைக் கணக்கிடுகிறது மற்றும் உடனடியாக முடிவடையும். ஆனால் சிக்கலான வைல்டு கார்டு தேடல்கள் ஆயிரக்கணக்கான முக்கிய வார்த்தைகளை ஸ்கேன் செய்து நீண்ட நேரம் எடுக்கும்.

மறுபுறம், ப்ரூட் ஃபோர்ஸ் தேடல்கள் எந்த வினவலுக்கும் அதிகமாகவோ அல்லது குறைவாகவோ அதே வேகத்தில் செயல்படுகின்றன. நீண்ட சொற்களைத் தேடுவது சிறந்தது, ஆனால் ஒரு எழுத்தைத் தேடுவது கூட மிக வேகமாக இருக்கும்.

ப்ரூட் ஃபோர்ஸ் முறையின் எளிமை அதன் செயல்திறன் அதன் கோட்பாட்டு அதிகபட்சத்திற்கு அருகில் உள்ளது. எதிர்பாராத டிஸ்க் ஓவர்லோட்கள், லாக் கன்டெண்டிஷன், பாயிண்டர் சேஸிங் மற்றும் தோல்விக்கான ஆயிரக்கணக்கான காரணங்களுக்கு குறைவான விருப்பத்தேர்வுகள் உள்ளன. எங்கள் பரபரப்பான சேவையகத்தில் கடந்த வாரம் Scalyr பயனர்கள் செய்த கோரிக்கைகளைப் பார்த்தேன். 14 கோரிக்கைகள் வந்தன. அவர்களில் எட்டு பேர் ஒரு வினாடிக்கு மேல் எடுத்தனர்; 000% 99 மில்லி விநாடிகளுக்குள் முடிந்தது (நீங்கள் பதிவு பகுப்பாய்வு கருவிகளைப் பயன்படுத்தவில்லை என்றால், என்னை நம்புங்கள்: அது வேகமானது).

சேவையை எளிதாகப் பயன்படுத்துவதற்கு நிலையான, நம்பகமான செயல்திறன் முக்கியமானது. இது அவ்வப்போது பின்தங்கியிருந்தால், பயனர்கள் அதை நம்பமுடியாததாக உணர்ந்து, அதைப் பயன்படுத்தத் தயங்குவார்கள்.

பதிவு தேடல் செயலில் உள்ளது

Scalyr தேடலை செயலில் காட்டும் ஒரு சிறிய அனிமேஷன் இதோ. எங்களிடம் டெமோ கணக்கு உள்ளது, அதில் ஒவ்வொரு பொது கிதுப் களஞ்சியத்திலும் ஒவ்வொரு நிகழ்வையும் இறக்குமதி செய்கிறோம். இந்த டெமோவில், நான் ஒரு வார மதிப்புள்ள தரவை ஆய்வு செய்கிறேன்: தோராயமாக 600 எம்பி மூல பதிவுகள்.

எனது டெஸ்க்டாப்பில் (சேவையகத்திலிருந்து சுமார் 5000 கிலோமீட்டர் தொலைவில்) சிறப்பு தயாரிப்பு இல்லாமல் வீடியோ நேரலையில் பதிவு செய்யப்பட்டது. நீங்கள் பார்க்கும் செயல்திறன் பெரும்பாலும் காரணமாக உள்ளது வலை கிளையன்ட் தேர்வுமுறை, அத்துடன் வேகமான மற்றும் நம்பகமான பின்தளம். 'லோடிங்' இன்டிகேட்டர் இல்லாமல் இடைநிறுத்தம் ஏற்படும் போதெல்லாம், நான் எதை அழுத்தப் போகிறேன் என்பதை நீங்கள் படிக்கலாம்.

முடிவில்

பெரிய அளவிலான தரவைச் செயலாக்கும் போது, ​​ஒரு நல்ல அல்காரிதத்தைத் தேர்ந்தெடுப்பது முக்கியம், ஆனால் "நல்லது" என்பது "ஆடம்பரமானது" என்று அர்த்தமல்ல. நடைமுறையில் உங்கள் குறியீடு எவ்வாறு செயல்படும் என்பதைப் பற்றி சிந்தியுங்கள். அல்காரிதம்களின் தத்துவார்த்த பகுப்பாய்வு, நிஜ உலகில் பெரும் முக்கியத்துவம் வாய்ந்த சில காரணிகளை விட்டுவிடுகிறது. எளிமையான அல்காரிதம்களை மேம்படுத்துவது எளிதானது மற்றும் விளிம்பு சூழ்நிலைகளில் மிகவும் நிலையானது.

குறியீடு செயல்படுத்தப்படும் சூழலைப் பற்றியும் சிந்தியுங்கள். எங்கள் விஷயத்தில், பின்னணி பணிகளை நிர்வகிக்க போதுமான சக்திவாய்ந்த சர்வர்கள் தேவை. பயனர்கள் தேடல்களை ஒப்பீட்டளவில் அரிதாகவே தொடங்குகிறார்கள், எனவே ஒவ்வொரு தேடலையும் முடிக்க தேவையான குறுகிய காலத்திற்கு நாங்கள் முழு சேவையகங்களையும் கடன் வாங்கலாம்.

ப்ரூட் ஃபோர்ஸ் முறையைப் பயன்படுத்தி, பதிவுகளின் தொகுப்பில் வேகமான, நம்பகமான, நெகிழ்வான தேடலைச் செயல்படுத்தினோம். இந்த யோசனைகள் உங்கள் திட்டங்களுக்கு பயனுள்ளதாக இருக்கும் என நம்புகிறோம்.

தொகு: கடந்த சில ஆண்டுகளில் செயல்திறன் அதிகரிப்பைப் பிரதிபலிக்கும் வகையில் தலைப்பும் உரையும் "வினாடிக்கு 20 ஜிபியில் தேடு" என்பதிலிருந்து "வினாடிக்கு 1 டிபியில் தேடு" என மாற்றப்பட்டுள்ளது. இந்த வேக அதிகரிப்பு முதன்மையாக எங்களின் அதிகரித்த வாடிக்கையாளர் தளத்திற்கு சேவை செய்வதற்காக இன்று நாங்கள் வைக்கும் EC2 சேவையகங்களின் வகை மற்றும் எண்ணிக்கையில் ஏற்படும் மாற்றங்களால் ஏற்படுகிறது. செயல்பாட்டு செயல்திறனில் மற்றொரு வியத்தகு ஊக்கத்தை வழங்கும் மாற்றங்கள் விரைவில் வரவுள்ளன, அவற்றைப் பகிர நாங்கள் காத்திருக்க முடியாது.

ஆதாரம்: www.habr.com