Ruajtja efikase e qindra milionëve të vegjël skedarëve. Zgjidhje Self-Hosted

Të nderuar anëtarë të komunitetit, ky artikull do të trajtojë ruajtjen dhe shpërndarjen efektive të qindra milionë skedarëve të vegjël. Në këtë fazë, po ofrohet një zgjidhje e plotë për sistemet e skedarëve të përputhshme me POSIX, duke ofruar mbështetje të plotë për bllokimet, përfshirë ato në klaster dhe madje duket se pa ndihma të jashtme.

Prandaj, për këtë qëllim, shkrova serverin tim të specializuar.
Gjatë realizimit të kësaj detyre, arrita të zgjidh problemin kryesor dhe njëkohësisht të arrij kursim në hapësirën e diskut dhe memorjen operative, të cilën e konsumonte pa mëshirë sistemi ynë i skedarëve në klaster. Një sasi e tillë skedarësh është e dëmshme për çdo sistem skedari në klaster.

Ideja është kjo:

Me fjalë të thjeshta, skedarët e vegjël ngarkohen përmes serverit, ato ruhet drejtpërdrejt në arkiv, dhe ashtu lexohen nga ai, ndërsa skedarët e mëdhenj vendosen përkrah. Skema: 1 dosje = 1 arkiv, që do të thotë kemi disa milionë arkivash me skedarë të vegjël, e jo disa qindra milionë skedarë. Dhe të gjitha këto janë realizuar në mënyrë të plotë, pa skripte dhe shpërndarje skedarësh në arkivat tar/zip.

Do të përpiqem ta shpreh shkurt, paraprakisht kërkoj falje nëse posti do të jetë i ngjeshur.

Filloi gjithçka nga fakti se nuk mund të gjeja një server të përshtatshëm në botë, i cili mund të ruante të dhënat e marra përmes protokollit HTTP drejtpërdrejt në arkiva, në mënyrë që të mos kishte mangësi që i përkasin arkivave të zakonshëm dhe ruajtjeve të objekteve. Arsyeja për kërkim ishte klasteri Origin, që ishte zgjeruar në përmasa të mëdha me 10 serverë, ku kishin u përmbledhur tashmë 250,000,000 skedarë të vegjël dhe tendenca e rritjes nuk kishte ndërmend të ndalonte.

Për ata që nuk i pëlqejnë artikujt dhe dokumentacioni i vogël është më i lehtë:

. Kërkesat e dërguara përmes mënyrave të tjera nuk do të shqyrtohen. dhe . Kërkesat e dërguara përmes mënyrave të tjera nuk do të shqyrtohen..

Dhe docker gjithashtu, tani ekziston një variant vetëm së bashku me nginx brenda për çdo rast:

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

Tjetër:

Nëse ka shumë skedarë, kërkohen resurse të konsiderueshme dhe, çka është më e shkurajshme, një pjesë e tyre humbet kot. Për shembull, kur përdoret një sistem skedarësh klasterik (në këtë rast – MooseFS), një skedar, pavarësisht nga madhësia e tij reale, gjithmonë zë së paku 64 KB. Kështu, për skedarë me madhësi 3, 10 ose 30 KB në disk, kërkohen nga 64 KB. Nëse ka një çerek billion skedarë, ne humbasim nga 2 deri në 10 tera byte. Të krijosh skedarë të rinj deri në pafundësi nuk do të jetë e mundur, sepse në atë MooseFS ekziston një kufizim: jo më shumë se 1 miliard me një replikim të çdo skedari.

Me rritjen e numrit të skedarëve, nevojitet shumë memorie operative për metadatat. Gjithashtu, dump-et e mëdha të metadatanave të shpeshta kontribuojnë në konsumimin e SSD-ve.

Serveri wZD. Po i japim rend rutinës në disqe.

Serveri është shkruar në gjuhën Go. Para të gjithash, më duhej të reduktonja numrin e skedarëve. Si ta bëj këtë? Nëpërmjet arkivimit, por në këtë rast pa kompresim, sepse skedarët e mi janë imazhe të shtrënguara. Më ndihmoi BoltDB, të cilin gjithashtu e eliminova nga disavantazhet, gjë që është reflektuar në dokumentacion.

Nga një çerek miliard dosjesh, në rastin tim mbetën vetëm 10 milion Arkiva Bolt. Po të kisha mundësinë të ndryshoja strukturën aktuale të mbushjes me dosje, ndoshta do të kishte mundësi ta ulja numrin deri në 1 milion dosje.

Të gjitha dosjet e vogla paketohen në Arkiva Bolt, automatikisht marrin emrat e dosjeve ku ndodhen, ndërsa të gjitha dosjet e mëdha qëndrojnë pranë arkivave; nuk ka kuptim t'i paketosh ato, dhe kjo është e konfigurueshme. Të voglat - i arkivojmë, të mëdhatë - i lëmë pa ndryshime. Serveri funksionon në mënyrë transparente për të dyja.

Arkitektura dhe karakteristikat e serverit wZD.

Serveri funksionon nën menaxhimin e sistemeve operative Linux, BSD, Solaris dhe OSX. Kam testuar vetëm për arkitekturën AMD64 nën Linux, por duhet të jetë i përshtatshëm edhe për ARM64, PPC64, MIPS64.

Karakteristikat kryesore:

• Multithreading;
• Multiserver, që siguron qëndrueshmëri dhe balancim të ngarkesës;
• Transparencë maksimale për përdoruesin ose zhvilluesin;
• Metodat HTTP të mbështetura: GET, HEAD, PUT dhe DELETE;
• Menaxhimi i sjelljes gjatë leximit dhe shk writing. më anë të titujve të klientëve;
• Mbështetje për hoste virtuale të konfiguruar në mënyrë fleksibile;
• Mbështetje për CRC për integritetin e të dhënave gjatë shkrimit/leximit;
• Bufra poludinamike për konsum minimal të memories dhe optimizimin e performancës të rrjeteve;
• Kompaktimi i vonuar i të dhënave;
• Përveç kësaj, ofrohet një arkivues me disa thread-e wZA për migrimin e skedarëve pa ndalur shërbimin.

Eksperianca reale:

Unë kam zhvilluar dhe testuar serverin dhe arkivuesin me të dhëna në kohë reale për një kohë të gjatë, tani ai funksionon me sukses në një klaster që përfshin 250,000,000 skedare të vogla (imazhe), të vendosura në 15,000,000 direktoriume në disqe SATA të ndara. Klasteri me 10 servera përbën një server Origin, i instaluar prapa një rrjeti CDN. Për shërbimin e tij përdoren 2 servera Nginx + 2 servera wZD.

Atij që do të vendosë të përdorë këtë server, ka kuptim të planifikojë strukturën e direktorive para përdorimit, nëse është e aplikueshme. Të them të drejtën, serveri nuk është menduar për të ngjeshur gjithçka në një arkiv Bolt.

Testimi i performancës:

Sa më i vogël është madhësia e skedarit të arkivuar, aq më shpejt kryhen operacionet GET dhe PUT me të. Le të krahasojmë kohën e përgjithshme të shkruar nga klienti HTTP në skedarët e zakonshëm dhe në arkivat Bolt, po ashtu edhe leximin. Krahasoni punën me skedarë me madhësi 32 KB, 256 KB, 1024 KB, 4096 KB dhe 32768 KB.

Kur punojmë me arkivat Bolt, kontrollohet integriteti i të dhënave të çdo skedari (përdoret CRC), para shkruajtjes dhe pas shkruajtjes ndodh leximi në flukso dhe ri-kalkulimi, natyrisht kjo sjell vonesa, por e rëndësishme është siguria e të dhënave.

Testet e performancës i kam kryer në SSD, pasi në diskun SATA testet nuk tregojnë ndonjë ndryshim të qartë.

Grafikët sipas rezultateve të testimit:

Siç duket, për skedarët e vegjël ndryshimi në kohën e leximit dhe shkruajtjes mes skedarëve të arkivuar dhe atyre jo të arkivuar është i vogël.

Një pamje krejt tjetër do të kemi në testin e leximit dhe shkruajtjes së skedarëve me madhësi 32 MB:

Diferenca në kohën midis leximit të skedarëve është në përmasa 5-25 ms. Me shkruar duan gjërat më keq, diferenca arrin rreth 150 ms. Por në këtë rast, nuk ka nevojë për ngarkimin e skedarëve të mëdhenj, në të vërtetë nuk ka asnjë kuptim, ata mund të jetojnë veç e veç nga arkivat.

*Teknikisht, ky server mund të përdoret edhe për detyra që kërkojnë NoSQL.

Metodat kryesore të punës me serverin wZD:

Ngarkimi i një skedari të zakonshëm:

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

Ngarkimi i një skedari në arkivën Bolt (nëse nuk kalon parametrin e serverit fmaxsize, që përcakton madhësinë maksimale të skedarit që mund të përfshihet në arkiv, nëse kalon, skedari do të ngarkohet si zakonisht përkrah arkivës):

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

Shkarkimi i skedarit (nëse në disk dhe në arkiv ka skedarë me emra të njëjtë, prioriteti në shkarkim jepet normalisht skedarit të paarkivuar):

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

Shkarkimi i skedarit nga arkiva Bolt (me forcë):

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

Përshkrimi i metodave të tjera është në dokumentacion.

Dokumentacioni wZD
Dokumentacioni wZA

Serveri deri tani mbështet vetëm protokollin HTTP, HTTPS nuk funksionon ende. Gjithashtu, metoda POST nuk mbështetet (ende nuk është vendosur nëse është e nevojshme apo jo).

Kush gjen përmbajtjen në kodin burimor, do të zbulojë një iris, nuk e duan të gjithë, por unë nuk e kam lidhur kodin kryesor me funksionet e kornizës së uebit, përveç përpunuesit të ndërprerjeve, kështu që më pas mund ta rishkruaj shpejt në çdo motor.

ToDo:

• Zhvillimi i një replikatori dhe distribuitori të vetë për mundësinë e përdorimit në sisteme të mëdha pa sistemet të klasterit (E gjithë gjëja me seriozitet)
• Mundësia e rikuperimit të plotë të metadatas në rast të humbjes së plotë (nëse përdoret distribuitori)
• Protokoll natyror për mundësinë e përdorimit të lidhjeve të përhershme rrjetore dhe shoferëve për gjuhë të ndryshme programimi
• Mundësi të zgjeruara për përdorimin e komponentit NoSQL
• Kompresimi i llojeve të ndryshme (gzip, zstd, snappy) për skedarë ose vlera brenda arkivave Bolt dhe për skedarë të zakonshëm
• Kriptimi i llojeve të ndryshme për skedarë ose vlera brenda arkivave Bolt dhe për skedarë të zakonshëm
• Konvertimi i videos server-side me vonesë, përfshirë edhe në GPU

Kjo është gjithçka, shpresoj që ky server t'i shërbejë dikujt, licenca BSD-3, e drejta e autorit është dyfish, pasi nëse nuk do të kishte kompaninë ku punoj, as nuk do të kisha shkruar serverin. Jam zhvillues i vetëm. Do të isha mirënjohës për gjetjet e gabimeve dhe kërkesat për veçori.

Burimi: habr.com