Azure BLOB संग्रहण में किसी साइट के लिए एक छवि संग्रह संग्रहीत करें

लेख में लाखों विज्ञापनों वाले किसी साइट के लिए एक छवि संग्रह के बजट भंडारण के आयोजन के अनुभव का वर्णन है।



मेरे मामले में, चित्रों को अपार्टमेंट, घरों, भूखंडों आदि की तस्वीरों के रूप में समझा जाता है। मेरी अपनी परियोजना है जो अचल संपत्ति की बिक्री और किराये के विज्ञापनों वाली एक साइट है। साइट लगभग 6 साल के लिए रही है और इस दौरान काफी संख्या में विज्ञापन जमा हुए हैं। प्रत्येक ऑब्जेक्ट कार्ड पर फोटो प्रति विज्ञापन औसतन 8 तस्वीरें प्रदर्शित की जाती हैं। दरअसल, मैं इन तस्वीरों को क्लाउड में स्टोर करने जा रहा हूं ताकि बाद में मैं उन्हें ऑब्जेक्ट कार्ड पर आगंतुकों को दिखा सकूं।

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

आगंतुकों को विज्ञापनों के चयन या ऑब्जेक्ट के कार्ड में जो तस्वीरें दिखाई देती हैं, वे वास्तव में तृतीय-पक्ष संसाधनों से भरी हुई हैं।

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

मैं क्लाउड में स्टोर होने वाले डेटा की मात्रा लगभग 3-4 टेराबाइट है। प्लस कई गीगाबाइट का दैनिक लाभ। यह देखते हुए कि यह नवाचार सीधे पैसा नहीं लाएगा, यह केवल अप्रत्यक्ष रूप से आगंतुक द्वारा निर्णय लेने को प्रभावित कर सकता है, जिस बजट में मैं बहुत मामूली से मिलना चाहता था वह 1000-2000 आर है। प्रति माह। यह बिल्कुल मुफ्त में अच्छा होगा, लेकिन मुझे ऐसा अवसर नहीं मिला।

नीला

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

Azure तीन भंडारण स्तरों के साथ BLOB भंडारण प्रदान करता है: हॉट, कूल और आर्काइव। सभी स्तरों पर कीमतें अलग-अलग हैं। सामान्य तौर पर, हॉट्टर पठन / लेखन को सस्ता करता है और अधिक महंगा मासिक भंडारण शुल्क, और इसके विपरीत। हॉट पर - बहुत लिखने / पढ़ने और हटाने के लिए लाभदायक है, लेकिन लंबे समय तक स्टोर करना महंगा है। संग्रह करना सस्ता है लेकिन पढ़ना / लिखना महंगा है। इसके अलावा, संग्रह और ठंडे स्तरों पर, जल्दी हटाने के लिए एक शुल्क है - इसका मतलब है कि अगर मैं एक निश्चित अवधि की तुलना में पहले एक वस्तु को (या किसी अन्य स्तर पर स्थानांतरण) हटाता हूं, तो मुझे अभी भी पूरी अवधि के लिए शुल्क लिया जाएगा। संग्रह स्तर के लिए, यह 180 दिनों का है, ठंड के लिए - 30।

कीमतों

संग्रह स्तर पर संग्रहण लागत $ 0.0023 प्रति जीबी है, ठंड पर $ 0.01 और गर्म पर $ 0.0196 है। वर्तमान दर पर, यह लगभग 0.15, 0.65 और 1.28 रूबल है।

मैंने अमेज़ॅन और Google में लागत के साथ तुलना की, यह पता चला कि एज़्योर सस्ता है।

	नीला	अमेज़न (S3)	गूगल
गरम	$ 0.0196	$ 0.024	$ 0.026
ठंडा	$ 0.01	$ 0.01	$ 0.01
पुरालेख	$ 0.0023	$ 0.0045	$ 0.007

भंडारण की लागत के अलावा, संचालन की लागत को ध्यान में रखना आवश्यक है - वे सभी स्तरों पर भिन्न भी हैं। कीमतें 10,000 लेनदेन के लिए हैं।

गरम
पढ़ें: $ 0.0043, लिखें: $ 0.054

ठंडा
पढ़ें: $ 0.01, लिखिए: $ 0.10

पुरालेख
पढ़ें: $ 6, लिखें: $ 0.12

काम का तर्क

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

तस्वीरों को संसाधित करने की प्रक्रिया को निम्नलिखित चरणों में वर्णित किया जा सकता है:

1. जैसे ही विज्ञापन आयात फ़ाइल से विज्ञापन गायब हो जाता है, अर्थात् भागीदार ने इसे प्रकाशित करना बंद कर दिया, प्राथमिकता कतार में एक प्रविष्टि बनाई गई है, जहां प्राथमिकता आगंतुकों द्वारा विचारों की संख्या है - जितना अधिक विचार, उतना ही अधिक संभावना है कि संग्रहित होने के बाद, वस्तु को आगे देखा जाएगा।
2. जब कतार से रिकॉर्ड का प्रसंस्करण किया जाता है, तो विज्ञापन के लिए कम (800x600 तक) फ़ोटो युक्त एक BLOB ऑब्जेक्ट बनता है। सीधे तस्वीरों के बजाय समग्र वस्तुओं का उपयोग बचत के कारण भी होता है - 8 रिकॉर्डिंग संचालन (प्रति ऑब्जेक्ट औसतन 8 फ़ोटो) के बजाय, एक प्रदर्शन किया जाता है, और प्रत्येक ऑपरेशन में पैसे खर्च होते हैं।
3. BLOB को पहले Hot में लोड किया जाता है, और फिर तुरंत आर्काइव में स्थानांतरित कर दिया जाता है। आर्काइव में सीधे लिखने की कोई संभावना नहीं है, और चूंकि कूल में जल्दी हटाने का शुल्क है, इसलिए हॉट को ट्रांज़िट के रूप में उपयोग करना सस्ता है।
4. BLOB संग्रह तब तक है जब तक मूल फ़ोटो के लिंक सक्रिय हैं (फ़ोटो अब तक भागीदारों से लिंक द्वारा दिखाए गए हैं)।
5. लिंक को कार्यक्षमता के लिए जांचा जाता है जब आगंतुक ऑब्जेक्ट के कार्ड पर जाता है - यदि वे उस पर जाते हैं, तो ऑब्जेक्ट लोकप्रिय है और यह संग्रह से फ़ोटो को पुनर्स्थापित करने के लिए समझ में आता है।
6. यदि मूल फ़ोटो के लिंक मर गए हैं, तो मैं जांचता हूं कि क्या कोई संग्रह प्रतिलिपि है, और यदि ऐसा है, तो मैं संग्रह से कूल पर बहाली के लिए अनुरोध भेजता हूं (संग्रह से एक BLOB ऑब्जेक्ट को पुनर्स्थापित करने में 15 घंटे लग सकते हैं - इसे Microsoft से निर्जलीकरण कहा जाता है)।
7. एक बार BLOB को आर्काइव से रिस्टोर कर लिया गया है, इसे लोकल स्टोरेज में कॉपी किया जाता है और सामान्य तस्वीरों में विभाजित किया जाता है। स्थानीय संग्रहण मेरे सर्वर की हार्ड ड्राइव है।
8. घोषणा कार्ड पर तस्वीरें पहले से ही स्थानीय भंडारण से दी गई हैं।
9. तस्वीरें कई दिनों के लिए स्थानीय भंडारण में संग्रहीत की जाती हैं। यदि इस समय के दौरान स्कैन किए गए थे, तो स्थानीय भंडारण अवधि बढ़ाई गई है। यदि कोई दृश्य नहीं था, तो तस्वीरें स्थानीय भंडारण से हटा दी जाती हैं, लेकिन Azure में कूल स्तर पर रहती हैं।
10. कूल से लेकर आर्काइव तक उनकी नकल की जाती है अगर दो महीने तक कोई दृश्य नहीं था - वस्तु स्पष्ट रूप से लोकप्रिय नहीं है और, तदनुसार, यह कूल में भंडारण के लिए अधिक भुगतान करने का कोई मतलब नहीं है।

पहला लॉन्च

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



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

मैंने स्टैक पर और दस्तावेज़ में खोज की, लेकिन कोई फायदा नहीं हुआ। Stackoverflow और tech support पर एक प्रश्न लिखा। नतीजतन, तकनीकी सहायता के साथ लंबे पत्राचार के बाद, और लॉग के साथ उन्हें प्रदान करते हुए, उन्होंने मुझे बताया कि वे स्थिति को पुन: उत्पन्न कर सकते हैं और यह उनकी तरफ से एक बग है।

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

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

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

निष्कर्ष

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

जब Azure Blob-storage में रिलीज होगी, तो मैं यहां जोड़ दूंगा कि क्या मैं मुआवजा पाने में कामयाब रहा। मासिक खर्चों के बारे में, यह लागत का लगभग 10% है।