ElasticSearch को साथ हाइलोड प्रोजेक्टमा लोड अप्टिमाइजेसन

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

परियोजना कसरी काम गर्दछ

हाम्रो ब्याकएन्डमा, हामी सेवाहरू सिर्जना गर्छौं जसले हाम्रो ग्राहकको वेबसाइट र मोबाइल अनुप्रयोगको प्रदर्शन सुनिश्चित गर्दछ। सामान्य संरचना रेखाचित्रमा देख्न सकिन्छ:

कामको प्रक्रियामा, हामी लेनदेनको ठूलो संख्यामा प्रशोधन गर्छौं: खरिदहरू, भुक्तानीहरू, प्रयोगकर्ता ब्यालेन्सको साथ सञ्चालनहरू, जसको लागि हामी धेरै लगहरू भण्डारण गर्छौं, साथै यो डेटा बाह्य प्रणालीहरूमा आयात र निर्यात गर्छौं।

त्यहाँ रिभर्स प्रक्रियाहरू पनि छन् जब हामी ग्राहकबाट डाटा प्राप्त गर्छौं र प्रयोगकर्तालाई हस्तान्तरण गर्छौं। थप रूपमा, भुक्तानी र बोनस कार्यक्रमहरूसँग काम गर्ने प्रक्रियाहरू अझै छन्।

संक्षिप्त पृष्ठभूमि

सुरुमा, हामीले 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 मार्फत त्यस्ता समयसीमाहरू प्राप्त गर्ने कुनै तरिका छैन - हामीले प्राय: लकहरू प्राप्त गर्यौं, र हामीले सबै अनुरोधहरू प्रशोधन गर्दा, प्रयोगकर्ताहरूले उनीहरूले पुरस्कार प्राप्त गरे वा गरेनन् भनेर जाँच गर्न सकेनन्। यो व्यवसायको लागि धेरै रमाइलो छैन, त्यसैले हामीले प्रशोधनलाई Elasticsearch मा सारियो।

आवधिकता

अब अद्यावधिकहरू निम्न सर्तहरू अनुसार घटना-आधारित कन्फिगर गरिएका छन्:

1. बिक्री अंक। हामीले बाह्य स्रोतबाट डाटा प्राप्त गर्ने बित्तिकै, हामी तुरुन्तै अपडेट सुरु गर्छौं।
2. समाचार। साइटमा कुनै पनि समाचार सम्पादन हुने बित्तिकै, यो स्वतः इलास्टिकमा पठाइन्छ।

यहाँ फेरि यो लोचदार को फाइदाहरु उल्लेख लायक छ। Postgres मा, अनुरोध पठाउँदा, तपाईंले इमानदारीपूर्वक सबै रेकर्डहरू प्रशोधन नगरेसम्म पर्खनु पर्छ। तपाईले 10 रेकर्डहरू इलास्टिकमा पठाउन सक्नुहुन्छ र तुरुन्तै काम सुरु गर्न सक्नुहुन्छ, रेकर्डहरू सबै शार्डहरूमा वितरित हुनको लागि प्रतीक्षा नगरी। निस्सन्देह, केहि शार्ड वा प्रतिकृतिले तुरुन्तै डाटा देख्न सक्दैन, तर सबै कुरा चाँडै उपलब्ध हुनेछ।

एकीकरण विधिहरू

त्यहाँ इलास्टिकसँग एकीकृत गर्ने २ तरिकाहरू छन्:

1. TCP मा मूल ग्राहक मार्फत। नेटिभ ड्राइभर बिस्तारै मर्दैछ: यो अब समर्थित छैन, यो एक धेरै असुविधाजनक वाक्य रचना छ। त्यसकारण, हामी व्यावहारिक रूपमा यसलाई प्रयोग गर्दैनौं र यसलाई पूर्ण रूपमा त्याग्न प्रयास गर्छौं।
2. HTTP इन्टरफेस मार्फत जसले JSON अनुरोधहरू र लुसेन सिन्ट्याक्स दुवै प्रयोग गर्न सक्छ। अन्तिम एउटा पाठ इन्जिन हो जसले इलास्टिक प्रयोग गर्दछ। यस संस्करणमा, हामीले HTTP मा JSON अनुरोधहरू मार्फत ब्याच गर्ने क्षमता पाउँछौं। यो हामीले प्रयोग गर्न खोजेको विकल्प हो।

HTTP इन्टरफेसको लागि धन्यवाद, हामी पुस्तकालयहरू प्रयोग गर्न सक्छौं जसले HTTP क्लाइन्टको एसिन्क्रोनस कार्यान्वयन प्रदान गर्दछ। हामी ब्याच र एसिन्क्रोनस API को फाइदा लिन सक्छौं, जसले उच्च प्रदर्शनको परिणाम दिन्छ, जसले ठूलो पदोन्नतिको दिनहरूमा धेरै मद्दत गर्‍यो (तलको बारेमा थप)

तुलना को लागी केहि संख्याहरु:

• पोस्टग्रेस बाउन्टी प्रयोगकर्ताहरूलाई 20 थ्रेडहरूमा समूह बिना बचत गर्दै: 460713 सेकेन्डमा 42 रेकर्डहरू
• 10 थ्रेडहरूको लागि लोचदार + प्रतिक्रियाशील ग्राहक + 1000 तत्वहरूको लागि ब्याच: 596749 सेकेन्डमा 11 रेकर्डहरू
• 10 थ्रेडहरूको लागि लोचदार + प्रतिक्रियाशील ग्राहक + 1000 तत्वहरूको लागि ब्याच: 23801684 प्रविष्टिहरू 4 मिनेटमा

अब हामीले एक HTTP अनुरोध प्रबन्धक लेखेका छौं जसले JSON लाई ब्याच/नट ब्याचको रूपमा बनाउँछ र पुस्तकालयको पर्वाह नगरी कुनै पनि HTTP क्लाइन्ट मार्फत पठाउँछ। तपाईं सिंक्रोनस वा एसिन्क्रोनस रूपमा अनुरोधहरू पठाउन पनि छनौट गर्न सक्नुहुन्छ।

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

ठूलो पदोन्नति

वर्षमा एक पटक, परियोजनाले प्रयोगकर्ताहरूको लागि ठूलो पदोन्नति होस्ट गर्दछ - यो उही हाइलोड हो, किनकि यस समयमा हामी एकै समयमा लाखौं प्रयोगकर्ताहरूसँग काम गर्छौं।

सामान्यतया बिदाको समयमा लोडको शिखर हुन्छ, तर यो पदोन्नति एकदम फरक स्तरमा छ। अघिल्लो वर्ष, प्रवर्द्धनको दिन, हामीले २७,५८०,८९० युनिट सामान बिक्री गरेका थियौं। डाटा आधा घन्टा भन्दा बढी प्रशोधन गरिएको थियो, जसले प्रयोगकर्ताहरूलाई असुविधाको कारण बनायो। प्रयोगकर्ताहरूले सहभागिताका लागि पुरस्कारहरू प्राप्त गरे, तर यो स्पष्ट भयो कि प्रक्रियालाई द्रुत बनाउन आवश्यक छ।

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

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

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

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

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

यदि हामीलाई कार्यक्षमतामा पूर्ण-पाठ खोज चाहिन्छ वा यदि हामीसँग धेरै फरक खोज मापदण्डहरू छन् भने, हामीलाई पहिले नै थाहा छ कि यसलाई इलास्टिकमा अनुवाद गर्न आवश्यक छ।

⌘⌘⌘

पढ्नु भएकोमा धन्यवाद। यदि तपाईंको कम्पनीले पनि ElasticSearch प्रयोग गर्दछ र यसको आफ्नै कार्यान्वयन केसहरू छन् भने, हामीलाई भन्नुहोस्। अरूहरू कस्तो छन् भनेर जान्न रोचक हुनेछ 🙂

स्रोत: www.habr.com