Spoštovana skupnost, ta članek se bo osredotočil na učinkovito shranjevanje in pridobivanje na stotine milijonov majhnih datotek. Na tej stopnji je predlagana končna rešitev za datotečne sisteme, združljive s POSIX, s polno podporo za ključavnice, vključno s ključavnicami gruče, in na videz celo brez bergel.
Zato sem za ta namen napisal lasten strežnik po meri.
Pri izvajanju te naloge nam je uspelo rešiti glavno težavo, hkrati pa doseči prihranke na disku in RAM-u, ki ju je naš datotečni sistem gruče neusmiljeno porabljal. Pravzaprav je takšno število datotek škodljivo za vsak datotečni sistem v gručah.
Ideja je naslednja:
Preprosto povedano, majhne datoteke se naložijo prek strežnika, shranijo neposredno v arhiv in iz njega tudi preberejo, velike datoteke pa se postavijo ena poleg druge. Shema: 1 mapa = 1 arhiv, skupaj imamo več milijonov arhivov z majhnimi datotekami in ne nekaj sto milijonov datotek. In vse to je implementirano v celoti, brez kakršnih koli skriptov ali dajanja datotek v tar/zip arhive.
Poskušal bom biti kratek, vnaprej se opravičujem, če bo objava dolga.
Vse se je začelo z dejstvom, da na svetu nisem mogel najti primernega strežnika, ki bi podatke, prejete preko protokola HTTP, shranil neposredno v arhive, brez slabosti, ki so značilne za običajne arhive in objektno shranjevanje. In razlog za iskanje je bil Origin grozd 10 strežnikov, ki se je razrasel do velikega obsega, v katerem se je nabralo že 250,000,000 majhnih datotek in trend rasti se ni nameraval ustaviti.
Za tiste, ki ne marate brati člankov, je malo dokumentacije lažje:
и .
In hkrati docker, zdaj je možnost samo z nginx notri za vsak slučaj:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdNaprej:
Če je datotek veliko, so potrebni znatni viri, najslabše pa je, da jih je nekaj izgubljenih. Na primer, pri uporabi gručastega datotečnega sistema (v tem primeru MooseFS) datoteka ne glede na njeno dejansko velikost vedno zavzema vsaj 64 KB. To pomeni, da je za datoteke velikosti 3, 10 ali 30 KB potrebno na disku 64 KB. Če je datotek četrt milijarde, izgubimo od 2 do 10 terabajtov. Nove datoteke ne bo mogoče ustvarjati v nedogled, saj ima MooseFS omejitev: največ 1 milijarda z eno repliko vsake datoteke.
Ker se število datotek povečuje, je za metapodatke potrebno veliko RAM-a. K obrabi pogonov SSD prispevajo tudi pogosti veliki izpisi metapodatkov.
strežnik wZD. Na diskih smo naredili red.
Strežnik je napisan v Go. Najprej sem moral zmanjšati število datotek. Kako narediti? Zaradi arhiviranja, vendar v tem primeru brez stiskanja, saj so moje datoteke samo stisnjene slike. BoltDB je prišel na pomoč, ki je še vedno moral odpraviti svoje pomanjkljivosti, kar se odraža v dokumentaciji.
Skupaj je namesto četrt milijarde datotek v mojem primeru ostalo le še 10 milijonov Boltovih arhivov. Če bi imel možnost spremeniti trenutno strukturo datotek imenika, bi jo bilo mogoče zmanjšati na približno 1 milijon datotek.
Vse majhne datoteke se zapakirajo v Boltove arhive, ki samodejno dobijo imena imenikov, v katerih se nahajajo, vse velike datoteke pa ostanejo zraven arhivov, nima smisla jih pakirati, to je prilagodljivo. Majhne arhiviramo, velike pustimo nespremenjene. Strežnik deluje transparentno z obema.
Arhitektura in značilnosti strežnika wZD.
Strežnik deluje pod operacijskimi sistemi Linux, BSD, Solaris in OSX. Preizkusil sem samo arhitekturo AMD64 pod Linuxom, vendar bi moralo delovati za ARM64, PPC64, MIPS64.
Glavne značilnosti:
- Večnitnost;
- Multistrežnik, ki zagotavlja toleranco napak in uravnoteženje obremenitve;
- Največja preglednost za uporabnika ali razvijalca;
- Podprte metode HTTP: GET, HEAD, PUT in DELETE;
- Nadzor vedenja pri branju in pisanju prek glav odjemalca;
- Podpora za prilagodljive virtualne gostitelje;
- Podpira celovitost podatkov CRC pri pisanju/branju;
- Poldinamični medpomnilniki za minimalno porabo pomnilnika in optimalno nastavitev delovanja omrežja;
- Odloženo stiskanje podatkov;
- Poleg tega je na voljo večnitni arhivar wZA za selitev datotek brez zaustavitve storitve.
Prava izkušnja:
Strežnik in arhivar sem razvijal in testiral na živih podatkih že kar dolgo časa, zdaj pa uspešno deluje na gruči, ki vključuje 250,000,000 majhnih datotek (slik), ki se nahajajo v 15,000,000 imenikih na ločenih SATA diskih. Grozd 10 strežnikov je strežnik Origin, nameščen za omrežjem CDN. Za servisiranje sta uporabljena 2 strežnika Nginx + 2 strežnika wZD.
Za tiste, ki se odločijo za uporabo tega strežnika, bi bilo pametno pred uporabo načrtovati strukturo imenika, če je na voljo. Naj takoj rezerviram, da strežnik ni namenjen strpanju vsega v arhiv 1 Bolt.
Testiranje delovanja:
Manjša kot je velikost stisnjene datoteke, hitreje se na njej izvajata operaciji GET in PUT. Primerjajmo skupni čas pisanja odjemalca HTTP v običajne datoteke in arhive Bolt ter branja. Primerjano je delo z datotekami velikosti 32 KB, 256 KB, 1024 KB, 4096 KB in 32768 KB.
Pri delu z arhivi Bolt se preveri celovitost podatkov vsake datoteke (uporablja se CRC), pred snemanjem in tudi po zapisu pride do sprotnega branja in preračunavanja, to seveda povzroča zamude, a glavna stvar je varnost podatkov.
Opravil sem teste zmogljivosti na pogonih SSD, saj testi na pogonih SATA ne kažejo jasne razlike.
Grafi na podlagi rezultatov testiranja:
Kot lahko vidite, je za majhne datoteke razlika v času branja in pisanja med arhiviranimi in nearhiviranimi datotekami majhna.
Povsem drugačno sliko dobimo pri testiranju branja in pisanja datotek velikosti 32 MB:
Časovna razlika med branjem datotek je znotraj 5-25 ms. Pri snemanju je stvar slabša, razlika je okoli 150 ms. Toda v tem primeru ni potrebe po nalaganju velikih datotek, preprosto nima smisla v tem, saj lahko živijo ločeno od arhivov.
*Tehnično lahko ta strežnik uporabite za naloge, ki zahtevajo NoSQL.
Osnovni načini dela s strežnikom wZD:
Nalaganje navadne datoteke:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgNalaganje datoteke v arhiv Bolt (če parameter strežnika fmaxsize, ki določa največjo velikost datoteke, ki je lahko vključena v arhiv, ni presežen; če je presežen, se datoteka kot običajno naloži poleg arhiva):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgPrenos datoteke (če so na disku in v arhivu datoteke z enakimi imeni, potem ima pri prenosu privzeto prednost nearhivirana datoteka):
curl -o test.jpg http://localhost/test/test.jpgPrenos datoteke iz arhiva Bolt (prisilno):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgOpisi ostalih metod so v dokumentaciji.
Strežnik trenutno podpira samo protokol HTTP, s HTTPS pa še ne deluje. Tudi metoda POST ni podprta (ni še odločeno, ali je potrebna ali ne).
Kdor se poglobi v izvorno kodo, bo tam našel butterscotch, ni vsem všeč, vendar glavne kode nisem vezal na funkcije spletnega ogrodja, razen za obravnavo prekinitev, tako da jo lahko v prihodnosti hitro prepišem za skoraj vse motor.
Narediti:
- Razvoj lastnega replikatorja in distributerja + geo za možnost uporabe v velikih sistemih brez gručnih datotečnih sistemov (Vse za odrasle)
- Možnost popolne povratne obnovitve metapodatkov, če so popolnoma izgubljeni (če uporabljate distributerja)
- Izvorni protokol za zmožnost uporabe trajnih omrežnih povezav in gonilnikov za različne programske jezike
- Napredne možnosti uporabe komponente NoSQL
- Kompresije različnih vrst (gzip, zstd, snappy) za datoteke ali vrednosti v arhivih Bolt in za običajne datoteke
- Šifriranje različnih vrst za datoteke ali vrednosti v arhivih Bolt in za običajne datoteke
- Zakasnjena video pretvorba na strani strežnika, vključno z GPE
Imam vse, upam da bo ta strežnik komu koristil, BSD-3 licenca, dvojne avtorske pravice, saj če ne bi bilo firme kjer delam, strežnik ne bi bil napisan. Jaz sem edini razvijalec. Hvaležen bom za morebitne napake in zahteve po funkcijah, ki jih najdete.
Vir: www.habr.com