हे हबर! मेरा नाम मैक्सिम वासिलिव है, मैं फ़िंच में एक विश्लेषक और परियोजना प्रबंधक के रूप में काम करता हूँ। आज मैं आपको बताना चाहता हूं कि कैसे, ElasticSearch का उपयोग करके, हम 15 मिनट में 6 करोड़ अनुरोधों को संसाधित करने में सक्षम थे और हमारे एक ग्राहक की साइट पर दैनिक लोड को अनुकूलित करने में सक्षम थे। दुर्भाग्य से, हमें नामों के बिना करना होगा, चूंकि हमारे पास एक एनडीए है, हम आशा करते हैं कि लेख की सामग्री को इससे नुकसान नहीं होगा। चल दर।
प्रोजेक्ट कैसे काम करता है
हमारे बैकएंड पर, हम ऐसी सेवाएँ बनाते हैं जो हमारे क्लाइंट की वेबसाइटों और मोबाइल एप्लिकेशन के प्रदर्शन को सुनिश्चित करती हैं। आरेख में सामान्य संरचना देखी जा सकती है:
काम की प्रक्रिया में, हम बड़ी संख्या में लेन-देन की प्रक्रिया करते हैं: खरीद, भुगतान, उपयोगकर्ता संतुलन के साथ संचालन, जिसके लिए हम बहुत सारे लॉग स्टोर करते हैं, साथ ही इस डेटा को बाहरी सिस्टम में आयात और निर्यात करते हैं।
जब हम क्लाइंट से डेटा प्राप्त करते हैं और इसे उपयोगकर्ता को स्थानांतरित करते हैं तो रिवर्स प्रोसेस भी होते हैं। इसके अलावा, अभी भी भुगतान और बोनस कार्यक्रमों के साथ काम करने की प्रक्रियाएँ हैं।
संक्षिप्त पृष्ठभूमि
प्रारंभ में, हमने केवल डेटा स्टोर के रूप में PostgreSQL का उपयोग किया। DBMS के लिए इसके मानक लाभ: लेन-देन की उपस्थिति, एक विकसित डेटा नमूनाकरण भाषा, एकीकरण के लिए उपकरणों की एक विस्तृत श्रृंखला; अच्छे प्रदर्शन के साथ संयुक्त रूप से काफी लंबे समय तक हमारी जरूरतों को पूरा करता है।
हमने पोस्टग्रेज में पूरी तरह से सभी डेटा संग्रहीत किए हैं: लेन-देन से लेकर समाचार तक। लेकिन उपयोगकर्ताओं की संख्या बढ़ी, और इसके साथ अनुरोधों की संख्या भी बढ़ी।
समझने के लिए, केवल डेस्कटॉप साइट पर 2017 में सत्रों की वार्षिक संख्या 131 मिलियन है। 2018 में - 125 मिलियन। 2019 फिर से 130 मिलियन। साइट के मोबाइल संस्करण और मोबाइल एप्लिकेशन से और 100-200 मिलियन जोड़ें, और आप बड़ी संख्या में अनुरोध प्राप्त होंगे।
परियोजना की वृद्धि के साथ, पोस्टग्रेज ने भार का सामना करना बंद कर दिया, हमारे पास समय नहीं था - बड़ी संख्या में विभिन्न प्रश्न सामने आए, जिसके लिए हम पर्याप्त संख्या में सूचकांक नहीं बना सके।
हम समझ गए थे कि अन्य डेटा स्टोर की आवश्यकता थी जो हमारी आवश्यकताओं को पूरा करे और PostgreSQL का भार कम करे। Elasticsearch और MongoDB को संभावित विकल्प माना जाता था। बाद वाला निम्नलिखित बिंदुओं पर हार गया:
- अनुक्रमणिका में डेटा की मात्रा बढ़ने पर धीमी अनुक्रमण गति। लोचदार के साथ, गति डेटा की मात्रा पर निर्भर नहीं करती है।
- कोई पूर्ण पाठ खोज नहीं
इसलिए हमने अपने लिए इलास्टिक को चुना और ट्रांजिशन के लिए तैयार किया।
लोचदार के लिए संक्रमण
1. हमने पॉइंट ऑफ़ सेल सर्च सर्विस से ट्रांज़िशन शुरू किया। हमारे ग्राहक के पास बिक्री के लगभग 70 बिंदु हैं, और इसके लिए साइट पर और एप्लिकेशन में कई प्रकार की खोजों की आवश्यकता होती है:
- शहर के नाम से पाठ खोज
- किसी बिंदु से दिए गए दायरे में भू-खोज। उदाहरण के लिए, यदि उपयोगकर्ता यह देखना चाहता है कि बिक्री के कौन से बिंदु उसके घर के सबसे करीब हैं।
- दिए गए वर्ग द्वारा खोजें - उपयोगकर्ता मानचित्र पर एक वर्ग बनाता है, और इस त्रिज्या के सभी बिंदु उसे दिखाए जाते हैं।
- अतिरिक्त फ़िल्टर द्वारा खोजें। बिक्री के बिंदु वर्गीकरण में एक दूसरे से भिन्न होते हैं
अगर हम Organisation की बात करें तो Postgres में हमारे पास मैप और न्यूज दोनों के लिए डेटा सोर्स होता है और Elastic Snapshots में ओरिजिनल डेटा से लिया जाता है। तथ्य यह है कि शुरू में पोस्टग्रेज सभी मानदंडों द्वारा खोज का सामना नहीं कर सके। न केवल कई इंडेक्स थे, वे ओवरलैप भी कर सकते थे, इसलिए पोस्टग्रेस शेड्यूलर खो गया और समझ में नहीं आया कि किस इंडेक्स का उपयोग करना है।
2. कतार में अगला समाचार अनुभाग था। प्रकाशन हर दिन साइट पर दिखाई देते हैं ताकि उपयोगकर्ता सूचना के प्रवाह में खो न जाए, जारी करने से पहले डेटा को क्रमबद्ध किया जाना चाहिए। यह वह है जिसके लिए खोज है: आप साइट को टेक्स्ट मैच द्वारा खोज सकते हैं, और साथ ही अतिरिक्त फ़िल्टर कनेक्ट कर सकते हैं, क्योंकि वे भी इलास्टिक के माध्यम से बनाए गए हैं।
3. फिर हमने लेन-देन की प्रक्रिया को आगे बढ़ाया। उपयोगकर्ता साइट पर एक निश्चित उत्पाद खरीद सकते हैं और पुरस्कार ड्रा में भाग ले सकते हैं। ऐसी खरीदारी के बाद, हम बड़ी मात्रा में डेटा संसाधित करते हैं, विशेष रूप से सप्ताहांत और छुट्टियों पर। तुलना के लिए अगर सामान्य दिनों में खरीदारी की संख्या 1,5-2 लाख के बीच रहती है तो छुट्टियों में यह आंकड़ा 53 लाख तक पहुंच सकता है।
उसी समय, डेटा को कम से कम समय में संसाधित किया जाना चाहिए - उपयोगकर्ता कई दिनों तक परिणाम की प्रतीक्षा करना पसंद नहीं करते हैं। पोस्टग्रेज के माध्यम से इस तरह की समय सीमा को प्राप्त करने का कोई तरीका नहीं है - हमें अक्सर लॉक प्राप्त होते हैं, और जब हम सभी अनुरोधों को संसाधित कर रहे होते हैं, तो उपयोगकर्ता यह जांच नहीं कर पाते कि उन्हें पुरस्कार मिला है या नहीं। यह व्यवसाय के लिए बहुत सुखद नहीं है, इसलिए हमने प्रसंस्करण को एलिटिक्स खोज में स्थानांतरित कर दिया।
दौरा
निम्न स्थितियों के अनुसार अब अपडेट इवेंट-आधारित कॉन्फ़िगर किए गए हैं:
- बिक्री बिंदु। जैसे ही हम किसी बाहरी स्रोत से डेटा प्राप्त करते हैं, हम तुरंत अपडेट शुरू कर देते हैं।
- समाचार। साइट पर जैसे ही कोई खबर संपादित की जाती है, वह स्वचालित रूप से Elastic को भेज दी जाती है।
यहां फिर से इलास्टिक के फायदों का जिक्र करना जरूरी है। पोस्टग्रेज में, अनुरोध भेजते समय, आपको तब तक इंतजार करना होगा जब तक कि यह सभी रिकॉर्डों को ईमानदारी से संसाधित न कर दे। आप इलास्टिक को 10 रिकॉर्ड भेज सकते हैं और तुरंत काम करना शुरू कर सकते हैं, बिना रिकॉर्ड के सभी शार्ड्स में वितरित किए जाने की प्रतीक्षा किए बिना। बेशक, कुछ शार्ड या प्रतिकृति डेटा को तुरंत नहीं देख सकते हैं, लेकिन सब कुछ बहुत जल्द उपलब्ध होगा।
एकीकरण के तरीके
लोचदार के साथ एकीकृत करने के 2 तरीके हैं:
- टीसीपी पर एक मूल ग्राहक के माध्यम से। देशी ड्राइवर धीरे-धीरे मर रहा है: यह अब समर्थित नहीं है, इसका एक बहुत ही असुविधाजनक सिंटैक्स है। इसलिए, हम व्यावहारिक रूप से इसका उपयोग नहीं करते हैं और इसे पूरी तरह से त्यागने का प्रयास करते हैं।
- एक HTTP इंटरफ़ेस के माध्यम से जो JSON अनुरोध और ल्यूसीन सिंटैक्स दोनों का उपयोग कर सकता है। आखिरी वाला एक टेक्स्ट इंजन है जो इलास्टिक का उपयोग करता है। इस संस्करण में, हम HTTP पर JSON अनुरोधों के माध्यम से बैच करने की क्षमता प्राप्त करते हैं। यह वह विकल्प है जिसका हम उपयोग करने का प्रयास कर रहे हैं।
HTTP इंटरफ़ेस के लिए धन्यवाद, हम पुस्तकालयों का उपयोग कर सकते हैं जो HTTP क्लाइंट का अतुल्यकालिक कार्यान्वयन प्रदान करते हैं। हम बैच और एसिंक्रोनस एपीआई का लाभ उठा सकते हैं, जिसके परिणामस्वरूप उच्च प्रदर्शन होता है, जिसने बड़े प्रचार के दिनों में बहुत मदद की (नीचे उस पर और अधिक)
तुलना के लिए कुछ संख्याएँ:
- ग्रुपिंग के बिना 20 थ्रेड्स में पोस्टग्रेस बाउंटी उपयोगकर्ताओं को सहेजना: 460713 सेकंड में 42 रिकॉर्ड
- 10 थ्रेड्स के लिए इलास्टिक + रिएक्टिव क्लाइंट + 1000 तत्वों के लिए बैच: 596749 सेकंड में 11 रिकॉर्ड
- 10 थ्रेड्स के लिए इलास्टिक + रिएक्टिव क्लाइंट + 1000 तत्वों के लिए बैच: 23801684 प्रविष्टियां 4 मिनट में
अब हमने एक HTTP रिक्वेस्ट मैनेजर लिखा है जो JSON को बैच / नॉट बैच के रूप में बनाता है और लाइब्रेरी की परवाह किए बिना इसे किसी भी HTTP क्लाइंट के माध्यम से भेजता है। आप सिंक्रोनस या एसिंक्रोनस रूप से अनुरोध भेजना भी चुन सकते हैं।
कुछ एकीकरणों में, हम अभी भी आधिकारिक परिवहन ग्राहक का उपयोग करते हैं, लेकिन यह केवल अगले रिफैक्टरिंग का मामला है। इस मामले में, प्रसंस्करण के लिए स्प्रिंग वेब क्लाइंट के आधार पर निर्मित एक कस्टम क्लाइंट का उपयोग किया जाता है।
बड़ा प्रचार
वर्ष में एक बार, परियोजना उपयोगकर्ताओं के लिए एक बड़ा प्रचार करती है - यह वही हाईलोड है, क्योंकि इस समय हम एक ही समय में करोड़ों उपयोगकर्ताओं के साथ काम करते हैं।
आमतौर पर छुट्टियों के दौरान चरम भार होता है, लेकिन यह प्रचार पूरी तरह से अलग स्तर पर है। पिछले साल, प्रचार के दिन, हमने 27 यूनिट माल बेचा। डेटा को आधे घंटे से अधिक समय तक संसाधित किया गया, जिससे उपयोगकर्ताओं को असुविधा हुई। उपयोगकर्ताओं को भागीदारी के लिए पुरस्कार प्राप्त हुए, लेकिन यह स्पष्ट हो गया कि प्रक्रिया को तेज करने की आवश्यकता है।
2019 की शुरुआत में, हमने फैसला किया कि हमें ElasticSearch की जरूरत है। पूरे एक साल के लिए, हमने इलास्टिक में प्राप्त डेटा के प्रसंस्करण और मोबाइल एप्लिकेशन और वेबसाइट के एपीआई में उन्हें जारी करने का आयोजन किया। परिणामस्वरूप, अगले वर्ष अभियान के दौरान, हमने संसाधित किया 15 मिनट में 131 प्रविष्टियां।
चूंकि हमारे पास ऐसे बहुत से लोग हैं जो सामान खरीदना चाहते हैं और प्रचार में पुरस्कार निकालने में भाग लेना चाहते हैं, यह एक अस्थायी उपाय है। अब हम इलास्टिक को अप-टू-डेट जानकारी भेज रहे हैं, लेकिन भविष्य में हम पिछले महीनों के लिए संग्रहीत जानकारी को स्थायी भंडारण के रूप में पोस्टग्रेज में स्थानांतरित करने की योजना बना रहे हैं। इलास्टिक इंडेक्स को बंद न करने के लिए, जिसकी अपनी सीमाएँ भी हैं।
निष्कर्ष / निष्कर्ष
फिलहाल, हमने उन सभी सेवाओं को स्थानांतरित कर दिया है जिन्हें हम इलास्टिक में चाहते थे और अभी के लिए इस पर रोक लगा दी है। अब हम पोस्टग्रेज में मुख्य लगातार स्टोरेज के ऊपर इलास्टिक में एक इंडेक्स बना रहे हैं, जो यूजर लोड को लेता है।
भविष्य में, हम सेवाओं को स्थानांतरित करने की योजना बनाते हैं यदि हम समझते हैं कि डेटा अनुरोध बहुत विविध हो जाता है और असीमित संख्या में स्तंभों की खोज की जाती है। यह अब Postgres का कार्य नहीं है।
यदि हमें कार्यक्षमता में पूर्ण-पाठ खोज की आवश्यकता है या यदि हमारे पास बहुत से भिन्न खोज मापदंड हैं, तो हम पहले से ही जानते हैं कि इसे इलास्टिक में अनुवादित करने की आवश्यकता है।
मैं
पढ़ने के लिए धन्यवाद। यदि आपकी कंपनी ElasticSearch का भी उपयोग करती है और इसके अपने कार्यान्वयन के मामले हैं, तो हमें बताएं। यह जानना दिलचस्प होगा कि दूसरे 🙂 कैसे हैं
स्रोत: www.habr.com