Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea

Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea

Komunitate agurgarria, Artikulu hau ehunka milioi fitxategi txiki modu eraginkorrean biltegiratzean eta berreskuratzean zentratuko da. Fase honetan, azken irtenbidea proposatzen da POSIX-ekin bateragarriak diren fitxategi-sistemetarako, blokeoetarako laguntza osoa dutenak, kluster blokeoak barne, eta itxuraz makulurik gabe ere.

Beraz, nire zerbitzari pertsonalizatua idatzi nuen horretarako.
Zeregin hau ezartzean, arazo nagusia konpontzea lortu dugu, eta, aldi berean, gure kluster fitxategi-sistemak errukirik gabe kontsumitzen zuen diskoko espazioan eta RAM-an aurreztea lortu genuen. Egia esan, horrelako fitxategi kopuru bat kaltegarria da edozein multzotako fitxategi-sistemarentzat.

Ideia hau da:

Hitz sinpleetan, fitxategi txikiak zerbitzariaren bidez kargatzen dira, zuzenean artxiboan gordetzen dira, eta bertatik irakurtzen dira, eta fitxategi handiak elkarren ondoan jartzen dira. Eskema: 1 karpeta = 1 artxibo, guztira hainbat milioi artxibo ditugu fitxategi txikiekin, eta ez ehunka milioi fitxategi. Eta hori guztia guztiz inplementatuta dago, inolako scriptik edo fitxategiak tar/zip artxiboetan jarri gabe.

Motza izaten saiatuko naiz, aldez aurretik barkamena eskatzen dizut mezua luzea bada.

Dena hasi zen munduan ezin nuela aurkitu HTTP protokoloaren bidez jasotako datuak artxiboetan zuzenean gordetzeko zerbitzari egokirik aurkitu, ohiko artxiboek eta objektuen biltegiratzeek dituzten desabantailak gabe. Eta bilaketaren arrazoia eskala handian hazi zen 10 zerbitzarien Origin klusterra izan zen, zeinetan 250,000,000 fitxategi txiki pilatuta zeuden jada, eta hazkunde joera ez zen geldituko.

Artikuluak irakurtzea gustatzen ez zaienarentzat, dokumentazio apur bat errazagoa da:

Hemen ΠΈ Hemen.

Eta docker aldi berean, orain aukera bat dago nginx barruan bakarrik badaezpada:

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

Hurrengoa:

Fitxategi asko baldin badira, baliabide garrantzitsuak behar dira, eta okerrena da horietako batzuk alferrik galtzen direla. Adibidez, clustered fitxategi-sistema bat erabiltzen denean (kasu honetan, MooseFS), fitxategiak, bere benetako tamaina edozein dela ere, gutxienez 64 KB hartzen ditu beti. Hau da, 3, 10 edo 30 KB-ko fitxategietarako, 64 KB behar dira diskoan. Mila milioi fitxategi laurden baldin badaude, 2 eta 10 terabyte galtzen ditugu. Ezin izango da fitxategi berriak sortu mugagabean, MooseFS-k muga bat baitu: 1 milioi baino gehiago fitxategi bakoitzaren erreplika batekin.

Fitxategi kopurua handitzen doan heinean, RAM asko behar da metadatuetarako. Metadatu handiek maiz isurtzeak SSD unitateen higaduran eragiten dute.

wZD zerbitzaria. Diskoetan gauzak ordenatzen ditugu.

Zerbitzaria Go-n idatzita dago. Lehenik eta behin, fitxategi kopurua murriztu behar nuen. Nola egin? Artxibatzea dela eta, baina kasu honetan konpresiorik gabe, nire fitxategiak irudi konprimituak besterik ez baitira. BoltDB erreskatatzera etorri zen, oraindik bere gabezietatik kendu behar zena, hori dokumentazioan islatzen da.

Guztira, mila milioi laurden fitxategiren ordez, nire kasuan 10 milioi Bolt artxibo besterik ez ziren geratzen. Uneko direktorio-fitxategien egitura aldatzeko aukera izango banu, posible izango litzateke gutxi gorabehera milioi bat fitxategira murriztea.

Fitxategi txiki guztiak Bolt artxiboetan biltzen dira, eta horiek automatikoki jasotzen dituzte kokatutako direktorioen izenak, eta fitxategi handi guztiak artxiboen ondoan geratzen dira; ez du balio horiek ontziratzeak, hau pertsonalizagarria da. Txikiak artxibatu egiten dira, handiak aldatu gabe. Zerbitzariak gardentasunez funtzionatzen du biekin.

wZD zerbitzariaren arkitektura eta ezaugarriak.

Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea

Zerbitzariak Linux, BSD, Solaris eta OSX sistema eragileekin funtzionatzen du. Linux-en AMD64 arkitekturarako bakarrik probatu nuen, baina ARM64, PPC64, MIPS64-rekin funtzionatu beharko luke.

Ezaugarri nagusiak:

  • Hari anitzekoa;
  • Zerbitzari anitzekoa, akatsen tolerantzia eta karga orekatzea eskainiz;
  • Erabiltzaile edo garatzaileentzako gardentasun handiena;
  • Onartutako HTTP metodoak: GET, HEAD, PUT eta DELETE;
  • Irakurtzeko eta idazteko portaera bezeroen alboko goiburuen bidez kudeatzea;
  • Oso konfiguragarriak diren ostalari birtualentzako laguntza;
  • Onartu CRC datuen osotasuna idaztean/irakurtzean;
  • Buffer erdi-dinamikoak memoria gutxieneko kontsumorako eta sareko errendimendu optimorako sintonizaziorako;
  • Datuen trinkotze geroratua;
  • Horrez gain, hari anitzeko wZA artxibatzaile bat eskaintzen da fitxategiak migratzeko zerbitzua gelditu gabe.

Benetako esperientzia:

Denbora dezente daramat zerbitzaria eta artxiboa zuzeneko datuetan garatzen eta probatzen, orain arrakastaz funtzionatzen ari da 250,000,000 fitxategi txiki (argazkiak) barne hartzen dituen kluster batean, 15,000,000 direktorioetan SATA unitate bereizietan. 10 zerbitzariko multzoa CDN sare baten atzean instalatutako Origin zerbitzari bat da. Zerbitzua emateko, 2 Nginx zerbitzari + 2 wZD zerbitzari erabiltzen dira.

Zerbitzari hau erabiltzea erabakitzen dutenentzat, komenigarria litzateke direktorioen egitura planifikatzea, hala badagokio, erabili aurretik. Utzidazu erreserba bat egin berehala zerbitzariak ez duela dena 1 Bolt artxibo batean sartzeko.

Errendimendu-probak:

Zenbat eta txikiagoa izan konprimatutako fitxategiaren tamaina, orduan eta azkarrago egiten dira GET eta PUT eragiketak. Konpara dezagun HTTP bezeroak idazteko denbora osoa fitxategi arruntekin eta Bolt artxiboekin, baita irakurtzeko ere. 32 KB, 256 KB, 1024 KB, 4096 KB eta 32768 KB-ko fitxategiekin lan egitea konparatzen da.

Bolt artxiboekin lan egiten denean, fitxategi bakoitzaren datuen osotasuna egiaztatzen da (CRC erabiltzen da), grabatu aurretik eta, gainera, grabatu ondoren, etengabeko irakurketa eta birkalkulua gertatzen da, honek berez atzerapenak dakartza, baina gauza nagusia datuen segurtasuna da.

Errendimendu probak egin nituen SSD unitateetan, SATA diskoetan egindako probek ez baitute alde argirik erakusten.

Proben emaitzetan oinarritutako grafikoak:

Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea
Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea

Ikus dezakezunez, artxibo txikietan artxibatutako eta artxibatu gabeko fitxategien artean irakurtzeko eta idazteko denboraren aldea txikia da.

Irudi guztiz ezberdina lortzen dugu 32 MB-ko tamainako fitxategiak irakurtzen eta idazten probatzean:

Gorde eraginkortasunez ehunka milioi fitxategi txiki. Auto-ostatatutako irtenbidea

Fitxategien irakurketaren arteko denbora-aldea 5-25 ms artekoa da. Grabaketarekin, gauzak okerrago daude, aldea 150 ms ingurukoa da. Baina kasu honetan ez dago fitxategi handiak kargatu beharrik; besterik gabe, ez du balio hori egiteak; artxiboetatik bereizita bizi daitezke.

*Teknikoki, zerbitzari hau erabil dezakezu NoSQL behar duten zereginetarako.

wZD zerbitzariarekin lan egiteko oinarrizko metodoak:

Fitxategi arrunt bat kargatzen:

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

Fitxategi bat Bolt artxibora igotzea (artxiboan sar daitekeen gehienezko fitxategi-tamaina zehazten duen fmaxsize zerbitzariaren parametroa gainditzen ez bada; hori gainditzen bada, artxiboaren ondoan ohiko moduan igoko da fitxategia):

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

Fitxategi bat deskargatzea (diskoan eta artxiboan izen bereko fitxategiak badaude, deskargatzean, lehenespenez artxibatu gabeko fitxategiari ematen zaio lehentasuna):

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

Bolt artxibotik fitxategi bat deskargatzea (behartuta):

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

Beste metodo batzuen deskribapenak dokumentazioan daude.

wZD Dokumentazioa
wZA Dokumentazioa

Une honetan zerbitzariak HTTP protokoloa soilik onartzen du; ez du HTTPSrekin funtzionatzen oraindik. POST metodoa ere ez da onartzen (oraindik ez da erabaki behar den ala ez).

Iturburu-kodea sakontzen duenak gurina aurkituko du han, denei ez zaie gustatzen, baina ez dut kode nagusia web esparruko funtzioekin lotu, eten-kudeatzailea izan ezik, beraz, etorkizunean azkar berridatzi ahal izango dut ia edozeinentzat. motorra.

egitekoen:

  • Zure erreplikatzailea eta banatzailea garatzea + geo sistema handietan erabiltzeko aukera izateko cluster fitxategi-sistemarik gabe (Dena helduentzat)
  • Metadatuak guztiz alderantziz berreskuratzeko aukera guztiz galtzen badira (banatzaile bat erabiliz gero)
  • Programazio-lengoaia desberdinetarako sare-konexio iraunkorrak eta kontrolatzaileak erabiltzeko gaitasuna duen protokolo natiboa
  • NoSQL osagaia erabiltzeko aukera aurreratuak
  • Mota ezberdinetako konpresioak (gzip, zstd, snappy) Bolt artxiboen barruko fitxategi edo balioetarako eta fitxategi arruntetarako
  • Bolt artxiboen barruko fitxategi edo balioetarako mota ezberdinetako enkriptatzea eta fitxategi arruntetarako
  • Zerbitzariaren aldeko bideo bihurketa atzeratua, GPUn barne

Denetarik daukat, espero dut zerbitzari hau norbaiti baliagarria izatea, BSD-3 lizentzia, copyright bikoitza, izan ere, lan egiten dudan enpresarik ez balego, zerbitzaria ez litzateke idatzita egongo. Ni naiz garatzaile bakarra. Eskertuko nuke aurkitzen dituzun akats eta eginbide eskaerak.

Iturria: www.habr.com

Gehitu iruzkin berria