Vážená komunita, tento článok sa zameria na efektívne ukladanie a získavanie stoviek miliónov malých súborov. V tejto fáze je navrhnuté konečné riešenie pre súborové systémy kompatibilné s POSIX s plnou podporou zámkov, vrátane klastrových zámkov, a zdanlivo dokonca bez bariel.
Na tento účel som si teda napísal vlastný server.
V priebehu implementácie tejto úlohy sa nám podarilo vyriešiť hlavný problém a zároveň dosiahnuť úsporu miesta na disku a RAM, ktoré náš klastrový súborový systém nemilosrdne spotrebovával. V skutočnosti je takýto počet súborov škodlivý pre akýkoľvek klastrovaný súborový systém.
Myšlienka je taká:
Jednoducho povedané, malé súbory sa nahrávajú cez server, ukladajú sa priamo do archívu a tiež sa z neho čítajú a veľké súbory sú umiestnené vedľa seba. Schéma: 1 priečinok = 1 archív, celkovo máme niekoľko miliónov archívov s malými súbormi a nie niekoľko stoviek miliónov súborov. A to všetko je implementované plne, bez akýchkoľvek skriptov alebo ukladania súborov do archívov tar/zip.
Pokúsim sa to skrátiť, vopred sa ospravedlňujem, ak je príspevok dlhý.
Všetko to začalo tým, že som vo svete nenašiel vhodný server, ktorý by dokázal ukladať dáta prijaté cez HTTP protokol priamo do archívov, bez nevýhod, ktoré sú vlastné klasickým archívom a objektovým úložiskám. A dôvodom hľadania bol klaster Origin 10 serverov, ktorý sa rozrástol do veľkého rozsahu, v ktorom sa už nahromadilo 250,000,000 XNUMX XNUMX malých súborov a trend rastu sa nezastaví.
Pre tých, ktorí neradi čítajú články, je jednoduchšia malá dokumentácia:
и .
A zároveň docker, teraz existuje možnosť iba s nginx vo vnútri pre prípad:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdĎalšie:
Ak existuje veľa súborov, sú potrebné značné zdroje a najhoršie na tom je, že niektoré z nich sú zbytočné. Napríklad pri použití klastrovaného súborového systému (v tomto prípade MooseFS) súbor, bez ohľadu na jeho skutočnú veľkosť, vždy zaberá aspoň 64 KB. To znamená, že pre súbory s veľkosťou 3, 10 alebo 30 KB je na disku potrebných 64 KB. Ak existuje štvrť miliardy súborov, stratíme 2 až 10 terabajtov. Nové súbory nebude možné vytvárať donekonečna, pretože MooseFS má obmedzenie: nie viac ako 1 miliardu s jednou replikou každého súboru.
So zvyšujúcim sa počtom súborov je pre metadáta potrebné veľké množstvo pamäte RAM. K opotrebovaniu SSD diskov prispievajú aj časté veľké skládky metadát.
server wZD. Dáme veci do poriadku na diskoch.
Server je napísaný v Go. V prvom rade som potreboval znížiť počet súborov. Ako to spraviť? Kvôli archivácii, ale v tomto prípade bez kompresie, keďže moje súbory sú len komprimované obrázky. Na pomoc prišiel BoltDB, ktorý ešte musel byť odstránený z jeho nedostatkov, to sa odráža v dokumentácii.
Celkovo namiesto štvrť miliardy súborov zostalo v mojom prípade len 10 miliónov Boltových archívov. Ak by som mal možnosť zmeniť aktuálnu adresárovú štruktúru súborov, bolo by možné ju zredukovať na približne 1 milión súborov.
Všetky malé súbory sú zabalené do archívov Bolt, ktoré automaticky dostanú názvy adresárov, v ktorých sa nachádzajú, a všetky veľké súbory zostávajú vedľa archívov, nemá zmysel ich baliť, je to prispôsobiteľné. Malé sa archivujú, veľké sa nechávajú nezmenené. Server pracuje transparentne s oboma.
Architektúra a funkcie servera wZD.
Server funguje pod operačnými systémami Linux, BSD, Solaris a OSX. Testoval som iba architektúru AMD64 pod Linuxom, ale mala by fungovať pre ARM64, PPC64, MIPS64.
Hlavné rysy:
- Multithreading;
- Multiserver, ktorý poskytuje odolnosť voči chybám a vyrovnávanie záťaže;
- Maximálna transparentnosť pre používateľa alebo vývojára;
- Podporované metódy HTTP: GET, HEAD, PUT a DELETE;
- Správa správania pri čítaní a zápise prostredníctvom hlavičiek na strane klienta;
- Podpora vysoko konfigurovateľných virtuálnych hostiteľov;
- Podpora integrity dát CRC pri zápise/čítaní;
- Polodynamické vyrovnávacie pamäte pre minimálnu spotrebu pamäte a optimálne ladenie výkonu siete;
- Odložené zhutňovanie údajov;
- Okrem toho je ponúkaný viacvláknový archivátor wZA na migráciu súborov bez zastavenia služby.
Skutočné skúsenosti:
Server a archivátor som vyvíjal a testoval na živých dátach pomerne dlho, teraz úspešne funguje na klastri, ktorý obsahuje 250,000,000 15,000,000 10 malých súborov (obrázkov) umiestnených v 2 2 XNUMX adresároch na samostatných SATA diskoch. Klaster XNUMX serverov je server Origin nainštalovaný za sieťou CDN. Na jeho obsluhu sa používajú XNUMX servery Nginx + XNUMX servery wZD.
Pre tých, ktorí sa rozhodnú používať tento server, by bolo rozumné naplánovať si pred použitím adresárovú štruktúru, ak je to vhodné. Dovoľte mi hneď urobiť výhradu, že server nie je určený na to, aby všetko vtesnal do archívu 1 Bolt.
Testovanie výkonu:
Čím menšia je veľkosť zazipovaného súboru, tým rýchlejšie sa na ňom vykonajú operácie GET a PUT. Porovnajme celkový čas zápisu HTTP klienta do bežných súborov a archívov Bolt, ako aj čítania. Porovnáva sa práca so súbormi s veľkosťou 32 KB, 256 KB, 1024 KB, 4096 KB a 32768 KB.
Pri práci s archívmi Bolt sa kontroluje integrita údajov každého súboru (používa sa CRC), pred nahrávaním a aj po nahrávaní dochádza k priebežnému čítaniu a prepočítavaniu, čo prirodzene prináša oneskorenia, ale hlavnou vecou je bezpečnosť údajov.
Vykonal som testy výkonu na jednotkách SSD, pretože testy na jednotkách SATA neukázali jasný rozdiel.
Grafy založené na výsledkoch testovania:
Ako vidíte, pri malých súboroch je rozdiel v časoch čítania a zápisu medzi archivovanými a nearchivovanými súbormi malý.
Úplne iný obraz získame pri testovaní čítania a zápisu súborov s veľkosťou 32 MB:
Časový rozdiel medzi čítaním súborov je 5-25 ms. S nahrávaním je to už horšie, rozdiel je asi 150 ms. V tomto prípade však nie je potrebné nahrávať veľké súbory, jednoducho to nemá zmysel, môžu žiť oddelene od archívov.
*Technicky môžete tento server použiť na úlohy vyžadujúce NoSQL.
Základné metódy práce so serverom wZD:
Načítavanie bežného súboru:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgOdovzdanie súboru do archívu Bolt (ak nie je prekročený parameter servera fmaxsize, ktorý určuje maximálnu veľkosť súboru, ktorý možno do archívu zahrnúť; ak je prekročený, súbor sa odošle ako zvyčajne vedľa archívu):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgSťahovanie súboru (ak sú na disku a v archíve súbory s rovnakými názvami, pri sťahovaní má prioritu štandardne nearchivovaný súbor):
curl -o test.jpg http://localhost/test/test.jpgSťahovanie súboru z archívu Bolt (vynútené):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgPopisy ostatných metód sú v dokumentácii.
Server momentálne podporuje iba protokol HTTP, zatiaľ nefunguje s HTTPS. Metóda POST tiež nie je podporovaná (ešte nebolo rozhodnuté, či je potrebná alebo nie).
Kto sa hrabe v zdrojovom kode, najde tam maslovku, nie kazdemu sa paci, ale ja som neviazal hlavny kod na funkcie web frameworku, okrem obsluhy prerusenia, takze v buducnosti ho mozem rychlo prepisat na takmer hocijaky motora.
Robiť:
- Vývoj vlastného replikátora a distribútora + geo pre možnosť použitia vo veľkých systémoch bez klastrových súborových systémov (Všetko pre dospelých)
- Možnosť úplnej spätnej obnovy metadát, ak sa úplne stratia (ak používate distribútora)
- Natívny protokol pre schopnosť používať trvalé sieťové pripojenia a ovládače pre rôzne programovacie jazyky
- Pokročilé možnosti využitia komponentu NoSQL
- Kompresie rôznych typov (gzip, zstd, snappy) pre súbory alebo hodnoty v archívoch Bolt a pre bežné súbory
- Šifrovanie rôznych typov pre súbory alebo hodnoty v archívoch Bolt a pre bežné súbory
- Oneskorená konverzia videa na strane servera vrátane GPU
Mám všetko, dúfam, že sa tento server niekomu bude hodiť, licencia BSD-3, dvojité autorské práva, pretože keby neexistovala spoločnosť, kde pracujem, server by nebol napísaný. Som jediný vývojár. Bol by som vďačný za akékoľvek chyby a požiadavky na funkcie, ktoré nájdete.
Zdroj: hab.com