लाखो लहान फायली कार्यक्षमतेने संचयित करा. स्वयं-होस्ट केलेले समाधान

प्रिय समुदाय, हा लेख लाखो लहान फायली कार्यक्षमतेने संचयित आणि पुनर्प्राप्त करण्यावर लक्ष केंद्रित करेल. या टप्प्यावर, POSIX-सुसंगत फाइल सिस्टीमसाठी अंतिम उपाय प्रस्तावित आहे, ज्यामध्ये क्लस्टर लॉकचा समावेश आहे आणि अगदी क्रॅचशिवाय देखील लॉकसाठी पूर्ण समर्थन आहे.

म्हणून मी या उद्देशासाठी माझा स्वतःचा सानुकूल सर्व्हर लिहिला.
हे कार्य अंमलात आणताना, आम्ही मुख्य समस्येचे निराकरण करण्यात व्यवस्थापित केले आणि त्याच वेळी डिस्क स्पेस आणि RAM मध्ये बचत केली, जी आमच्या क्लस्टर फाइल सिस्टमने निर्दयीपणे वापरली होती. वास्तविक, अशा अनेक फाइल्स कोणत्याही क्लस्टर केलेल्या फाइल सिस्टमसाठी हानिकारक असतात.

कल्पना अशी आहे:

सोप्या शब्दात सांगायचे तर, लहान फाइल्स सर्व्हरद्वारे अपलोड केल्या जातात, त्या थेट संग्रहणात जतन केल्या जातात आणि त्यातून वाचल्या जातात आणि मोठ्या फाइल्स शेजारी ठेवल्या जातात. योजना: 1 फोल्डर = 1 संग्रहण, एकूण आमच्याकडे लहान फायलींसह अनेक दशलक्ष संग्रहण आहेत, आणि काही शंभर दशलक्ष फायली नाहीत. आणि हे सर्व कोणत्याही स्क्रिप्टशिवाय किंवा फाईल टार/झिप आर्काइव्हमध्ये न टाकता पूर्णपणे अंमलात आणले जाते.

मी ते लहान ठेवण्याचा प्रयत्न करेन, पोस्ट लांब असल्यास मी आगाऊ माफी मागतो.

हे सर्व या वस्तुस्थितीपासून सुरू झाले की मला जगात एक योग्य सर्व्हर सापडला नाही जो एचटीटीपी प्रोटोकॉलद्वारे प्राप्त केलेला डेटा थेट आर्काइव्हमध्ये जतन करू शकेल, परंपरागत संग्रहण आणि ऑब्जेक्ट स्टोरेजमध्ये अंतर्भूत असलेल्या तोटेशिवाय. आणि शोधाचे कारण 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 मध्ये लिहिलेले आहे. सर्व प्रथम, मला फाइल्सची संख्या कमी करणे आवश्यक आहे. ते कसे करायचे? संग्रहणामुळे, परंतु या प्रकरणात संक्षेप न करता, माझ्या फायली फक्त संकुचित चित्रे आहेत. बोल्टडीबी बचावासाठी आला, ज्याला अद्याप त्याच्या कमतरता दूर कराव्या लागल्या, हे दस्तऐवजीकरणात दिसून येते.

एकूण, एक अब्ज फायलींच्या एक चतुर्थांश ऐवजी, माझ्या बाबतीत फक्त 10 दशलक्ष बोल्ट संग्रहण शिल्लक होते. जर मला वर्तमान निर्देशिका फाइल संरचना बदलण्याची संधी मिळाली, तर ती अंदाजे 1 दशलक्ष फाइल्सपर्यंत कमी करणे शक्य होईल.

सर्व लहान फायली बोल्ट आर्काइव्हमध्ये पॅक केल्या जातात, ज्यामध्ये ते ज्या डिरेक्टरीमध्ये आहेत त्यांची नावे आपोआप प्राप्त होतात आणि सर्व मोठ्या फायली संग्रहांच्या पुढे राहतात; त्यांना पॅक करण्यात काही अर्थ नाही, हे सानुकूल करण्यायोग्य आहे. लहान संग्रहित केले आहेत, मोठे अपरिवर्तित सोडले आहेत. सर्व्हर दोन्हीसह पारदर्शकपणे कार्य करतो.

आर्किटेक्चर आणि wZD सर्व्हरची वैशिष्ट्ये.

सर्व्हर लिनक्स, बीएसडी, सोलारिस आणि ओएसएक्स ऑपरेटिंग सिस्टीम अंतर्गत कार्यरत आहे. मी फक्त लिनक्स अंतर्गत AMD64 आर्किटेक्चरसाठी चाचणी केली आहे, परंतु ते ARM64, PPC64, MIPS64 साठी कार्य करेल.

मुख्य वैशिष्ट्ये:

• मल्टीथ्रेडिंग;
• मल्टीसर्व्हर, फॉल्ट टॉलरन्स आणि लोड बॅलेंसिंग प्रदान करते;
• वापरकर्ता किंवा विकसकासाठी कमाल पारदर्शकता;
• समर्थित HTTP पद्धती: GET, HEAD, PUT आणि DELETE;
• क्लायंट शीर्षलेखांद्वारे वाचन आणि लेखन वर्तनावर नियंत्रण;
• लवचिक आभासी होस्टसाठी समर्थन;
• लेखन/वाचन करताना CRC डेटा अखंडतेचे समर्थन करा;
• किमान मेमरी वापर आणि इष्टतम नेटवर्क कार्यप्रदर्शन ट्यूनिंगसाठी अर्ध-गतिशील बफर;
• स्थगित डेटा कॉम्पॅक्शन;
• याव्यतिरिक्त, सेवा न थांबवता फायली स्थलांतरित करण्यासाठी मल्टी-थ्रेडेड आर्काइव्हर wZA ऑफर केले जाते.

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

मी बऱ्याच काळापासून लाइव्ह डेटावर सर्व्हर आणि आर्काइव्हर विकसित आणि चाचणी करत आहे, आता ते एका क्लस्टरवर यशस्वीरित्या कार्य करत आहे ज्यात 250,000,000 लहान फाईल्स (चित्रे) आहेत ज्यात स्वतंत्र SATA ड्राइव्हवर 15,000,000 निर्देशिकांमध्ये स्थित आहे. 10 सर्व्हरचा क्लस्टर हा CDN नेटवर्कच्या मागे स्थापित केलेला मूळ सर्व्हर आहे. त्याची सेवा करण्यासाठी, 2 Nginx सर्व्हर + 2 wZD सर्व्हर वापरले जातात.

जे हा सर्व्हर वापरण्याचा निर्णय घेतात त्यांच्यासाठी, वापरण्यापूर्वी, लागू असल्यास, निर्देशिका संरचना तयार करणे शहाणपणाचे ठरेल. मी लगेच आरक्षण करतो की सर्व्हरचा हेतू 1 बोल्ट आर्काइव्हमध्ये सर्वकाही क्रॅम करण्याचा नाही.

कामगिरी चाचणी:

झिप केलेल्या फाईलचा आकार जितका लहान असेल तितक्या वेगवान GET आणि PUT ऑपरेशन्स त्यावर केल्या जातात. एचटीटीपी क्लायंट लिहिण्याच्या एकूण वेळेची नियमित फाइल्स आणि बोल्ट आर्काइव्ह, तसेच वाचन यांच्याशी तुलना करूया. 32 KB, 256 KB, 1024 KB, 4096 KB आणि 32768 KB आकारांच्या फायलींसह कामाची तुलना केली जाते.

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

मी 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, स्नॅपी) कॉम्प्रेशन
• बोल्ट आर्काइव्हजमधील फाइल्स किंवा व्हॅल्यूजसाठी आणि नियमित फाइल्ससाठी विविध प्रकारचे एनक्रिप्शन
• विलंबित सर्व्हर-साइड व्हिडिओ रूपांतरण, जीपीयूसह

माझ्याकडे सर्व काही आहे, मला आशा आहे की हा सर्व्हर एखाद्यासाठी उपयुक्त ठरेल, बीएसडी -3 परवाना, दुहेरी कॉपीराइट, कारण मी जिथे काम करतो तिथे कोणतीही कंपनी नसती तर सर्व्हर लिहिला गेला नसता. मी एकमेव विकासक आहे. तुम्हाला आढळलेल्या कोणत्याही बग आणि वैशिष्ट्यांच्या विनंत्यांसाठी मी कृतज्ञ आहे.

स्त्रोत: www.habr.com