ElasticSearch सह हायलोड प्रोजेक्टवर लोड ऑप्टिमायझेशन

अहो हाब्र! माझे नाव मॅक्सिम वासिलिव्ह आहे, मी फिन्च येथे विश्लेषक आणि प्रकल्प व्यवस्थापक म्हणून काम करतो. आज मी तुम्हाला सांगू इच्छितो की, ElasticSearch वापरून, आम्ही 15 मिनिटांत 6 दशलक्ष विनंत्यांवर प्रक्रिया करू शकलो आणि आमच्या एका क्लायंटच्या साइटवर दैनंदिन भार कसा ऑप्टिमाइझ करू शकलो. दुर्दैवाने, आम्हाला नावांशिवाय करावे लागेल, आमच्याकडे एनडीए असल्याने, आम्हाला आशा आहे की लेखाच्या मजकुराचा याचा त्रास होणार नाही. चल जाऊया.

प्रकल्प कसे कार्य करते

आमच्या बॅकएंडवर, आम्ही सेवा तयार करतो ज्या आमच्या क्लायंटच्या वेबसाइट्स आणि मोबाइल ऍप्लिकेशनच्या कार्यप्रदर्शनाची खात्री करतात. आकृतीमध्ये सामान्य रचना पाहिली जाऊ शकते:

कामाच्या प्रक्रियेत, आम्ही मोठ्या संख्येने व्यवहारांवर प्रक्रिया करतो: खरेदी, पेमेंट, वापरकर्ता शिल्लक असलेली ऑपरेशन्स, ज्यासाठी आम्ही बरेच लॉग संग्रहित करतो, तसेच हा डेटा बाह्य सिस्टममध्ये आयात आणि निर्यात करतो.

जेव्हा आम्ही क्लायंटकडून डेटा प्राप्त करतो आणि तो वापरकर्त्याकडे हस्तांतरित करतो तेव्हा उलट प्रक्रिया देखील असतात. याव्यतिरिक्त, पेमेंट आणि बोनस प्रोग्रामसह कार्य करण्यासाठी अद्याप प्रक्रिया आहेत.

संक्षिप्त पार्श्वभूमी

सुरुवातीला, आम्ही फक्त डेटा स्टोअर म्हणून PostgreSQL वापरला. डीबीएमएससाठी त्याचे मानक फायदे: व्यवहारांची उपस्थिती, विकसित डेटा सॅम्पलिंग भाषा, एकीकरणासाठी विस्तृत साधनांची श्रेणी; चांगल्या कामगिरीसह एकत्रितपणे आमच्या गरजा बर्‍याच काळासाठी पूर्ण केल्या.

आम्ही पोस्टग्रेसमध्ये पूर्णपणे सर्व डेटा संग्रहित केला: व्यवहारांपासून बातम्यांपर्यंत. परंतु वापरकर्त्यांची संख्या वाढली आणि त्यासह विनंत्यांची संख्या.

समजून घेण्यासाठी, 2017 मध्ये केवळ डेस्कटॉप साइटवर सत्रांची वार्षिक संख्या 131 दशलक्ष आहे. 2018 मध्ये - 125 दशलक्ष. 2019 पुन्हा 130 दशलक्ष. साइटच्या मोबाइल आवृत्ती आणि मोबाइल ऍप्लिकेशनमधून आणखी 100-200 दशलक्ष जोडा आणि तुम्ही मोठ्या संख्येने विनंत्या मिळतील.

प्रकल्पाच्या वाढीसह, पोस्टग्रेसने लोडचा सामना करणे थांबवले, आमच्याकडे वेळ नव्हता - मोठ्या संख्येने विविध प्रश्न दिसू लागले, ज्यासाठी आम्ही पुरेशी संख्या निर्देशांक तयार करू शकलो नाही.

आम्हाला समजले की इतर डेटा स्टोअरची गरज आहे जी आमच्या गरजा पुरवतील आणि पोस्टग्रेएसक्यूएलचा भार कमी करतील. Elasticsearch आणि MongoDB हे संभाव्य पर्याय मानले गेले. नंतरचे खालील मुद्द्यांवर हरले:

1. इंडेक्सेसमधील डेटाचे प्रमाण वाढत असताना इंडेक्सिंगचा वेग कमी होतो. लवचिक सह, गती डेटाच्या प्रमाणात अवलंबून नाही.
2. पूर्ण मजकूर शोध नाही

म्हणून आम्ही स्वतःसाठी लवचिक निवडले आणि संक्रमणाची तयारी केली.

लवचिक करण्यासाठी संक्रमण

1. आम्ही विक्री शोध सेवेच्या बिंदूपासून संक्रमण सुरू केले. आमच्या क्लायंटकडे एकूण 70 पॉइंट्स ऑफ सेल आहेत आणि यासाठी साइटवर आणि ऍप्लिकेशनमध्ये अनेक प्रकारचे शोध आवश्यक आहेत:

• शहराच्या नावाने मजकूर शोध
• एखाद्या बिंदूपासून दिलेल्या त्रिज्यामध्ये भूशोध. उदाहरणार्थ, वापरकर्त्याला त्याच्या घराच्या सर्वात जवळचे विक्रीचे कोणते ठिकाण पहायचे असेल.
• दिलेल्या स्क्वेअरद्वारे शोधा - वापरकर्ता नकाशावर एक चौरस काढतो आणि या त्रिज्यामधील सर्व बिंदू त्याला दाखवले जातात.
• अतिरिक्त फिल्टरद्वारे शोधा. विक्रीचे गुण वर्गीकरणात एकमेकांपेक्षा वेगळे आहेत

जर आपण संस्थेबद्दल बोललो, तर पोस्टग्रेसमध्ये आमच्याकडे नकाशा आणि बातम्या दोन्हीसाठी डेटा स्रोत आहे आणि लवचिक स्नॅपशॉट्स मूळ डेटामधून घेतले जातात. वस्तुस्थिती अशी आहे की सुरुवातीला पोस्टग्रेस सर्व निकषांनुसार शोधाचा सामना करू शकला नाही. केवळ अनेक निर्देशांकच नव्हते तर ते ओव्हरलॅप देखील करू शकतात, त्यामुळे पोस्टग्रेस शेड्युलर हरवला आणि कोणता निर्देशांक वापरायचा हे समजले नाही.

2. पुढील ओळीत बातम्या विभाग होता. प्रकाशने दररोज साइटवर दिसतात जेणेकरून वापरकर्ता माहितीच्या प्रवाहात गमावू नये, जारी करण्यापूर्वी डेटाची क्रमवारी लावणे आवश्यक आहे. हा शोध यासाठी आहे: तुम्ही मजकूर जुळणीद्वारे साइट शोधू शकता आणि त्याच वेळी अतिरिक्त फिल्टर कनेक्ट करू शकता, कारण ते देखील लवचिक द्वारे केले जातात.

3. मग आम्ही व्यवहार प्रक्रिया हलवली. वापरकर्ते साइटवर विशिष्ट उत्पादन खरेदी करू शकतात आणि बक्षीस सोडतीमध्ये सहभागी होऊ शकतात. अशा खरेदीनंतर, आम्ही विशेषत: शनिवार व रविवार आणि सुट्टीच्या दिवशी मोठ्या प्रमाणात डेटावर प्रक्रिया करतो. तुलनेसाठी, जर सामान्य दिवशी खरेदीची संख्या 1,5-2 दशलक्ष दरम्यान असेल, तर सुट्टीच्या दिवशी हा आकडा 53 दशलक्षांपर्यंत पोहोचू शकतो.

त्याच वेळी, डेटावर कमीत कमी वेळेत प्रक्रिया करणे आवश्यक आहे - वापरकर्त्यांना अनेक दिवस निकालाची प्रतीक्षा करणे आवडत नाही. Postgres द्वारे अशा मुदती साध्य करण्याचा कोणताही मार्ग नाही - आम्हाला अनेकदा लॉक मिळाले, आणि आम्ही सर्व विनंत्यांची प्रक्रिया करत असताना, वापरकर्ते त्यांना बक्षिसे मिळाली की नाही हे तपासू शकले नाहीत. हे व्यवसायासाठी खूप आनंददायी नाही, म्हणून आम्ही प्रक्रिया इलास्टिकसर्चमध्ये हलवली.

कालावधी

आता अद्यतने खालील अटींनुसार, इव्हेंट-आधारित कॉन्फिगर केली आहेत:

1. विक्री गुण. आम्हाला बाह्य स्त्रोताकडून डेटा प्राप्त होताच, आम्ही त्वरित अपडेट सुरू करतो.
2. बातम्या. साइटवर कोणतीही बातमी संपादित करताच ती आपोआप इलास्टिकवर पाठवली जाते.

येथे पुन्हा इलास्टिकच्या फायद्यांचा उल्लेख करणे योग्य आहे. पोस्टग्रेसमध्ये, विनंती पाठवताना, तुम्हाला ते सर्व रेकॉर्डवर प्रामाणिकपणे प्रक्रिया करेपर्यंत प्रतीक्षा करावी लागेल. तुम्ही 10 रेकॉर्ड इलास्टिकला पाठवू शकता आणि सर्व शार्ड्समध्ये रेकॉर्ड वितरीत होण्याची वाट न पाहता लगेच काम सुरू करू शकता. अर्थात, काही शार्ड किंवा प्रतिकृती लगेच डेटा पाहू शकत नाहीत, परंतु सर्वकाही लवकरच उपलब्ध होईल.

एकत्रीकरण पद्धती

लवचिक सह समाकलित करण्याचे 2 मार्ग आहेत:

1. TCP वर मूळ क्लायंटद्वारे. नेटिव्ह ड्रायव्हर हळूहळू संपत चालला आहे: तो यापुढे समर्थित नाही, त्याचा एक अतिशय गैरसोयीचा सिंटॅक्स आहे. म्हणून, आम्ही व्यावहारिकरित्या ते वापरत नाही आणि ते पूर्णपणे सोडून देण्याचा प्रयत्न करतो.
2. HTTP इंटरफेसद्वारे जेएसओएन विनंत्या आणि ल्युसीन सिंटॅक्स दोन्ही वापरू शकतात. शेवटचे एक मजकूर इंजिन आहे जे लवचिक वापरते. या आवृत्तीमध्ये, आम्हाला HTTP वर JSON विनंत्यांद्वारे बॅच करण्याची क्षमता मिळते. हा पर्याय आम्ही वापरण्याचा प्रयत्न करत आहोत.

HTTP इंटरफेसबद्दल धन्यवाद, आम्ही लायब्ररी वापरू शकतो जे HTTP क्लायंटचे असिंक्रोनस अंमलबजावणी प्रदान करतात. आम्ही बॅच आणि एसिंक्रोनस API चा लाभ घेऊ शकतो, ज्यामुळे उच्च कार्यप्रदर्शन होते, ज्याने मोठ्या जाहिरातीच्या दिवसांमध्ये खूप मदत केली (खाली त्याबद्दल अधिक)

तुलनेसाठी काही संख्या:

• पोस्टग्रेस बाउंटी वापरकर्त्यांना 20 थ्रेड्समध्ये गट न करता जतन करणे: 460713 सेकंदात 42 रेकॉर्ड
• 10 थ्रेडसाठी लवचिक + प्रतिक्रियाशील क्लायंट + 1000 घटकांसाठी बॅच: 596749 सेकंदात 11 रेकॉर्ड
• 10 थ्रेडसाठी लवचिक + प्रतिक्रियाशील क्लायंट + 1000 घटकांसाठी बॅच: 23801684 मिनिटांत 4 नोंदी

आता आम्ही एक HTTP विनंती व्यवस्थापक लिहिले आहे जो JSON ला बॅच/नॉट बॅच म्हणून तयार करतो आणि लायब्ररीची पर्वा न करता कोणत्याही HTTP क्लायंटद्वारे पाठवतो. तुम्ही समकालिक किंवा असिंक्रोनस विनंत्या पाठवणे देखील निवडू शकता.

काही इंटिग्रेशन्समध्ये, आम्ही अजूनही अधिकृत वाहतूक क्लायंट वापरतो, परंतु ही फक्त पुढील रिफॅक्टरिंगची बाब आहे. या प्रकरणात, स्प्रिंग वेबक्लायंटच्या आधारावर तयार केलेला मूळ क्लायंट प्रक्रियेसाठी वापरला जातो.

मोठी जाहिरात

वर्षातून एकदा, प्रकल्प वापरकर्त्यांसाठी एक मोठी जाहिरात आयोजित करतो - हे समान हायलोड आहे, कारण यावेळी आम्ही एकाच वेळी लाखो वापरकर्त्यांसह कार्य करतो.

सहसा सुट्ट्यांमध्ये लोडची शिखरे येतात, परंतु ही जाहिरात पूर्णपणे भिन्न पातळीवर आहे. मागील वर्षी, जाहिरातीच्या दिवशी, आम्ही 27 युनिट्स वस्तू विकल्या. अर्ध्या तासापेक्षा जास्त काळ डेटावर प्रक्रिया करण्यात आली, ज्यामुळे वापरकर्त्यांची गैरसोय झाली. वापरकर्त्यांना सहभागासाठी बक्षिसे मिळाली, परंतु हे स्पष्ट झाले की प्रक्रियेला गती देणे आवश्यक आहे.

2019 च्या सुरुवातीला, आम्ही ठरवले की आम्हाला इलास्टिकसर्चची आवश्यकता आहे. संपूर्ण वर्षभर, आम्ही इलास्टिकमध्ये प्राप्त डेटाची प्रक्रिया आणि मोबाईल ऍप्लिकेशन आणि वेबसाइटच्या एपीआयमध्ये त्यांचे जारी करण्याचे आयोजन केले. परिणामी, पुढच्या वर्षी प्रचारादरम्यान आम्ही प्रक्रिया केली 15 मिनिटांत 131 नोंदी.

आमच्याकडे बरेच लोक आहेत ज्यांना वस्तू विकत घ्यायच्या आहेत आणि जाहिरातींमध्ये बक्षिसे काढण्यात भाग घ्यायचा आहे, हा एक तात्पुरता उपाय आहे. आता आम्ही इलास्टिकला अद्ययावत माहिती पाठवत आहोत, परंतु भविष्यात आम्ही मागील महिन्यांची संग्रहित माहिती कायमस्वरूपी स्टोरेज म्हणून पोस्टग्रेसमध्ये हस्तांतरित करण्याची योजना आखत आहोत. लवचिक निर्देशांक अडकू नये म्हणून, ज्याच्या मर्यादा देखील आहेत.

निष्कर्ष/निष्कर्ष

याक्षणी, आम्‍हाला हव्या असलेल्या सर्व सेवा इलास्टिकवर हस्तांतरित केल्या आहेत आणि आत्तासाठी यावर विराम दिला आहे. आता आम्ही पोस्टग्रेसमधील मुख्य पर्सिस्टंट स्टोरेजच्या शीर्षस्थानी इलास्टिकमध्ये एक निर्देशांक तयार करत आहोत, जो वापरकर्त्याचा भार घेतो.

भविष्यात, डेटा विनंती खूप वैविध्यपूर्ण आहे आणि अमर्यादित स्तंभांसाठी शोधले गेले आहे हे आम्हाला समजल्यास आम्ही सेवा हस्तांतरित करण्याची योजना आखत आहोत. पोस्टग्रेससाठी हे यापुढे कार्य नाही.

आम्हाला कार्यक्षमतेमध्ये पूर्ण-मजकूर शोध आवश्यक असल्यास किंवा आमच्याकडे बरेच भिन्न शोध निकष असल्यास, आम्हाला आधीच माहित आहे की हे इलास्टिकमध्ये भाषांतरित करणे आवश्यक आहे.

⌘⌘⌘

वाचल्याबद्दल धन्यवाद. तुमची कंपनी देखील ElasticSearch वापरत असल्यास आणि तिचे स्वतःचे अंमलबजावणी प्रकरणे असल्यास, आम्हाला सांगा. इतर कसे आहेत हे जाणून घेणे मनोरंजक असेल 🙂

स्त्रोत: www.habr.com