👌 👨🏿‍🚒 💀 ElasticSearch के साथ एक हाईलोड परियोजना पर लोड अनुकूलन 👨🏿‍🌾 🎧 🌴

नमस्कार, हेब्र! मेरा नाम मैक्सिम वासिलिव है, मैं एक विश्लेषक और परियोजना प्रबंधक के रूप में काम करता हूं। आज मैं आपको बताना चाहूँगा कि, ElasticSearch का उपयोग करते हुए, हम 6 मिनट में 15 मिलियन प्रश्नों को संसाधित करने और अपने एक ग्राहक की साइट पर दैनिक लोड को अनुकूलित करने में सक्षम थे। दुर्भाग्य से, हमें नामों के बिना करना होगा, क्योंकि हमारे पास एनडीए है, हम आशा करते हैं कि लेख की सामग्री प्रभावित नहीं होगी। जाने दो।

प्रोजेक्ट की व्यवस्था कैसे की जाती है

हमारे बैकएंड पर, हम ऐसी सेवाएँ बनाते हैं जो हमारे क्लाइंट की साइटों और मोबाइल एप्लिकेशन के प्रदर्शन को सुनिश्चित करती हैं। आरेख में सामान्य संरचना देखी जा सकती है:

इस प्रक्रिया में, हम बड़ी संख्या में लेनदेन की प्रक्रिया करते हैं: खरीद, भुगतान, उपयोगकर्ता संतुलन के साथ संचालन, जिसके लिए हम बहुत सारे लॉग संग्रहीत करते हैं, और इस डेटा को बाहरी सिस्टम में आयात और निर्यात भी करते हैं।

जब हम किसी क्लाइंट से डेटा प्राप्त करते हैं और उसे उपयोगकर्ता तक पहुंचाते हैं, तो रिवर्स प्रोसेस भी होते हैं। इसके अलावा, भुगतान और बोनस कार्यक्रमों के साथ काम करने के लिए अभी भी प्रक्रियाएं हैं।

लघु पृष्ठभूमि

प्रारंभ में, हमने केवल डेटा वेयरहाउस के रूप में PostgreSQL का उपयोग किया। DBMS के लिए इसके मानक लाभ: लेन-देन की उपलब्धता, डेटा नमूने की विकसित भाषा, एकीकरण के लिए व्यापक उपकरण; अच्छे प्रदर्शन के साथ, संतुष्ट लोगों ने लंबे समय तक हमारी जरूरतों को पूरा किया है।

हमने पोस्टग्रेज में पूरी तरह से सभी डेटा संग्रहीत किए हैं: लेनदेन से समाचार तक। लेकिन उपयोगकर्ताओं की संख्या बढ़ी, और इसके साथ अनुरोधों की संख्या।

समझने के लिए, अकेले डेस्कटॉप साइट पर 2017 में सत्रों की वार्षिक संख्या 131 मिलियन है। 2018 में, 125 मिलियन 2019 फिर से 130 मिलियन है। साइट के मोबाइल संस्करण और मोबाइल एप्लिकेशन से एक और 100-200 मिलियन जोड़ें, और आपको भारी संख्या में अनुरोध मिलेंगे।

परियोजना की वृद्धि के साथ, पोस्टग्रेज लोड से निपटने के लिए बंद हो गया, हमारे पास समय नहीं था - बड़ी संख्या में विभिन्न प्रश्न प्रकट हुए, जिसके तहत हम पर्याप्त संख्या में सूचकांक नहीं बना सके।

हमने महसूस किया कि अन्य डेटा वेयरहाउस की आवश्यकता थी जो हमारी आवश्यकताओं को प्रदान करेगा और पोस्टग्रेक्ज़िक से लोड को ले जाएगा। इलास्टिसर्च और मोंगोबडी को संभावित विकल्प माना जाता था। उत्तरार्द्ध निम्नलिखित बिंदुओं पर हार गया:

अनुक्रमित में डेटा की मात्रा बढ़ाने के साथ धीमी अनुक्रमित गति। इलास्टिक में, गति डेटा की मात्रा पर निर्भर नहीं करती है।
कोई पूर्ण पाठ खोज नहीं

इसलिए हमने इलास्टिक को अपने लिए चुना और संक्रमण के लिए तैयार किया।

इलास्टिक में स्विच करना

1. हमने बिक्री खोज सेवा के एक बिंदु के साथ संक्रमण शुरू किया। हमारे ग्राहक के पास बिक्री के लगभग 70,000 अंक हैं, और इसके लिए साइट और एप्लिकेशन में कई प्रकार की खोजों की आवश्यकता होती है:

शहर के नाम से पाठ खोज
किसी बिंदु से किसी दिए गए दायरे में भू-खोज। उदाहरण के लिए, यदि कोई उपयोगकर्ता यह देखना चाहता है कि बिक्री के कौन से बिंदु उसके घर के सबसे नजदीक हैं।
किसी दिए गए वर्ग द्वारा खोजें - उपयोगकर्ता नक्शे पर एक वर्ग खींचता है, और उसे इस दायरे में सभी बिंदुओं को दिखाया जाता है।
अतिरिक्त फिल्टर के लिए खोजें। बिक्री के अंक वर्गीकरण में एक दूसरे से भिन्न होते हैं

संगठन की बात करें तो, पोस्टग्रेज्स में हमारे पास नक्शे पर और समाचार पर डेटा का एक स्रोत है, और इलास्टिक स्नैपशॉट में मूल डेटा से बने हैं। तथ्य यह है कि शुरू में Postgres सभी मानदंडों द्वारा खोज का सामना नहीं कर सका। न केवल कई इंडेक्स थे, वे भी इंटरसेक्ट कर सकते थे, इसलिए पोस्टग्रैज शेड्यूलर खो गया और समझ में नहीं आया कि इसके लिए किस इंडेक्स का उपयोग किया जाए।

2. लाइन में अगला समाचार अनुभाग था। हर दिन, साइट पर प्रकाशन दिखाई देते हैं ताकि उपयोगकर्ता सूचना के प्रवाह में खो न जाए, डेटा जारी करने से पहले हल किया जाना चाहिए। इसके लिए, आपको एक खोज की आवश्यकता होती है: जिस साइट पर आप टेक्स्ट मैच द्वारा खोज सकते हैं, और उसी समय अतिरिक्त फ़िल्टर कनेक्ट करें, क्योंकि वे भी इलास्टिक के माध्यम से बनाए जाते हैं।

3. फिर हमने ट्रांजेक्शन प्रोसेसिंग को आगे बढ़ाया। उपयोगकर्ता साइट पर एक विशिष्ट उत्पाद खरीद सकते हैं और पुरस्कार ड्रा में भाग ले सकते हैं। इस तरह की खरीदारी के बाद, हम बड़ी मात्रा में डेटा संसाधित करते हैं, खासकर सप्ताहांत और छुट्टियों पर। तुलना के लिए, अगर सामान्य दिनों में खरीदारी की संख्या 1.5-2 मिलियन के बीच होती है, तो छुट्टियों पर यह आंकड़ा 53 मिलियन तक पहुंच सकता है।

इसी समय, डेटा को न्यूनतम समय में संसाधित करने की आवश्यकता होती है - उपयोगकर्ता कई दिनों तक परिणाम का इंतजार करना पसंद नहीं करते हैं। आपने पोस्टग्रेज के माध्यम से ऐसी समय-सीमा प्राप्त नहीं की है - हमें अक्सर ताले मिलते हैं, और जब हम सभी अनुरोधों को संसाधित करते हैं, तो उपयोगकर्ता यह जांच नहीं कर सकते हैं कि उन्हें पुरस्कार मिले या नहीं। यह व्यवसाय के लिए बहुत सुखद नहीं है, इसलिए हमने प्रसंस्करण को एलिस्टिक्स खोज में स्थानांतरित कर दिया।

दौरा

अब अपडेट को निम्न स्थितियों के तहत इवेंट-वार कॉन्फ़िगर किया गया है:

बिक्री केन्द्र। जैसे ही एक बाहरी स्रोत से डेटा हमारे पास आता है, हम तुरंत अपडेट शुरू करते हैं।
समाचार। जैसे ही कोई भी समाचार साइट पर संपादित होता है, वह स्वचालित रूप से इलास्टिक को भेज दिया जाता है।

यहां फिर से, यह इलास्टिक के फायदों का उल्लेख करने योग्य है। पोस्टग्रेज में, अनुरोध भेजते समय, आपको तब तक इंतजार करने की आवश्यकता होती है जब तक वह ईमानदारी से सभी रिकॉर्डों को संसाधित नहीं करता है। आप एलास्टिक को 10 हजार रिकॉर्ड भेज सकते हैं, और तुरंत काम शुरू कर सकते हैं, जब तक कि रिकॉर्ड सभी शार्ड्स में वितरित नहीं किए जाते। बेशक, कुछ शर्ड या रेप्लिका डेटा को तुरंत नहीं देख सकते हैं, लेकिन बहुत जल्द सब कुछ उपलब्ध होगा।

एकीकरण के तरीके

लोचदार के साथ एकीकृत करने के 2 तरीके हैं:

टीसीपी पर मूल ग्राहक के माध्यम से। मूल चालक धीरे-धीरे मर रहा है: यह अब समर्थित नहीं है, इसमें बहुत असुविधाजनक सिंटैक्स है। इसलिए, हम व्यावहारिक रूप से इसका उपयोग नहीं करते हैं और इसे पूरी तरह से त्यागने का प्रयास करते हैं।
एक HTTP इंटरफ़ेस, जिसमें आप JSON रिक्वेस्ट और Lucene सिंटैक्स दोनों का उपयोग कर सकते हैं। उत्तरार्द्ध एक पाठ इंजन है जो इलास्टिक का उपयोग करता है। इस विकल्प में, हमें HTTP पर JSON अनुरोधों के माध्यम से बैच की क्षमता मिलती है। यह वह विकल्प है जिसका हम उपयोग करने का प्रयास कर रहे हैं।

HTTP इंटरफ़ेस के लिए धन्यवाद, हम उन पुस्तकालयों का उपयोग कर सकते हैं जो HTTP क्लाइंट के अतुल्यकालिक कार्यान्वयन प्रदान करते हैं। हम बैच और अतुल्यकालिक एपीआई का लाभ उठा सकते हैं, जो अंत में उच्च प्रदर्शन देता है, जिसने एक बड़ी कार्रवाई के दिनों के दौरान बहुत मदद की (उस पर और नीचे)

तुलना के लिए कुछ आंकड़े:

बचत करने वाले उपयोगकर्ताओं को समूह के बिना 20 धाराओं में पोस्टग्रेज में पुरस्कार मिला: 42 सेकंड में 460,713 प्रविष्टियां
लोचदार + प्रतिक्रियाशील ग्राहक 10 थ्रेड + बैच के लिए 1000 तत्वों के लिए: 11 सेकंड में 596749 रिकॉर्ड
1000 तत्वों के लिए 10 थ्रेड्स + बैच के लिए लोचदार + प्रतिक्रियाशील ग्राहक: 4 मिनट में 23801684 रिकॉर्ड

अब हमने एक HTTP रिक्वेस्ट मैनेजर लिखा है जो JSON को बैच / बैच के रूप में बनाता है और लाइब्रेरी की परवाह किए बिना किसी भी HTTP क्लाइंट के माध्यम से भेजता है। आप सिंक या एसिंक्रोनस रूप से अनुरोध भेजने का विकल्प भी चुन सकते हैं।

कुछ एकीकरण में, हम अभी भी आधिकारिक परिवहन ग्राहक का उपयोग करते हैं, लेकिन यह केवल आने वाले रिफैक्टरिंग का मामला है। उसी समय, स्प्रिंग WebClient के आधार पर निर्मित एक कस्टम क्लाइंट का उपयोग प्रसंस्करण के लिए किया जाता है।

बड़ा प्रचार

वर्ष में एक बार उपयोगकर्ताओं के लिए एक बड़ा अभियान परियोजना पर होता है - यह एक ही हाईलोड है, क्योंकि इस समय हम एक ही समय में लाखों उपयोगकर्ताओं के साथ काम करते हैं।

आमतौर पर पीक लोड छुट्टियों के दौरान होता है, लेकिन यह पदोन्नति पूरी तरह से अलग स्तर है। पदोन्नति से पहले वर्ष के अंतिम दिन, हमने 27,580,890 यूनिट माल बेचा। डेटा को आधे घंटे से अधिक समय तक संसाधित किया गया, जिससे उपयोगकर्ताओं को असुविधा हुई। उपयोगकर्ताओं को भाग लेने के लिए पुरस्कार मिला, लेकिन यह स्पष्ट हो गया कि इस प्रक्रिया को तेज करने की आवश्यकता है।

2019 की शुरुआत में, हमने फैसला किया कि हमें ElasticSearch की आवश्यकता है। एक पूरे वर्ष के लिए, हमने इलास्टिक में प्राप्त डेटा के प्रसंस्करण और मोबाइल एप्लिकेशन और साइट के एपीआई में इसके आउटपुट का आयोजन किया। परिणामस्वरूप, अभियान के दौरान अगले वर्ष हमने 6 मिनट में 15 131 783 रिकॉर्ड संसाधित किए।

चूंकि हमारे पास बहुत सारे लोग हैं जो सामान खरीदना चाहते हैं और पदोन्नति में पुरस्कार ड्रा में भाग लेते हैं, यह एक अस्थायी उपाय है। अब हम Elastic के लिए प्रासंगिक जानकारी भेज रहे हैं, लेकिन भविष्य में हम पिछले महीनों के संग्रह की जानकारी को स्थायी भंडार के रूप में Postgres में स्थानांतरित करने की योजना बना रहे हैं। आदेश में लोचदार सूचकांक को रोकना नहीं है, जिसकी सीमाएं भी हैं।

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

फिलहाल, हमने इलास्टिक को उन सभी सेवाओं में स्थानांतरित कर दिया है जो हम चाहते थे और अब के लिए विराम दे चुके हैं। अब, Postgres में मुख्य लगातार भंडारण के शीर्ष पर, हम इलास्टिक में एक सूचकांक का निर्माण कर रहे हैं, जो उपयोगकर्ता लोड पर ले जाता है।

भविष्य में, हम सेवाओं को स्थानांतरित करने की योजना बनाते हैं यदि हम समझते हैं कि डेटा अनुरोध बहुत विविध हो जाता है और असीमित संख्या में कॉलम द्वारा खोजा जाता है। यह अब Postgres के लिए एक कार्य नहीं है।

यदि हमें कार्यात्मक में पूर्ण-पाठ खोज की आवश्यकता है, या यदि हमारे पास बहुत सारे अलग-अलग खोज मानदंड हैं, तो हम पहले से ही जानते हैं कि इसे लोचदार में अनुवादित करने की आवश्यकता है।

⌘⌘⌘

पढ़ने के लिए धन्यवाद। यदि आपकी कंपनी भी ElasticSearch का उपयोग करती है और इसके अपने कार्यान्वयन मामले हैं, तो हमें बताएं। यह जानना दिलचस्प होगा कि दूसरों के पास कैसे :-)

ElasticSearch के साथ एक हाईलोड परियोजना पर लोड अनुकूलन