எலாஸ்டிக் தேடலுடன் ஹைலோட் திட்டத்தில் மேம்படுத்தல் ஏற்றவும்

ஹே ஹப்ர்! எனது பெயர் மாக்சிம் வாசிலீவ், நான் FINCH இல் ஆய்வாளராகவும் திட்ட மேலாளராகவும் பணிபுரிகிறேன். எலாஸ்டிக் தேடலைப் பயன்படுத்தி, 15 நிமிடங்களில் 6 மில்லியன் கோரிக்கைகளை எவ்வாறு செயலாக்க முடிந்தது மற்றும் எங்கள் வாடிக்கையாளர்களில் ஒருவரின் தளத்தில் தினசரி சுமைகளை எவ்வாறு மேம்படுத்த முடிந்தது என்பதை இன்று நான் உங்களுக்குச் சொல்ல விரும்புகிறேன். துரதிர்ஷ்டவசமாக, நாங்கள் பெயர்கள் இல்லாமல் செய்ய வேண்டியிருக்கும், எங்களிடம் NDA இருப்பதால், கட்டுரையின் உள்ளடக்கம் இதனால் பாதிக்கப்படாது என்று நம்புகிறோம். போகலாம்.

திட்டம் எவ்வாறு செயல்படுகிறது

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

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

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

சுருக்கமான பின்னணி

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

அனைத்து தரவையும் Postgres இல் சேமித்துள்ளோம்: பரிவர்த்தனைகள் முதல் செய்திகள் வரை. ஆனால் பயனர்களின் எண்ணிக்கை அதிகரித்தது, அதனுடன் கோரிக்கைகளின் எண்ணிக்கையும் அதிகரித்தது.

புரிந்து கொள்ள, டெஸ்க்டாப் தளத்தில் மட்டும் 2017 இல் ஆண்டு அமர்வுகளின் எண்ணிக்கை 131 மில்லியன். 2018 இல் - 125 மில்லியன். 2019 மீண்டும் 130 மில்லியன். தளத்தின் மொபைல் பதிப்பு மற்றும் மொபைல் பயன்பாட்டிலிருந்து மேலும் 100-200 மில்லியனைச் சேர்க்கவும், மேலும் நீங்கள் அதிக எண்ணிக்கையிலான கோரிக்கைகள் கிடைக்கும்.

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

எங்கள் தேவைகளை வழங்கும் மற்றும் PostgreSQL இன் சுமைகளை அகற்றும் பிற தரவு அங்காடிகள் தேவை என்பதை நாங்கள் புரிந்துகொண்டோம். Elasticsearch மற்றும் MongoDB ஆகியவை சாத்தியமான விருப்பங்களாகக் கருதப்பட்டன. பிந்தையது பின்வரும் புள்ளிகளில் இழந்தது:

1. குறியீட்டு எண்களில் உள்ள தரவுகளின் அளவு அதிகரிக்கும் போது மெதுவான அட்டவணைப்படுத்தல் வேகம். மீள்தன்மையுடன், வேகமானது தரவின் அளவைப் பொறுத்தது அல்ல.
2. முழு உரை தேடல் இல்லை

எனவே நாங்கள் எலாஸ்டிக்கைத் தேர்ந்தெடுத்து மாற்றத்திற்குத் தயாரானோம்.

மீள்நிலைக்கு மாற்றம்

1. விற்பனைத் தேடல் சேவையிலிருந்து மாற்றத்தைத் தொடங்கினோம். எங்கள் வாடிக்கையாளருக்கு மொத்தம் 70 விற்பனை புள்ளிகள் உள்ளன, இதற்கு தளத்திலும் பயன்பாட்டிலும் பல வகையான தேடல்கள் தேவைப்படுகின்றன:

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

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

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

3. பிறகு பரிவர்த்தனை செயலாக்கத்தை நகர்த்தினோம். பயனர்கள் தளத்தில் ஒரு குறிப்பிட்ட தயாரிப்பை வாங்கலாம் மற்றும் பரிசு டிராவில் பங்கேற்கலாம். அத்தகைய வாங்குதல்களுக்குப் பிறகு, பெரிய அளவிலான தரவைச் செயலாக்குகிறோம், குறிப்பாக வார இறுதி நாட்கள் மற்றும் விடுமுறை நாட்களில். ஒப்பிடுகையில், சாதாரண நாட்களில் கொள்முதல் எண்ணிக்கை 1,5-2 மில்லியனுக்கு இடையில் இருந்தால், விடுமுறை நாட்களில் இந்த எண்ணிக்கை 53 மில்லியனை எட்டும்.

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

காலகட்டம்

இப்போது புதுப்பிப்புகள் பின்வரும் நிபந்தனைகளின்படி நிகழ்வின் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளன:

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

மீள்தன்மையின் நன்மைகளை இங்கே மீண்டும் குறிப்பிடுவது மதிப்பு. Postgres இல், கோரிக்கையை அனுப்பும் போது, ​​அது நேர்மையாக அனைத்து பதிவுகளையும் செயல்படுத்தும் வரை நீங்கள் காத்திருக்க வேண்டும். நீங்கள் 10 பதிவுகளை Elastic க்கு அனுப்பலாம் மற்றும் அனைத்து ஷார்ட்களிலும் பதிவுகள் விநியோகிக்கப்படும் வரை காத்திருக்காமல் உடனடியாக வேலை செய்யத் தொடங்கலாம். நிச்சயமாக, சில ஷார்ட் அல்லது பிரதிகள் உடனடியாக தரவைப் பார்க்காமல் இருக்கலாம், ஆனால் அனைத்தும் மிக விரைவில் கிடைக்கும்.

ஒருங்கிணைப்பு முறைகள்

எலாஸ்டிக் உடன் ஒருங்கிணைக்க 2 வழிகள் உள்ளன:

1. TCP மூலம் சொந்த கிளையன்ட் மூலம். சொந்த இயக்கி படிப்படியாக இறந்து கொண்டிருக்கிறது: இது இனி ஆதரிக்கப்படாது, இது மிகவும் சிரமமான தொடரியல் உள்ளது. எனவே, நாங்கள் அதை நடைமுறையில் பயன்படுத்துவதில்லை மற்றும் அதை முற்றிலுமாக கைவிட முயற்சிக்கிறோம்.
2. JSON கோரிக்கைகள் மற்றும் Lucene தொடரியல் இரண்டையும் பயன்படுத்தக்கூடிய HTTP இடைமுகம் மூலம். கடைசியாக எலாஸ்டிக் பயன்படுத்தும் உரை இயந்திரம். இந்தப் பதிப்பில், HTTP மூலம் JSON கோரிக்கைகள் மூலம் பேட்ச் செய்யும் திறனைப் பெறுகிறோம். இந்த விருப்பத்தை நாங்கள் பயன்படுத்த முயற்சிக்கிறோம்.

HTTP இடைமுகத்திற்கு நன்றி, HTTP கிளையண்டின் ஒத்திசைவற்ற செயலாக்கத்தை வழங்கும் நூலகங்களைப் பயன்படுத்தலாம். Batch மற்றும் ஒத்திசைவற்ற API ஐப் பயன்படுத்திக் கொள்ளலாம், இதன் விளைவாக அதிக செயல்திறன் கிடைக்கும், இது பெரிய விளம்பரத்தின் நாட்களில் பெரிதும் உதவியது (மேலும் கீழே)

ஒப்பிடுவதற்கு சில எண்கள்:

• போஸ்ட்கிரெஸ் பவுண்டி பயனர்களை 20 த்ரெட்களில் குழுவாக்காமல் சேமிக்கிறது: 460713 வினாடிகளில் 42 பதிவுகள்
• மீள்தன்மை + 10 இழைகளுக்கு எதிர்வினை கிளையன்ட் + 1000 உறுப்புகளுக்கான தொகுதி: 596749 வினாடிகளில் 11 பதிவுகள்
• மீள்தன்மை + 10 இழைகளுக்கு எதிர்வினை கிளையன்ட் + 1000 உறுப்புகளுக்கான தொகுதி: 23801684 நிமிடங்களில் 4 பதிவுகள்

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

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

பெரிய பதவி உயர்வு

வருடத்திற்கு ஒருமுறை, இந்த திட்டம் பயனர்களுக்கு ஒரு பெரிய விளம்பரத்தை வழங்குகிறது - இது அதே ஹைலோட் ஆகும், ஏனெனில் இந்த நேரத்தில் நாங்கள் ஒரே நேரத்தில் பல்லாயிரக்கணக்கான பயனர்களுடன் வேலை செய்கிறோம்.

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

2019 இன் தொடக்கத்தில், எலாஸ்டிக் தேடல் தேவை என்று முடிவு செய்தோம். ஒரு வருடம் முழுவதும், பெறப்பட்ட தரவை எலாஸ்டிக்கில் செயலாக்கவும், மொபைல் பயன்பாடு மற்றும் இணையதளத்தின் ஏபிஐயில் அவற்றை வழங்கவும் நாங்கள் ஏற்பாடு செய்துள்ளோம். இதன் விளைவாக, அடுத்த ஆண்டு பிரச்சாரத்தின் போது, ​​நாங்கள் செயலாக்கினோம் 15 நிமிடங்களில் 131 பதிவுகள்.

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

முடிவு/முடிவுகள்

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

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

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

⌘⌘⌘

வாசித்ததற்கு நன்றி. உங்கள் நிறுவனமும் ElasticSearch ஐப் பயன்படுத்தினால் மற்றும் அதன் சொந்த செயல்படுத்தல் வழக்குகள் இருந்தால், எங்களிடம் கூறுங்கள். மற்றவர்கள் எப்படி இருக்கிறார்கள் என்று தெரிந்து கொள்வது சுவாரஸ்யமாக இருக்கும் 🙂

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