कैसे Yandex.Mail इन्फ्रास्ट्रक्चर 13 साल से अधिक हो गया है

21 वीं सदी के दूसरे दशक में, मेल न केवल लोगों के बीच पत्राचार है। उपयोगकर्ताओं को उम्मीद है कि मेल उन्हें दैनिक कार्यों को हल करने में मदद करेगा, समय बचाएगा, लापता जानकारी का सुझाव देगा। हम लगातार Yandex.Mail में नए टच जोड़ रहे हैं जो उपयोगकर्ताओं के जीवन को थोड़ा आसान बनाते हैं। आज हम आपके साथ Yandex.Mail में 13 साल में किए गए पथ पर फिर से जाना चाहते हैं, जो सेवा के वास्तुकला और बुनियादी ढांचे के विकास पर विशेष ध्यान देता है।



अब कुछ लोगों को याद है कि Yandex.Mail का पहला संस्करण PHP में लिखा गया था, और पत्र मेटा जानकारी के बगल में सीधे रिलेशनल डेटाबेस में संग्रहीत किए गए थे। इतने दूर नहीं 2000 में, एक दर्जन सर्वरों पर पूरी मेल सेवा फिट है। सर्वर स्वयं पूरी तरह से मैनुअल मोड में सेवित थे: डिस्क कॉन्फ़िगरेशन से ऑपरेटिंग सिस्टम स्थापित करने के लिए, कोई स्वचालन नहीं था।

2002 वर्ष

पहली चीज जिसे छोड़ना पड़ा, वह PHP भाषा थी। उस समय, इसे विकसित करने में मदद करने की तुलना में अधिक बार हस्तक्षेप किया गया।



आसपास कई प्रथम श्रेणी के पर्ल विशेषज्ञ थे, पर्ल के लिए पहले से ही बड़ी संख्या में पुस्तकालय थे, और हमने अपाचे + पर्ल का उपयोग करके मेल को फिर से लिखा। यह तेज और आसान हो गया है।

2005 वर्ष

थोड़ा और समय बीत गया, और मौजूदा अपाचे मल्टीप्रोसेस मॉडल लोड से निपटने के लिए बंद हो गया। पर्ल इंटरप्रेटर और मेटा-इंफॉर्मेशन रिपॉजिटरी से इसके कनेक्शन की विशेषताओं के द्वारा एक अलग समस्या बनाई गई थी। परिणामस्वरूप, अपाचे 2 के बीटा संस्करण सहित प्रयोगों की एक श्रृंखला के बाद, हमने अपना स्वयं का मॉड्यूलर एप्लिकेशन सर्वर लिखा जिसे बैदा कहा गया। यह एक थ्रेड और इवेंट-लूप अनुरोध प्रसंस्करण मॉडल दोनों का उपयोग कर सकता है, यह एक्सटेंशन को जोड़ने के लिए बहुत सुविधाजनक है, जिसमें भाषा दुभाषियों भी शामिल हैं - उदाहरण के लिए, जेएस। सर्वर, अधिकांश Yandex.Mail कोड की तरह, C ++ में लिखा जाता है। कई मायनों में, यह नेटवर्क एक्सचेंज और थ्रेड्स के साथ काम करने के लिए एक लाइब्रेरी है, जिसे बढ़ते हुए लोड के साथ सेवा सुनिश्चित करने के लिए आवश्यक था।

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

2006 वर्ष

यह स्पष्ट हो गया कि डेटा की बढ़ती मात्रा के साथ एक संबंधपरक भंडार में संदेश निकायों को संग्रहीत करने से काम नहीं चलेगा। इसलिए पत्रों के एक विशेष भंडार के लिए एक आदेश था, जिसे मुल्का कहा जाता था। प्रौद्योगिकी के विकास के आठ वर्षों में इतने सारे वास्तु परिवर्तन नहीं हुए हैं, हालांकि भंडारण आकार में कई गुना बढ़ गया है। अब, मेल को छोड़कर, इसका उपयोग Yandex.Disk में फ़ाइलों को संग्रहीत करने के लिए किया जाता है।

अलग-अलग भंडारण के लॉन्च के बाद से, हमने सर्वर पर डिस्क सबसिस्टम के कॉन्फ़िगरेशन के साथ प्रयोग किया: हमने अलग-अलग RAID स्तरों की कोशिश की और उपकरणों को बड़े विभाजन में संयोजित किया। RAID5 कॉन्फ़िगरेशन सबसे लंबे समय तक चला, लेकिन इसमें ऐसी खामियां थीं जिन्हें संबोधित करने की आवश्यकता थी: RAID5 को चेकसम की गणना के साथ-साथ ब्लॉक का फिर से पढ़ना आवश्यक था जब इसे फिर से लिखा गया था, जो लिखने की गति को कम करता है। यदि सरणी को फिर से बनाना आवश्यक है, तो इसका प्रदर्शन भी लंबे समय तक खराब हो जाता है।



फिर हमने SCSI के बजाय SATA ड्राइव के साथ प्रयोग करना शुरू किया। यह पता चला है कि बिना RAID5 SATA डिस्क हमारे कॉन्फ़िगरेशन में RAID5 में इकट्ठे SCSI के रूप में लगभग एक ही डेटा एक्सेस स्पीड देते हैं। फॉल्ट टॉलरेंस सुनिश्चित करने के लिए या तो कॉन्फ़िगरेशन को ऑप्टिमाइज़ करना, या अपने स्वयं के समाधान के साथ आना आवश्यक था।

2007 वर्ष

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



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

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

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

2008 साल

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

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

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

अब मेल के साथ पोस्टफिक्स को बदलने का समय आ गया है। हमने अपने खुद के SMTP सर्वर NwSMTP को बुलाया । यह एक घटना-आधारित सर्वर के रूप में कल्पना की गई थी जो असीमित संख्या में कनेक्शन को संभालने में सक्षम था। प्रसिद्ध NGINX वेब सर्वर समान रूप से व्यवस्थित है, लेकिन उस समय इसमें SMTP- प्रॉक्सी के लिए समर्थन नहीं था। इसलिए हम लगभग तुरन्त पत्र प्राप्त करने लगे। NwSMTP का विकास काफी दिलचस्प था: रोलआउट बहुत बार होते थे - कभी-कभी प्रति घंटे संस्करण के अनुसार। नए संस्करण को इकट्ठा करने के तुरंत बाद, इसे एक उत्पादन मशीन पर रोल आउट किया गया और देखा गया कि क्या हो रहा है। इस तरह की दक्षता उत्पाद को बहुत तेज़ी से जारी करने की अनुमति देती है। नाम नाम एम्एसएमटीपी यहाँ से आया है, यह नेक्स्ट वीक एसएमटीपी के लिए एक संक्षिप्त नाम है: इसमें लगभग कोई भी कार्य सात दिनों में पूर्ण विकास चक्र से गुजरता है और सर्वर डेवलपमेंट टीम इस सवाल का जवाब देती है "आप यह कब करेंगे?": "अगले सप्ताह"।

2008 के मध्य में, जब हमने जैबर सर्वर लॉन्च किया, एक प्रयोग के रूप में हमने नए पत्रों की वास्तविक समय सूचनाएँ बनाईं। स्टेजिंग सिस्टम को धीमा नहीं करने के लिए, सूचनाओं ने यूडीपी प्रोटोकॉल के अनुसार काम किया, और एक्सएमपी पैकेज में रूपांतरण के लिए सुविधाजनक एक्सएमएल डेटा के अंदर काम किया। आज, "एक्सएमपी पर यूडीपी" के बारे में चुटकुले मुस्कुराहट का कारण बनते हैं, लेकिन उस समय इसने काम किया, हालांकि कुछ सीमाओं और कुछ सूचनाओं के नुकसान के साथ।

2009 साल

इस समय तक, Yandex.Mail में कई इंटरफेस एक साथ काम कर रहे थे। नियो इंटरएक्टिव नहीं था: WMI के अंदर HTML पेज जेनरेट किया गया था। आधुनिक में इंटरैक्टिव था, लेकिन एक ही वास्तुकला पर बनाया गया था।



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



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

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

इस साल हमने धागे बनाए, जो निश्चित रूप से, डेटाबेस संरचना और भार को बहुत प्रभावित करते थे।

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

दस्तावेज़ दर्शक के बारे में एक अलग कहानी

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

2010 का साल

इस वर्ष हमने मेल द्वारा खोज को पूरी तरह से भुनाया। उस समय जो कार्यान्वयन मौजूद था, वह काम की गति और खोज परिणाम की गुणवत्ता के साथ हम दोनों के अनुरूप नहीं था। खोज प्रसंस्करण के परिणामस्वरूप, एक प्रणाली बनाई गई जिसके आधार पर न केवल पत्रों की वास्तविक खोज काम करती है, प्रति दिन लाखों अनुरोधों की सेवा करती है, बल्कि कुछ अन्य Yandex.Mail फ़ंक्शन भी हैं।

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

फिर 2010 में, हमने Yandex.Mail प्रौद्योगिकियों के आंतरिक यैंडेक्स पत्राचार (हमारे सहयोगियों ने बहुत से पत्र लिखे) का अनुवाद करने के लिए एक बड़ा काम किया। यह डोमेन के लिए लगभग मेल के समान ही काम करता है, लेकिन कंपनी की अन्य आंतरिक सेवाओं के साथ एकीकृत है। लगभग सभी नए कार्यों को पहले कॉर्पोरेट मेल में परीक्षण किया जाता है, डीबग किया जाता है, कार्यात्मक रूप से परिष्कृत किया जाता है, और उसके बाद ही वे सभी उपयोगकर्ताओं के लिए उपलब्ध होते हैं।

2011 वर्ष

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

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

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

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

हमारे दिन

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

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

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

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



इस बीच, इंटरनेट पर बड़े बदलाव आए हैं। IPv4 , 6 2012 IPv6 . IPv6. IPv6 mail.yandex.com . IPv6 .

XScript, , . web-, API. - WMI Baida .

IMAP . IMAP , , .

, , , -: , , . , , , , ..