👨🏽‍⚖️ 💅🏼 🚲 टर्बो पृष्ठों की सामग्री प्रणाली कैसे व्यवस्थित की जाती है: योजनाएं, तथ्य और थोड़ा सा इतिहास 👲🏿 🦅 😝

टेलीकॉमडेली के अनुसार , रूस में लगभग 30% मोबाइल इंटरनेट उपयोगकर्ताओं को रोजाना डाउनलोड करने में समस्या होती है। हालांकि, इसका कारण न केवल असमान कवरेज में हो सकता है, बल्कि पृष्ठ के बहुत अधिक "वजन" में भी हो सकता है।

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

यह जादू कैसे काम करता है? पूर्ण टर्बो पृष्ठ बनने से पहले डेटा पथ क्या है? मेरा नाम Stas Makeev है, मैं प्रौद्योगिकी टर्बो पृष्ठों के विकास का नेतृत्व करता हूं। अब मैं सब कुछ समझाने की कोशिश करूंगा।

लेकिन सबसे पहले, यह थोड़ा सा सारांश है ताकि जब मैं विवरण में तल्लीन करना शुरू करूं तो आप खो न जाएं।

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

साइट मालिकों के पास सिस्टम से जुड़ने के कई तरीके हैं:

. : YML — -, RSS – ;
API: ( );
: - .

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

काम की एक बहुत ही सरल सामान्य योजना इस प्रकार है:

ये सब कैसे शुरू हुआ

सामग्री प्रणाली के पहले संस्करण को काफी सरल रूप से व्यवस्थित किया गया था: हर कुछ मिनटों में, कार्यक्रम के अनुसार, वही कार्यक्रम Yandex आंतरिक क्लाउड सर्वर पर लॉन्च किया गया था। इसमें कई चरण शामिल थे, प्रत्येक अगला भाग जो पिछले डेटा के लिए तैयार था, जो हम जानते हैं:

आरएसएस फ़ीड की सूची डाउनलोड की गई थी, दस्तावेज़ पार्सर लॉन्च किया गया था;
छवियों की एक सूची पार्सर परिणामों से निकाली गई थी;
कैश्ड चित्रों को सीडीएन में लोड नहीं किया गया था;
संसाधित दस्तावेज केवी भंडार में डाले गए थे।

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

हमने विभिन्न ट्रिक्स की मदद से स्थिति को नियंत्रण में रखने में कामयाबी हासिल की: पहली चीज जो हमने की वह थी एक अलग प्रक्रिया में पहला कदम (RSS फीड्स + एक डॉक्यूमेंट पार्सर डाउनलोड करना)। यही है, जबकि एक पिछली पुनरावृत्ति के लिए चित्रों को संसाधित कर रहा था, दूसरी प्रक्रिया पहले से ही अगले के लिए फीड डाउनलोड कर रही थी। कुछ समय बाद, यह स्पष्ट हो गया: इस रूप में, सिस्टम को स्केल करना बहुत मुश्किल है। हमें मौलिक रूप से कुछ नया चाहिए।

नई सामग्री प्रणाली में RSS, API और YML को संसाधित करना

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

पहला घन डाउनलोड RSS फ़ीड्स और गुजरता है;
दूसरा - एक-एक करके फीड लेता है, सामग्री को पार्स करता है। बाहर निकलने पर - अलग दस्तावेज़;
तीसरा - एक समय में एक दस्तावेज़ लेता है, चित्रों और वीडियो को संसाधित करता है, केवी-भंडारण में सब कुछ रिकॉर्ड करता है।

उसी फ़ीड को न केवल टर्बो में पंजीकृत किया जा सकता है, बल्कि हमारी अन्य सेवाओं पर भी - समाचार या बाजार में, उदाहरण के लिए। यदि उनमें से प्रत्येक अपने दम पर डेटा डाउनलोड करता है, तो वेबमास्टर्स सर्वर पर लोड स्वीकार्य एक से कई गुना अधिक होगा। कैसे सही है? फ़ीड को एक बार डाउनलोड करें, और फिर सभी उपभोक्ता सेवाओं को सामग्री वितरित करें - Yandex.Robot यह करता है। हम सामग्री डाउनलोड करने के लिए उसकी सेवाओं का उपयोग करते हैं: हम Yandex.Webmaster से RSS की एक सूची लेते हैं और टर्बो में पंजीकृत YML फ़ीड, इसे रोबोट को हस्तांतरित करते हैं और डाउनलोड परिणामों की सदस्यता लेते हैं।

प्राप्त आंकड़ों पर, पार्सर शुरू करें। बस मामले में, मैं आपको याद दिलाता हूं: RSS फ़ीड सिर्फ एक फ़ाइल ".XML" प्रारूप में है, जो भागीदार के मेजबान पर एक स्थिर URL द्वारा सुलभ है। इस फ़ाइल में साइट पर सभी अद्यतनों के बारे में जानकारी है - कौन से दस्तावेज़ नए हैं, जिन्हें बदल दिया गया है। पिछले कुछ घंटों में केवल सबसे अद्यतित जानकारी आदर्श फीड्स में होगी: प्रति सौ सौ किलोग्राम से अधिक कोई दस्तावेज़ नहीं।

वास्तविकता काटती है: कभी-कभी फाइलें बहुत लंबे समय तक फ़ीड के अंदर होती हैं और कभी नहीं बदलती हैं। ऐसे मामलों में पुनरावृत्ति से कैसे बचें? हम प्रत्येक दस्तावेज़ के हैश की गणना करते हैं, इसे डेटाबेस में संग्रहीत करते हैं, और हैश के बदलने तक कुछ भी नहीं करते हैं।

सामग्री प्रणाली के दृष्टिकोण से YML फ़ीड्स और API को संसाधित करना व्यावहारिक रूप से RSS के साथ बातचीत करने से अलग नहीं है: YML के लिए, हम एक और पार्सर शुरू करते हैं, और API द्वारा प्रेषित डेटा सीधे Yandex.Webmaster से प्राप्त किया जाता है।

छवि और वीडियो प्रसंस्करण

दस्तावेज़ जो पार्सर के आउटपुट पर प्राप्त होता है, वह KV-स्टोरेज के लिए लिखने के लिए लगभग तैयार है। भेजने से पहले केवल एक चीज बची है, वह है छवियों और वीडियो को संसाधित करना: सीडीएन में कैश और दस्तावेज़ में लिंक को बदलना। यहाँ फिर से हम मदद के लिए रोबोट की ओर मुड़ते हैं।

सबसे पहले, हम प्रत्येक चित्र और वीडियो की जांच करते हैं: क्या वे सीडीएन में हैं? यदि सब कुछ पहले से ही कैश है, तो लिंक्स को बदलें और अद्यतन दस्तावेज़ को KV रिपॉजिटरी में भेजें। अन्यथा:

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

इस समय एक और घन डाउनलोड परिणाम प्राप्त करता है, सीडीएन पर डेटा अपलोड करता है और डेटाबेस को अपडेट करता है।

ऐसी योजना में, नियोजन से संबंधित एक और महत्वपूर्ण समस्या हल हो सकती है: रोबोट समझता है कि विभिन्न होस्ट से डेटा डाउनलोड करना कितना तेज़ है, और ओवरलोड की अनुमति नहीं देता है।

एक नया दस्तावेज़ निम्न प्रकार का पथ:

दस्तावेज़ फ़ीड में दिखाई देता है।
रोबोट फ़ीड डाउनलोड करता है;
पार्सर एक नए दस्तावेज़ को पता चलता है और इसे आगे भेजता है;
हम जाँचते हैं कि दस्तावेज़ से चित्र डेटाबेस में उल्लिखित नहीं हैं, डाउनलोड का आदेश दें, दस्तावेज़ अस्थायी भंडारण (देरी) के लिए भेजा जाता है। जब दस्तावेज़ होता है, तो रोबोट चित्रों को डाउनलोड करता है, उन्हें सीडीएन में कैश किया जाता है, और लिंक डेटाबेस में दिखाई देते हैं;
, CDN, KV-.
: , Delay.

टर्बो पृष्ठों से कनेक्ट करने का एक और तरीका है, जिसके लिए वेबमास्टर को कुछ भी करने की आवश्यकता नहीं है - ऑटोपरर। यह सामग्री साइट के स्रोत डेटा के आधार पर टर्बो पेज बनाता है। आप समाप्त पृष्ठों के उदाहरण देख सकते हैं, Yandex.Webmaster में विज्ञापन और विश्लेषिकी कॉन्फ़िगर कर सकते हैं।

टर्बो मार्क का निर्माण करते समय मूल जानकारी का क्या उपयोग किया जाना चाहिए, यह पहचानने में मुख्य कठिनाई जो ऑटोपार्सर का सामना करती है, वह है HTML मार्कअप। ऐसा करने के लिए, हमारे पास कई ऑफ़लाइन प्रक्रियाएं हैं जो यह समझने की कोशिश कर रही हैं कि किसी विशिष्ट होस्ट को पार्स कैसे किया जाए। मैं दो मुख्य बातों पर ध्यान केंद्रित करूंगा:

सबसे पहला RSS- HTML- . — , RSS- ( ), . , . CatBoost , , . , , , . , . , , , HTML . ? : . – , .
: .. , , , , — . — .

वैसे, एक और लगातार बाधा - कई साइटें रोबोट द्वारा छवियों को डाउनलोड करने की क्षमता को अवरुद्ध करती हैं। दुर्भाग्य से, इस समस्या को हल करना असंभव है, और ऐसे पृष्ठों के लिए ऑटोपार्सर उपलब्ध नहीं है।

नतीजतन, सामग्री प्रणाली की पूरी योजना इस तरह दिखती है:

प्रणाली अच्छी तरह से मापनीय हो गई है: अब डेटाबेस, ऑटोपारसर और सिस्टम के अन्य घटकों की सेवा के लिए संसाधनों की एक महत्वपूर्ण राशि का उपयोग किया जाता है (केवल क्यूब को आरएसएस, वाईएमएल और एपीआई को 300 से अधिक प्रोसेसर का उपयोग करने के लिए जिम्मेदार माना जाता है) कोर), और बढ़े हुए भार के मामले में अतिरिक्त क्षमताओं को जोड़ना बहुत मुश्किल नहीं होगा।

अंत तक पढ़ने के लिए धन्यवाद! मुझे उम्मीद है, इस सामग्री के बाद, टर्बो पृष्ठों के काम में आपको अधिक तर्क और कम जादू मिलेगा (वैसे, यहां- टर्बो पृष्ठों के बारे में और भी अधिक जानकारी)। यदि कुछ अभी भी समझ से बाहर है, तो टिप्पणियों में लिखें - हम संपर्क में हैं।

टर्बो पृष्ठों की सामग्री प्रणाली कैसे व्यवस्थित की जाती है: योजनाएं, तथ्य और थोड़ा सा इतिहास

ये सब कैसे शुरू हुआ

नई सामग्री प्रणाली में RSS, API और YML को संसाधित करना

छवि और वीडियो प्रसंस्करण

More articles: