सीमित संसाधनों या मैन्युअल रूप से सूर्यास्त के सामने विशाल तालिकाओं का चयन करें

प्रागितिहास

एक रूपरेखा है जिसमें हमें बड़ी मात्रा में डेटा के साथ काम करना है। विशेष रूप से, एक वंचित तालिका है जिसमें मौजूदा ग्राहकों के सभी मौजूदा ऑफ़र संग्रहीत किए जाते हैं, साथ ही हटाए जाने का इंतजार कर रहे is_deleted = 1 चिह्नित पुराने ऑफ़र भी।

इस तालिका में प्रविष्टियों की संख्या हाल ही में 30 से 50 मिलियन तक थी। सामान्य विकल्प, यहां तक ​​कि ऐसी स्थितियों के तहत, हमेशा काम नहीं किया। इसलिए, संस्थापक पिता (एवगेनी वासिलिविच) इस तरह से तालिका को फिर से इकट्ठा करने के तरीके के साथ आए: सभी प्रासंगिक (is_deleted = 0) को एक संरचना के साथ एक तालिका में कॉपी किया गया था, जिसमें तिथि और समय के साथ एक उपसर्ग शामिल है, और जब प्रतिलिपि पूरी हो गई, तो यह केवल मूल तालिका को हटाने और नाम बदलने के लिए बनी रही। मूल।

इस दृष्टिकोण ने मज़बूती से काम किया जब तक कि ऑफ़र के लिए खोज की गति को बढ़ाने के लिए आवश्यक नहीं था। और यहीं से शुरू होती है हमारी छोटी सी कहानी।

बदलाव की हवा

खोज की गति को बढ़ाने के लिए, विचित्र रूप से पर्याप्त, एक खोज इंजन का उपयोग करने का निर्णय लिया गया था। हमने सोलर को चुना। क्यों? क्योंकि हमारे उद्देश्यों के लिए यह अच्छा है। और न केवल हमारे उद्देश्यों के लिए। यदि समय है, तो मुझे इस खोज इंजन पर एक लेख लिखना सुनिश्चित होगा।

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

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

समाधान के लिए खोजें

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

पहला विकल्प । यह किसी भी तरह एक मौजूदा स्क्रिप्ट का अनुकूलन करने के प्रयास में शामिल था। लेकिन हम सफल नहीं हुए, और लगभग तुरंत इसे छोड़ दिया।

दूसरा विकल्प हैंडलरसॉकेट का उपयोग करना है। एचएस तेज, विश्वसनीय और अंततः फैशनेबल है। हालांकि, यह पता चला कि एचएस डेटा के एक विशाल सरणी को पढ़ने के लिए उपयुक्त नहीं है। एचएस जल्दी से यादृच्छिक रूप से स्थित व्यक्तिगत रिकॉर्ड खोजने का एक बड़ा काम करता है। और जब क्रमिक रूप से भागों में एक बड़े डेटा सरणी को पढ़ते हैं, तो प्रत्येक अगले चरण पर एक मंदी होती है, यदि आप सीमा, ऑफसेट का उपयोग करते हैं। लेकिन यह सबसे बड़ी समस्या नहीं है जब एचएस का उपयोग किया जाता है - हमें इस स्थिति के अनुसार चयन करना होता है_ डिलेटेड = 0, और यह फ़ील्ड इंडेक्स नहीं थी। और आम तौर पर बोलना, इसे इस तरह बनाना व्यर्थ है। इसलिए, बहादुर हैंडलर सॉकेट, जो पहले से ही अन्य कार्यों के लिए खुद को साबित कर चुका है, इस बार उम्मीदों पर खरा नहीं उतरा।

सौभाग्य से, एक तीसरा विकल्प था जिसे मैंने व्यक्तिगत रूप से पहले कभी इस्तेमाल नहीं किया था। यह मूल पेशी हैन्डलर है । वह क्या करने की अनुमति देता है और वह किसके लिए अच्छा है? यह गति की हानि के बिना एक निश्चित स्थिति (सूचकांक क्षेत्र द्वारा भी नहीं) द्वारा रिकॉर्ड के क्रमिक पढ़ने की अनुमति देता है, जो आमतौर पर सीमा, ऑफसेट या बीच की गणना के कारण होता है। आपको बस इतना करना है कि हैंडलर खोलना है, एक निश्चित स्थिति (READ FIRST) के साथ डेटा का पहला टुकड़ा पढ़ें और फिर, शर्तों को बदले बिना, READ NEXT को लागू करें जबकि कम से कम कुछ डेटा है। क्रियाओं का अनुक्रम सी-शनी दृष्टिकोण के साथ जुड़ा हुआ है, उदाहरण के लिए, निर्देशिका को स्कैन करने के लिए। और यहां सबसे खुशी की बात यह है कि सूचक उस स्थान पर रहता है जहां हमने इसे आखिरी बार छोड़ा था।

नतीजतन, हमारे पास पढ़ने की निरंतर उच्च गति है और तालिका में डेटा पढ़ते समय स्मृति का उचित उपयोग होता है, भले ही तालिका में 270 मिलियन रिकॉर्ड जमा हो गए हों। जब तक हमें यह समाधान मिला, तब तक बहुत सारे रिकॉर्ड थे। यह बहुत है या थोड़ा है? प्रश्न सापेक्ष है। लेकिन अगर इस तरह की मात्रा के कारण सेवा विफल होने लगती है, तो बहुत कुछ।

सीमित संसाधनों की स्थितियों में, यह समाधान गति और विश्वसनीयता में सबसे अधिक फायदेमंद साबित हुआ। मैं कहना चाहता हूं कि यदि आप एक पुनरावृत्ति में पहले १०,००० रिकॉर्ड पढ़ने में सक्षम थे, तो आप बाद के सभी रिकॉर्ड भी गिन सकते हैं, चाहे कितने भी हों।

पुनश्च

मुझे लगता है कि यह समाधान निश्चित रूप से किसी के काम आएगा।

धन्यवाद

मैं यूरी मसलेंनिकोव को धन्यवाद कहना चाहता हूं, जिन्होंने वास्तव में हैंडलर के विचार का प्रस्ताव दिया था।