लाखों-करोड़ों छोटी फ़ाइलों को कुशलतापूर्वक संग्रहीत करें। स्व-होस्टेड समाधान

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

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

विचार यह है:

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

मैं इसे छोटा रखने की कोशिश करूंगा, अगर पोस्ट लंबी है तो मैं पहले ही माफी मांगता हूं।

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

जो लोग लेख पढ़ना पसंद नहीं करते, उनके लिए थोड़ा दस्तावेज़ीकरण आसान है:

यहां и यहां.

और एक ही समय में डॉकर, अब केवल मामले में nginx के अंदर एक विकल्प है:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

अगला:

यदि बहुत सारी फ़ाइलें हैं, तो महत्वपूर्ण संसाधनों की आवश्यकता होती है, और सबसे बुरी बात यह है कि उनमें से कुछ बर्बाद हो जाते हैं। उदाहरण के लिए, क्लस्टर फ़ाइल सिस्टम (इस मामले में, MooseFS) का उपयोग करते समय, फ़ाइल, अपने वास्तविक आकार की परवाह किए बिना, हमेशा कम से कम 64 KB लेती है। अर्थात्, 3, 10 या 30 KB आकार की फ़ाइलों के लिए, डिस्क पर 64 KB की आवश्यकता होती है। यदि एक चौथाई अरब फ़ाइलें हैं, तो हमें 2 से 10 टेराबाइट्स का नुकसान होता है। अनिश्चित काल तक नई फ़ाइलें बनाना संभव नहीं होगा, क्योंकि MooseFS की एक सीमा है: प्रत्येक फ़ाइल की एक प्रतिकृति के साथ 1 बिलियन से अधिक नहीं।

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

डब्ल्यूजेडडी सर्वर। हम डिस्क पर चीजों को क्रम में रखते हैं।

सर्वर गो में लिखा है. सबसे पहले, मुझे फ़ाइलों की संख्या कम करने की आवश्यकता थी। इसे कैसे करना है? संग्रह करने के कारण, लेकिन इस मामले में संपीड़न के बिना, क्योंकि मेरी फ़ाइलें केवल संपीड़ित चित्र हैं। बोल्टडीबी बचाव में आया, जिसे अभी भी अपनी कमियों को दूर करना था, यह दस्तावेज़ीकरण में परिलक्षित होता है।

कुल मिलाकर, एक चौथाई अरब फाइलों के बजाय, मेरे मामले में केवल 10 मिलियन बोल्ट अभिलेखागार बचे थे। यदि मुझे वर्तमान निर्देशिका फ़ाइल संरचना को बदलने का अवसर मिलता, तो इसे लगभग 1 लाख फ़ाइलों तक कम करना संभव होता।

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

WZD सर्वर की वास्तुकला और विशेषताएं।

सर्वर लिनक्स, बीएसडी, सोलारिस और ओएसएक्स ऑपरेटिंग सिस्टम के तहत काम करता है। मैंने केवल Linux के अंतर्गत AMD64 आर्किटेक्चर के लिए परीक्षण किया, लेकिन इसे ARM64, PPC64, MIPS64 के लिए काम करना चाहिए।

मुख्य विशेषताएं:

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

वास्तविक अनुभव:

मैं काफी लंबे समय से लाइव डेटा पर सर्वर और आर्काइवर का विकास और परीक्षण कर रहा हूं, अब यह एक क्लस्टर पर सफलतापूर्वक काम कर रहा है जिसमें अलग-अलग SATA ड्राइव पर 250,000,000 निर्देशिकाओं में स्थित 15,000,000 छोटी फ़ाइलें (चित्र) शामिल हैं। 10 सर्वरों का एक क्लस्टर एक सीडीएन नेटवर्क के पीछे स्थापित एक ओरिजिन सर्वर है। इसकी सर्विस के लिए 2 Nginx सर्वर + 2 wZD सर्वर का उपयोग किया जाता है।

जो लोग इस सर्वर का उपयोग करने का निर्णय लेते हैं, उनके लिए उपयोग से पहले, यदि लागू हो, निर्देशिका संरचना की योजना बनाना बुद्धिमानी होगी। मैं तुरंत एक आरक्षण कर दूं कि सर्वर का इरादा 1 बोल्ट संग्रह में सब कुछ ठूंसने का नहीं है।

प्रदर्शन का परीक्षण:

ज़िप्ड फ़ाइल का आकार जितना छोटा होगा, उस पर GET और PUT ऑपरेशन उतनी ही तेज़ी से निष्पादित होंगे। आइए HTTP क्लाइंट के लिखने और पढ़ने के कुल समय की तुलना नियमित फ़ाइलों और बोल्ट अभिलेखागार से करें। 32 KB, 256 KB, 1024 KB, 4096 KB और 32768 KB आकार की फ़ाइलों के साथ कार्य की तुलना की जाती है।

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

मैंने SSD ड्राइव पर प्रदर्शन परीक्षण किए, क्योंकि SATA ड्राइव पर परीक्षण में कोई स्पष्ट अंतर नहीं दिखा।

परीक्षण परिणामों पर आधारित ग्राफ़:

जैसा कि आप देख सकते हैं, छोटी फ़ाइलों के लिए संग्रहीत और गैर-संग्रहीत फ़ाइलों के बीच पढ़ने और लिखने के समय में अंतर छोटा है।

32 एमबी आकार की फ़ाइलों को पढ़ने और लिखने का परीक्षण करते समय हमें एक पूरी तरह से अलग तस्वीर मिलती है:

फ़ाइलों को पढ़ने के बीच का समय अंतर 5-25 एमएस के भीतर है। रिकॉर्डिंग के साथ हालात बदतर हैं, अंतर लगभग 150 एमएस है। लेकिन इस मामले में बड़ी फ़ाइलों को अपलोड करने की कोई आवश्यकता नहीं है; ऐसा करने का कोई मतलब नहीं है; वे अभिलेखागार से अलग रह सकते हैं।

*तकनीकी रूप से, आप इस सर्वर का उपयोग NoSQL की आवश्यकता वाले कार्यों के लिए कर सकते हैं।

WZD सर्वर के साथ काम करने की बुनियादी विधियाँ:

एक नियमित फ़ाइल लोड हो रही है:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

किसी फ़ाइल को बोल्ट संग्रह में अपलोड करना (यदि सर्वर पैरामीटर fmaxsize, जो संग्रह में शामिल किए जा सकने वाले अधिकतम फ़ाइल आकार को निर्धारित करता है, को पार नहीं किया जाता है; यदि इसे पार किया जाता है, तो फ़ाइल को संग्रह के बगल में सामान्य रूप से अपलोड किया जाएगा):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

किसी फ़ाइल को डाउनलोड करना (यदि डिस्क पर और संग्रह में समान नाम वाली फ़ाइलें हैं, तो डाउनलोड करते समय, अनारक्षित फ़ाइल को डिफ़ॉल्ट रूप से प्राथमिकता दी जाती है):

curl -o test.jpg http://localhost/test/test.jpg

बोल्ट संग्रह से एक फ़ाइल डाउनलोड करना (मजबूर):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

अन्य विधियों का विवरण दस्तावेज़ में है।

wZD दस्तावेज़ीकरण
wZA दस्तावेज़ीकरण

सर्वर वर्तमान में केवल HTTP प्रोटोकॉल का समर्थन करता है; यह अभी तक HTTPS के साथ काम नहीं करता है। POST पद्धति भी समर्थित नहीं है (यह अभी तक तय नहीं हुआ है कि इसकी आवश्यकता है या नहीं)।

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

करने के लिए:

• क्लस्टर फ़ाइल सिस्टम के बिना बड़े सिस्टम में उपयोग की संभावना के लिए अपने स्वयं के रेप्लिकेटर और वितरक + जियो का विकास (वयस्कों के लिए सब कुछ)
• मेटाडेटा के पूरी तरह से खो जाने पर उसकी पूर्ण रिवर्स पुनर्प्राप्ति की संभावना (यदि वितरक का उपयोग कर रहे हैं)
• विभिन्न प्रोग्रामिंग भाषाओं के लिए लगातार नेटवर्क कनेक्शन और ड्राइवरों का उपयोग करने की क्षमता के लिए मूल प्रोटोकॉल
• NoSQL घटक का उपयोग करने के लिए उन्नत संभावनाएँ
• बोल्ट अभिलेखागार के अंदर फ़ाइलों या मानों के लिए और नियमित फ़ाइलों के लिए विभिन्न प्रकार (gzip, zstd, snappy) के संपीड़न
• बोल्ट अभिलेखागार के अंदर फ़ाइलों या मानों के लिए और नियमित फ़ाइलों के लिए विभिन्न प्रकार का एन्क्रिप्शन
• GPU सहित सर्वर-साइड वीडियो रूपांतरण में देरी

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

स्रोत: www.habr.com