टॉपफेस फोटो स्टोरेज अब ओपन सोर्स है

हम फ़ोटो संग्रहीत करने में अच्छे हैं, इसलिए हमने तय किया कि अगर आप अपना खुद का tumblr, facebook या imgur बनाना चाहते हैं तो आपके लिए जीवन आसान हो जाएगा। मामला वास्तव में सरल है, लेकिन सूक्ष्मताएं हैं जो पहले से सबसे अच्छी तरह से जानी जाती हैं। इसके अलावा, हमने नोड.जेएस पर सब कुछ किया , जो 100,000,000 से अधिक तस्वीरों के साथ भंडार का बहुत विशिष्ट नहीं है।



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

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

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

मैं घटकों के बारे में संक्षेप में बताने की कोशिश करूंगा।

बैकपैक समन्वयक

GitHub से लिंक करें । यहां आप सीख सकते हैं कि सिस्टम को संपूर्ण रूप से कैसे तैनात किया जाए।

समन्वयक - वह स्तर जिसके साथ एप्लिकेशन स्टोर में डेटा को बचाने के लिए संचार करता है। आदेश में सक्षम:

• रखो और दोहराने के लिए कहो
• शेयर आँकड़े

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

शार्द - कई बैकपैक उदाहरण हैं जो समान डेटासेट साझा करते हैं।

जब किसी तस्वीर को स्टोरेज पर अपलोड किया जाता है, तो इसे शार्द के एक उदाहरण पर सहेजा जाता है, जिसके बाद शार्द के अन्य उदाहरणों की प्रतिकृति के लिए कार्य बनाए जाते हैं। हमारे पास अलग-अलग भौतिक मशीनों पर प्रत्येक शार्क के लिए 3 बैकपैक उदाहरण हैं, ताकि उल्कापिंड एक सर्वर में गिरने के मामले में, शार्क कार्य करना जारी रखे।

यह ध्यान देने योग्य है कि हम अनावश्यक आंदोलनों को बनाने के लिए अपना सर्वश्रेष्ठ प्रयास कर रहे हैं, इसलिए जब रिपॉजिटरी में एक नया शार्क जोड़ते हैं, तो कोई असंतुलन नहीं होता है। हम सिर्फ एक नए शार्क में अधिक सक्रिय रूप से लिखते हैं। ऐसा इसलिए नहीं है क्योंकि पुनर्संतुलन मुश्किल है (वास्तव में हाँ) या क्योंकि हमें महारत हासिल नहीं है (वास्तव में महारत हासिल है, तो हमारे दिमाग बदल गए), लेकिन क्योंकि यह वास्तव में आवश्यक नहीं है।

बैग-प्रतिलिपिकार

GitHub से लिंक करें ।

प्रतिकृति स्तर, जो केवल वह करता है जो बैकपैक उदाहरणों पर चित्रों को तोड़ता है। उठने के बाद दुर्गम उदाहरणों से उनका डेटा मिलता है। कम से कम एक बार संदेश प्रसंस्करण की गारंटी के लिए zk-redis-queue मॉड्यूल का उपयोग करता है।

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

बैग

GitHub से लिंक करें ।

डेटा भंडारण का स्तर, भंडारण का बहुत नमक। वेबदाव (GET, PUT) को कमांड कर सकते हैं:

• फ़ाइल सहेजें
• फ़ाइल प्राप्त करें
• आंकड़े बताने के लिए - यह वेबदाव नहीं है, लेकिन सही बात है

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

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

नगीनक्स की तुलना में एक बैकपैक के लाभों को परीक्षण द्वारा समझा जा सकता है। हमने 1,700,000 रैंडम तस्वीरें लीं और एक ही सर्वर पर बैकपैक और नगनेक्स में संग्रहीत किया। हमने 100,000 यादृच्छिक फ़ाइलों का चयन किया और उन्हें 20 धाराओं में पढ़ने का फैसला किया।

लाल रेखा बैकपैक है, हरी रेखा नगीनक्स है।

प्रति सेकंड अनुरोध

बैकपैक ने हर चीज के बारे में 732 सेकंड का समय लिया, जबकि नेगनेक्स 1200 सेकंड, अंतर 33% है।

डिस्क प्रति सेकंड पढ़ता है

यहां यह स्पष्ट हो जाता है कि क्यों: nginx डिस्क से बहुत अधिक पढ़ता है, डिस्क सिर को अधिक स्थानांतरित करता है, और यह ऑपरेशन मुफ्त नहीं है। समय के साथ, नगनेक्स डिस्क कैश को मेटाडेटा से भरता है और त्वरित करता है, लेकिन यहां तक ​​कि यह पर्याप्त नहीं है। यदि और भी अधिक डेटा होता, तो nginx डिस्क कैश में आने की संभावना भी कम होती। और हमारे पास बहुत अधिक डेटा है।

मैं / ओ उपयोग

ताकि आप यह न सोचें कि मैं आपको बेवकूफ बना रहा हूं, यह i / o ग्राफ़ पर स्पष्ट है कि हर बार प्रत्येक विकल्प ने डिस्क का 100% उपयोग किया है।

सभी परियोजनाएं नोड्स 0.10 का समर्थन करती हैं और रिसाव नहीं लगता है, कम से कम ढेर काम के हफ्तों के बाद भी स्थिर रहता है। हम राक्षस के माध्यम से राक्षसों को शुरू करते हैं।

यदि आप घर पर बैकपैक स्टैक का विस्तार करने का निर्णय लेते हैं तो हमें खुशी होगी!