ეფექტურად შეინახეთ ასობით მილიონი პატარა ფაილი. თვითმმართველობის ჰოსტირებული გადაწყვეტა

ძვირფასო საზოგადოებავ, ეს სტატია ყურადღებას გაამახვილებს ასობით მილიონი პატარა ფაილის ეფექტურად შენახვასა და აღდგენაზე. ამ ეტაპზე, საბოლოო გადაწყვეტა შემოთავაზებულია POSIX-თან თავსებადი ფაილური სისტემებისთვის საკეტების სრული მხარდაჭერით, კლასტერული ბლოკირების ჩათვლით და, როგორც ჩანს, ხელჯოხების გარეშეც კი.

ასე რომ, მე დავწერე ჩემი საკუთარი სერვერი ამ მიზნით.
ამ ამოცანის განხორციელების პროცესში ჩვენ მოვახერხეთ მთავარი პრობლემის გადაჭრა და ამავდროულად მივაღწიეთ დაზოგვას დისკზე და RAM-ში, რომელსაც ჩვენი კლასტერული ფაილური სისტემა უმოწყალოდ მოიხმარდა. სინამდვილეში, ფაილების ასეთი რაოდენობა საზიანოა ნებისმიერი კლასტერული ფაილური სისტემისთვის.

იდეა ასეთია:

მარტივი სიტყვებით, სერვერის საშუალებით იტვირთება პატარა ფაილები, ინახება პირდაპირ არქივში და ასევე იკითხება მისგან და დიდი ფაილები თავსდება გვერდიგვერდ. სქემა: 1 საქაღალდე = 1 არქივი, ჯამში გვაქვს რამდენიმე მილიონი არქივი პატარა ფაილებით და არა რამდენიმე ასეული მილიონი ფაილი. და ეს ყველაფერი ხორციელდება სრულად, ყოველგვარი სკრიპტის ან ფაილების tar/zip არქივებში ჩასმის გარეშე.

ვეცდები მოკლედ დავწერო, წინასწარ ბოდიშს გიხდით თუ პოსტი გრძელია.

ეს ყველაფერი დაიწყო იმით, რომ მე ვერ ვიპოვე მსოფლიოში შესაფერისი სერვერი, რომელსაც შეეძლო HTTP პროტოკოლით მიღებული მონაცემების შენახვა პირდაპირ არქივებში, ჩვეულებრივი არქივებისა და ობიექტების შენახვის მინუსების გარეშე. ძიების მიზეზი კი იყო 10 სერვერისგან შემდგარი Origin კლასტერი, რომელიც ფართო მასშტაბით გაიზარდა, რომელშიც უკვე დაგროვდა 250,000,000 XNUMX XNUMX პატარა ფაილი და ზრდის ტენდენცია შეჩერებას არ აპირებდა.

მათთვის, ვისაც არ უყვარს სტატიების კითხვა, მცირე დოკუმენტაცია უფრო ადვილია:

აქ и აქ.

და დოკერი ამავე დროს, ახლა არის ვარიანტი მხოლოდ 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 კბ. ანუ 3, 10 ან 30 კბ ზომის ფაილებისთვის საჭიროა დისკზე 64 კბ. თუ არსებობს მეოთხედი მილიარდი ფაილი, ჩვენ ვკარგავთ 2-დან 10 ტერაბაიტამდე. შეუძლებელი იქნება ახალი ფაილების შექმნა განუსაზღვრელი ვადით, რადგან MooseFS-ს აქვს შეზღუდვა: არაუმეტეს 1 მილიარდი თითოეული ფაილის ერთი ასლით.

როგორც ფაილების რაოდენობა იზრდება, მეტამონაცემებისთვის საჭიროა ბევრი ოპერატიული მეხსიერება. ხშირი დიდი მეტამონაცემების გადაყრა ასევე ხელს უწყობს SSD დისკების ცვეთას.

wZD სერვერი. დისკებზე მოვაწესრიგებთ ნივთებს.

სერვერი Go-შია დაწერილი. პირველ რიგში, მჭირდებოდა ფაილების რაოდენობის შემცირება. Როგორ გავაკეთო ეს? დაარქივების გამო, მაგრამ ამ შემთხვევაში შეკუმშვის გარეშე, რადგან ჩემი ფაილები უბრალოდ შეკუმშული სურათებია. სამაშველოში მოვიდა BoltDB, რომელიც ჯერ კიდევ უნდა აღმოიფხვრას მისი ნაკლოვანებები, ეს ასახულია დოკუმენტაციაში.

მთლიანობაში, მეოთხედი მილიარდი ფაილის ნაცვლად, ჩემს შემთხვევაში დარჩა მხოლოდ 10 მილიონი Bolt-ის არქივი. მე რომ მქონოდა შესაძლებლობა შეცვალოს არსებული დირექტორია ფაილის სტრუქტურა, შესაძლებელი იქნებოდა მისი შემცირება დაახლოებით 1 მილიონ ფაილამდე.

ყველა პატარა ფაილი შეფუთულია Bolt-ის არქივებში, რომლებიც ავტომატურად იღებენ იმ დირექტორიების სახელებს, რომლებშიც ისინი მდებარეობს და ყველა დიდი ფაილი რჩება არქივების გვერდით; აზრი არ აქვს მათ შეფუთვას, ეს არის კონფიგურირებადი. პატარები არქივდება, დიდი უცვლელი რჩება. სერვერი ორივესთან გამჭვირვალედ მუშაობს.

wZD სერვერის არქიტექტურა და მახასიათებლები.

სერვერი მუშაობს Linux, BSD, Solaris და OSX ოპერაციული სისტემებით. მე მხოლოდ AMD64 არქიტექტურისთვის გამოვცადე Linux-ზე, მაგრამ ის უნდა მუშაობდეს ARM64, PPC64, MIPS64-ზე.

Ძირითადი მახასიათებლები:

• Multithreading;
• მულტისერვერი, რომელიც უზრუნველყოფს ხარვეზების ტოლერანტობას და დატვირთვის დაბალანსებას;
• მაქსიმალური გამჭვირვალობა მომხმარებლის ან დეველოპერისთვის;
• მხარდაჭერილი HTTP მეთოდები: GET, HEAD, PUT და DELETE;
• კითხვისა და ჩაწერის ქცევის მართვა კლიენტის მხარის სათაურების მეშვეობით;
• მაღალკონფიგურირებადი ვირტუალური ჰოსტების მხარდაჭერა;
• CRC მონაცემთა მთლიანობის მხარდაჭერა წერის/კითხვისას;
• ნახევრად დინამიური ბუფერები მეხსიერების მინიმალური მოხმარებისთვის და ქსელის მუშაობის ოპტიმალური რეგულირებისთვის;
• მონაცემთა გადადებული შეკუმშვა;
• გარდა ამისა, მრავალნაკადიანი არქივატორი wZA შემოთავაზებულია ფაილების მიგრაციისთვის სერვისის შეწყვეტის გარეშე.

რეალური გამოცდილება:

მე საკმაოდ დიდი ხანია ვავითარებ და ვამოწმებ სერვერსა და არქივერს ცოცხალ მონაცემებზე, ახლა ის წარმატებით მუშაობს კლასტერზე, რომელიც მოიცავს 250,000,000 15,000,000 10 პატარა ფაილს (სურათებს), რომლებიც მდებარეობს 2 2 XNUMX დირექტორიაში ცალკე SATA დისკებზე. XNUMX სერვერის კლასტერი არის Origin სერვერი, რომელიც დამონტაჟებულია CDN ქსელის უკან. მისი მომსახურებისთვის გამოიყენება XNUMX Nginx სერვერი + XNUMX wZD სერვერი.

მათთვის, ვინც გადაწყვეტს ამ სერვერის გამოყენებას, გონივრული იქნება, გამოყენებამდე დაიგეგმოს დირექტორია სტრუქტურა, თუ ეს შესაძლებელია. ნება მომეცით დაუყოვნებლივ გავაკეთო დაჯავშნა, რომ სერვერი არ არის გამიზნული ყველაფრის 1 Bolt-ის არქივში ჩაყრა.

შესრულების ტესტირება:

რაც უფრო მცირეა zipped ფაილის ზომა, მით უფრო სწრაფია მასზე GET და PUT ოპერაციები. მოდით შევადაროთ HTTP კლიენტის ჩაწერის საერთო დრო ჩვეულებრივ ფაილებთან და Bolt-ის არქივებთან, ისევე როგორც კითხვასთან. შედარებულია 32 KB, 256 KB, 1024 KB, 4096 KB და 32768 KB ზომის ფაილებთან მუშაობა.

Bolt-ის არქივებთან მუშაობისას მოწმდება თითოეული ფაილის მონაცემთა მთლიანობა (გამოიყენება CRC), ჩაწერამდე და ასევე ჩაწერის შემდეგ ხდება ფრენის წაკითხვა და ხელახალი გამოთვლა, ეს ბუნებრივად იწვევს შეფერხებებს, მაგრამ მთავარია მონაცემთა უსაფრთხოება.

მე ჩავატარე შესრულების ტესტები SSD დისკებზე, რადგან SATA დისკებზე ტესტები არ აჩვენებს აშკარა განსხვავებას.

გრაფიკები ტესტირების შედეგებზე დაყრდნობით:

როგორც ხედავთ, მცირე ფაილებისთვის წაკითხვისა და ჩაწერის დროში განსხვავება არქივებულ და არქივირებულ ფაილებს შორის მცირეა.

სრულიად განსხვავებულ სურათს ვიღებთ 32 მბ ზომის ფაილების წაკითხვისა და ჩაწერისას:

ფაილების წაკითხვას შორის დროის სხვაობა 5-25 ms ფარგლებშია. ჩაწერით, ყველაფერი უარესია, განსხვავება არის დაახლოებით 150 ms. მაგრამ ამ შემთხვევაში არ არის საჭირო დიდი ფაილების ატვირთვა; უბრალოდ აზრი არ აქვს ამის გაკეთებას; მათ შეუძლიათ იცხოვრონ არქივიდან დამოუკიდებლად.

*ტექნიკურად, შეგიძლიათ გამოიყენოთ ეს სერვერი ამოცანების შესასრულებლად, რომლებიც საჭიროებენ NoSQL-ს.

wZD სერვერთან მუშაობის ძირითადი მეთოდები:

რეგულარული ფაილის ჩატვირთვა:

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

ფაილის ატვირთვა Bolt-ის არქივში (თუ სერვერის პარამეტრი 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

ფაილის ჩამოტვირთვა Bolt-ის არქივიდან (იძულებითი):

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

სხვა მეთოდების აღწერა მოცემულია დოკუმენტაციაში.

wZD დოკუმენტაცია
wZA დოკუმენტაცია

სერვერი ამჟამად მხარს უჭერს მხოლოდ HTTP პროტოკოლს; ის ჯერ არ მუშაობს HTTPS-თან. POST მეთოდი ასევე არ არის მხარდაჭერილი (ჯერ არ არის გადაწყვეტილი, საჭიროა თუ არა).

ვინც იჭრება წყაროს კოდში, იქ იპოვის კარაქს, ყველას არ მოსწონს, მაგრამ მე არ მივაბარე მთავარი კოდი ვებ ჩარჩოს ფუნქციებს, გარდა შეფერხების დამმუშავებლისა, ასე რომ, მომავალში შემიძლია სწრაფად გადავწერო იგი თითქმის ნებისმიერისთვის. ძრავა.

Კეთება:

• თქვენი საკუთარი რეპლიკატორისა და დისტრიბუტორის შემუშავება + გეოგრაფიის გამოყენების შესაძლებლობისთვის დიდ სისტემებში კლასტერული ფაილური სისტემების გარეშე (ყველაფერი მოზრდილებისთვის)
• მეტამონაცემების სრული საპირისპირო აღდგენის შესაძლებლობა, თუ ის მთლიანად დაიკარგება (დისტრიბუტორის გამოყენების შემთხვევაში)
• მშობლიური პროტოკოლი მუდმივი ქსელური კავშირებისა და დრაივერების გამოყენების შესაძლებლობისთვის სხვადასხვა პროგრამირების ენებისთვის
• NoSQL კომპონენტის გამოყენების გაფართოებული შესაძლებლობები
• სხვადასხვა ტიპის შეკუმშვა (gzip, zstd, snappy) ფაილებისთვის ან მნიშვნელობებისთვის Bolt-ის არქივებში და ჩვეულებრივი ფაილებისთვის
• სხვადასხვა ტიპის დაშიფვრა ფაილებისთვის ან მნიშვნელობებისთვის Bolt-ის არქივებში და ჩვეულებრივი ფაილებისთვის
• დაგვიანებული სერვერის მხრიდან ვიდეო კონვერტაცია, მათ შორის GPU-ზე

ყველაფერი მაქვს, იმედია ვინმეს გამოადგება ეს სერვერი, BSD-3 ლიცენზია, ორმაგი საავტორო უფლება, რადგან არ ყოფილიყო კომპანია სადაც ვმუშაობ, სერვერი არ დაიწერებოდა. მე ვარ ერთადერთი დეველოპერი. მადლობელი ვიქნები ნებისმიერი შეცდომისა და ფუნქციის მოთხოვნისთვის, რომელსაც აღმოაჩენთ.

წყარო: www.habr.com