लाखौं साना फाइलहरू कुशलतापूर्वक भण्डारण गर्नुहोस्। स्व-होस्ट गरिएको समाधान

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

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

विचार यो हो:

सरल शब्दहरूमा, साना फाइलहरू सर्भर मार्फत अपलोड हुन्छन्, तिनीहरू सिधै अभिलेखमा सुरक्षित हुन्छन्, र त्यसबाट पढ्छन्, र ठूला फाइलहरू छेउछाउमा राखिन्छन्। योजना: 1 फोल्डर = 1 अभिलेख, कुलमा हामीसँग साना फाइलहरूसँग धेरै मिलियन अभिलेखहरू छन्, र धेरै लाख फाइलहरू छैनन्। र यो सबै कुनै पनि स्क्रिप्ट बिना वा tar/zip अभिलेखहरूमा फाइलहरू राख्ने बिना, पूर्ण रूपमा लागू गरिएको छ।

म यसलाई छोटो राख्न प्रयास गर्नेछु, यदि पोस्ट लामो भएमा म अग्रिम माफी चाहन्छु।

यो सबै तथ्यको साथ सुरु भयो कि मैले संसारमा उपयुक्त सर्भर फेला पार्न सकेन जसले 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 ड्राइभको हार र आँसुमा योगदान गर्दछ।

wZD सर्भर। हामीले डिस्कहरूमा चीजहरू क्रमबद्ध राख्छौं।

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

कुलमा, एक अर्ब फाइलहरूको एक चौथाईको सट्टा, मेरो मामलामा त्यहाँ केवल 10 मिलियन बोल्ट अभिलेखहरू बाँकी थिए। यदि मसँग हालको डाइरेक्टरी फाइल संरचना परिवर्तन गर्ने अवसर थियो भने, यसलाई लगभग 1 मिलियन फाइलहरूमा घटाउन सम्भव हुनेछ।

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

wZD सर्भरको वास्तुकला र सुविधाहरू।

सर्भरले लिनक्स, बीएसडी, सोलारिस र ओएसएक्स अपरेटिङ सिस्टम अन्तर्गत काम गर्छ। मैले लिनक्स अन्तर्गत AMD64 आर्किटेक्चरको लागि मात्र परीक्षण गरें, तर यसले ARM64, PPC64, MIPS64 का लागि काम गर्नुपर्छ।

मुख्य विशेषताहरु:

• मल्टिथ्रेडिङ;
• मल्टिसर्भर, दोष सहिष्णुता र लोड सन्तुलन प्रदान गर्दै;
• प्रयोगकर्ता वा विकासकर्ताको लागि अधिकतम पारदर्शिता;
• समर्थित HTTP विधिहरू: GET, HEAD, PUT र DELETE;
• क्लाइन्ट हेडरहरू मार्फत पढ्ने र लेख्ने व्यवहारको नियन्त्रण;
• लचिलो भर्चुअल होस्टहरूको लागि समर्थन;
• लेख्ने/पढ्दा CRC डाटा अखण्डतालाई समर्थन गर्नुहोस्;
• न्यूनतम मेमोरी खपत र इष्टतम नेटवर्क प्रदर्शन ट्युनिङको लागि अर्ध-गतिशील बफरहरू;
• स्थगित डाटा कम्पेक्शन;
• थप रूपमा, सेवा रोक्ने बिना फाइलहरू माइग्रेट गर्नको लागि बहु-थ्रेडेड आर्काइभर wZA प्रस्ताव गरिएको छ।

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

मैले धेरै लामो समयदेखि लाइभ डाटामा सर्भर र आर्काइभरको विकास र परीक्षण गरिरहेको छु, अब यो सफलतापूर्वक क्लस्टरमा सञ्चालन भइरहेको छ जसमा 250,000,000 साना फाइलहरू (तस्बिरहरू) 15,000,000 डाइरेक्टरीहरूमा छुट्टै SATA ड्राइभहरूमा अवस्थित छन्। 10 सर्भरहरूको क्लस्टर एउटा मूल सर्भर हो जुन CDN नेटवर्क पछाडि स्थापित हुन्छ। यसलाई सेवा गर्न, 2 Nginx सर्भर + 2 wZD सर्भरहरू प्रयोग गरिन्छ।

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

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

जिप गरिएको फाइलको साइज जति सानो हुन्छ, त्यति नै छिटो GET र PUT कार्यहरू यसमा गरिन्छ। HTTP क्लाइन्ट लेखनको लागि नियमित फाइलहरू र बोल्ट अभिलेखहरू, साथै पढ्नको लागि कुल समय तुलना गरौं। 32 KB, 256 KB, 1024 KB, 4096 KB र 32768 KB आकारका फाइलहरूसँग काम तुलना गरिएको छ।

बोल्ट अभिलेखहरूसँग काम गर्दा, प्रत्येक फाइलको डाटा अखण्डता जाँच गरिन्छ (CRC प्रयोग गरिन्छ), रेकर्डिङ अघि र रेकर्डिङ पछि, अन-द-फ्लाइ पढ्ने र पुन: गणना हुन्छ, यसले स्वाभाविक रूपमा ढिलाइ परिचय गराउँछ, तर मुख्य कुरा डाटा सुरक्षा हो।

मैले SSD ड्राइभहरूमा प्रदर्शन परीक्षणहरू सञ्चालन गरें, किनकि SATA ड्राइभहरूमा परीक्षणहरूले स्पष्ट भिन्नता देखाउँदैन।

परीक्षण परिणामहरूमा आधारित ग्राफहरू:

तपाईंले देख्न सक्नुहुने रूपमा, साना फाइलहरूको लागि संग्रहित र गैर-संग्रहित फाइलहरू बीचको पढ्न र लेख्ने समयको भिन्नता सानो छ।

32 MB साइजको फाइलहरू पढ्ने र लेख्ने परीक्षण गर्दा हामीले पूर्ण रूपमा फरक तस्वीर पाउँछौं:

पढ्ने फाइलहरू बीचको समय भिन्नता 5-25 ms भित्र छ। रेकर्डिङको साथ, चीजहरू खराब छन्, भिन्नता लगभग 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 मा लगायत सर्भर-साइड भिडियो रूपान्तरणमा ढिलाइ भयो

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

स्रोत: www.habr.com