Saja miljoni väikese faili tõhus säilitamine. Iseseisev lahendus

Kallis kogukond, see artikkel on pühendatud tõhusale sadade miljonite väikeste failide salvestamisele ja käitlemisele. Selles faasis pakkume lõpliku lahenduse POSIX-üh compatible failisüsteemidele, mis toetab täielikult lukustusi, sealhulgas klastrite lukustusi, ja tundub, et isegi ilma igasuguste kompromissideta.

Seega, selle eesmärgi saavutamiseks kirjutasin oma spetsialiseeritud serveri.
Selle ülesande elluviimise käigus õnnestus lahendada peamine probleem, saavutada samal ajal diskiruumi ja RAM-i kokkuhoid, mida meie klastrifailisüsteem pidevalt tarbis. Tõeliselt kahjulik on selline arv faile igasugusele klastrifailisüsteemile.

Idee on järgmine:

Lihtsalt öeldes, väiksed failid laaditakse serveri kaudu üles, salvestatakse otse arhiivi ja loetakse samuti sealt. Suured failid pannakse kõrvale. Skeem: 1 kaust = 1 arhiiv, seega meil on mitmeid miljoneid arhiive väikeste failidega, mitte sadu miljonite faile. Ja see on täielikult ellu viidud, ilma igasuguste skriptide ja failide jaotamata tar / zip arhiividesse.

Püüan selgitada lühemalt, vabandan eelnevalt, kui postitus tuleb mahukas.

Kõik algas sellest, et ma ei leidnud maailmas sobivat serverit, mis suudaks andmeid salvestada HTTP protokolli kaudu otse arhiividesse, nii et ei oleks tavaliste arhiivide ja objektide salvestusruumide puudusi. Otsingute põhjuseks oli suures mahus laienenud Origin klaster 10 serveriga, kus oli juba kogunenud 250 000 000 väikest faili, ning kasvutrend ei kavatse lõpetada.

Neile, kellele artiklite lugemine ei meeldi ja kellele väike dokumentatsioon on lihtsam:

siia ja siia.

Ja docker ka, praegu on saadaval variant ainult koos nginx-iga sees igaks juhuks:

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

Jätkame:

Kui faile on väga palju, on vajalikud märkimisväärsed ressursid, ja mis on kõige kurvem, osa neist kaob asjata. Näiteks, kui kasutada klastreeritud failisüsteemi (antud juhul - MooseFS), siis fail, sõltumata tegelikust suurusest, võtab alati vähemalt 64 KB. See tähendab, et failide, mille suurus on 3, 10 või 30 KB, puhul vajatakse kettale 64 KB. Kui faile on veerand miljardit, kaotame 2 kuni 10 terabaiti. Uute failide loomine lõputult ei õnnestu, kuna MooseFS-is on piirang: mitte rohkem kui 1 miljard iga faili repliiki.

Failide arvu suurenedes on metainformatsiooni jaoks vajalik palju töömälu. Samuti suurte metainformatsiooni dump'id aitavad kaasa SSD-kettaste kulumisele.

Server wZD. Teeme kettal korda.

Server on kirjutatud Go keeles. Esiteks pidi mulle vähendama failide arvu. Kuidas seda teha? Arhiveerimise abil, kuid antud juhul ilma kompressioonita, kuna minu failid on sageli tihendatud pildid. Appi tuli BoltDB, mida tuli natuke parandada, see on kajastatud dokumentatsioonis.

Niisiis, minu puhul jäi veerandi miljardi faili asemel alles ainult 10 miljonit Bolt arhive. Kui mul oleks võimalus muuta praegust struktuuri failide täitmiseks kataloogides, siis võiks selle vähendada umbes 1 miljonini.

Kõik väikesed failid pakitakse Bolt arhiividesse, mis saavad automaatselt katalooge, kus nad asuvad, nimeks, ja kõik suured failid jäävad arhiivide kõrvale, neid pole mõtet pakendada, seda saab seadistada. Väikesed - arhiveerime, suured - jätame muutmata. Server töötab sujuvalt nii nende kui ka teistega.

Serveri wZD arhitektuur ja omadused.

Server töötab Linuxi, BSD, Solaris ja OSX operatsioonisüsteemide all. Olen testinud ainult AMD64 arhitektuuri Linuxi all, kuid see peaks sobima ka ARM64, PPC64 ja MIPS64 jaoks.

Põhifunktsioonid:

• Mitme töötluse tugi;
• Mulitiserverite tugi, tagades rikkedeta töö ja koormuse tasakaalustamise;
• Maksimaalne läbipaistvus kasutajale või arendajale;
• Toetatud HTTP meetodid: GET, HEAD, PUT ja DELETE;
• Käitumise haldamine lugemise ja kirjutamise ajal kliendi pealkirjade kaudu;
• Paindlikult seadistatavate virtuaalsete hostide tugi;
• Andmete terviklikkuse tugi CRC kirjutamisel/loetamisel;
• Pooldünaamilised puhverid madala mälu tarbimise ja optimaalse võrgu jõudluse seadistamiseks;
• Andmete kompaktimine
• Lisaks pakutakse mitmeühendiga arhiivijat wZA failide migreerimiseks teenuse katkestamata.

Reaalne kogemus:

Olen arendanud ja testinud serverit ja arhiivijat reaalsetel andmetel üsna pikka aega, nüüd töötab see edukalt klastris, mis hõlmab 250,000,000 väikefaili (pilte), mis asuvad 15,000,000 kataloogis eraldi SATA-diskidel. Klastril, kuhu kuulub 10 serverit, on Origin-server, mis on paigaldatud CDN-võrgu taha. Selle teenindamiseks kasutatakse 2 Nginx serverit + 2 wZD serverit.

Neil, kes otsustavad kasutada seda serverit, tasub enne kasutamist planeerida katalooge struktuuri, kui see on asjakohane. Ütlen kohe, et server ei ole mõeldud kõike ühte Bolt arhiivi toppimiseks.

Jõudlustestimine:

Mida väiksem on arhiivitud faili suurus, seda kiiremini toimuvad GET ja PUT toimingud. Võrdleme HTTP kliendi täielikku kirjutamise aega tavalistes failides ja Bolt arhiivides ning samuti lugemist. Võrdlus toimub failide suurustega 32 KB, 256 KB, 1024 KB, 4096 KB ja 32768 KB.

Bolt arhiivide töötlemisel kontrollitakse iga faili andmete terviklikkust (kasutatakse CRC), enne kirjutamist ja samuti pärast kirjutamist toimub ka lugemine ja uuesti arvutamine, see toob loomulikult kaasa viivitusi, kuid peamine - andmete turvalisus.

Jõudlusteste tegin SSD-mälu seadmetes, kuna SATA-diskidel ei näidata teste selget erinevust.

Testimistulemustest graafikud:

Nagu näha, on väikeste failide lugemise ja kirjutamise ajavahe arhiivitud ja mittearhiivitud failide vahel väike.

Kuid saame täiesti teistsuguse pildi, kui testime 32 MB suuruste failide lugemist ja kirjutamist:

Failide lugemise ajavahe on 5-25 ms. Kirjutamise puhul on olukord halvem, vahe on umbes 150 ms. Kuid antud juhul ei ole suured failid üles laadida mõistetav, sel pole lihtsalt mõtet, need võivad elada eraldi arhiividest.

*Tehniliselt saab seda serverit kasutada ka NoSQL-iga seotud ülesannete jaoks.

Peamised meetodid wZD serveriga töötamiseks:

Tavalise faili laadimine:

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

Faili üleslaadimine Bolt arhivi (kui serveri parameeter fmaxsize, mis määrab maksimaalse faili suuruse, mis saab arhivi lisatud olla, ei ületa, siis faili laaditakse üles tavaliselt koos arhiviga):

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

Faili allalaadimine (kui kettal ja arhivis on faile sama nimega, siis allalaadimisel antakse vaikimisi eelis mittearhiveeritud failile):

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

Faili allalaadimine Bolt arhivist (sundimisega):

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

Muude meetodite kirjeldus on dokumendis.

wZD dokumentatsioon
wZA dokumentatsioon

Server toetab praegu ainult HTTP protokolli, HTTPS ei toimi. Samuti ei toetata POST meetodit (veel ei ole otsustatud, kas see on vajalik või mitte).

Kes uurib lähtekoodi, leiab seal iirist, mida kõik ei armasta, aga ma ei sidunud põhikoodi veebi raamistikuga funktsioonide osas, välja arvatud katkestuste töötleja, seega saan edaspidi uuesti kiirelt kirjutada peaaegu igale mootorile.

ToDo:

• Oma replikatsiooni ja jaotamise arendamine + geo suuremate süsteemide jaoks, ilma klastrite FS-ita (asi tõsiselt)
• Täieliku tagasipöördumise võimalus metaandmete täieliku kadumise korral (distribuutori kasutamise korral)
• Natiivprotokoll, et kasutada püsivaid võrguühendusi ja juhtmeid erinevatesse programmeerimiskeeltesse
• Laienenud võimalused NoSQL komponentide kasutamiseks
• Erinevate tüüpide kokkusurumine (gzip, zstd, snappy) failide või Bolt arhiivide ja tavalisete failide väärtuste jaoks
• Erinevate tüüpide krüpteerimine failide või Bolt arhiivides ja tavalisetes failides
• Edasilükatud serveri videokonverteerimine, sealhulgas GPU-l

Minu poolt kõik, loodan, et see server on kellelegi kasulik, BSD-3 litsents, autorikaitse kahekordne, kuna kui poleks olnud ettevõtet, kus ma töötan, ei oleks ma ka serverit kirjutanud. Olen arendaja üksi. Olen tänulik tõstatatud vigade ja funktsioonide soovituste eest.

Allikas: habr.com