Lugupeetud kogukond! See artikkel keskendub sadade miljonite väikeste failide tõhusale salvestamisele ja toomisele. Selles etapis pakutakse lõplikku lahendust POSIX-iga ühilduvatele failisüsteemidele, millel on täielik lukkude tugi, sealhulgas kobarlukud, ja näiliselt isegi ilma karkudeta.
Nii et ma kirjutasin selleks otstarbeks oma kohandatud serveri.
Selle ülesande elluviimise käigus õnnestus meil põhiprobleem lahendada ja samal ajal säästa kettaruumi ja RAM-i, mida meie klastri failisüsteem halastamatult kulutas. Tegelikult on selline failide arv kahjulik mis tahes rühmitatud failisüsteemile.
Idee on selline:
Lihtsamalt öeldes laaditakse serveri kaudu üles väikesed failid, need salvestatakse otse arhiivi ja sealt ka loetakse ning suured failid asetatakse kõrvuti. Skeem: 1 kaust = 1 arhiiv, kokku on meil mitu miljonit väikeste failidega arhiive, mitte mitusada miljonit faili. Ja seda kõike rakendatakse täielikult, ilma skriptideta või faile tar/zip-arhiivi panemata.
Püüan lühidalt teha, vabandan juba ette, kui postitus on pikk.
Kõik sai alguse sellest, et ma ei leidnud maailmast sobivat serverit, mis suudaks HTTP-protokolli kaudu saadud andmeid otse arhiividesse salvestada, ilma tavaarhiividele ja objektide salvestamisele omaste puudusteta. Ja otsingu põhjuseks oli mastaapseks kasvanud 10 serverist koosnev Origin-klaster, kuhu oli kogunenud juba 250,000,000 XNUMX XNUMX väikest faili ja kasvutrend ei kavatsenud peatuda.
Neile, kellele artikleid lugeda ei meeldi, on väike dokumentatsioon lihtsam:
и .
Ja docker samal ajal, nüüd on igaks juhuks võimalus ainult nginxiga sees:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdJärgmine:
Kui faile on palju, on vaja märkimisväärseid ressursse ja kõige hullem on see, et osa neist läheb raisku. Näiteks rühmitatud failisüsteemi (antud juhul MooseFS) kasutamisel võtab fail olenemata selle tegelikust suurusest alati vähemalt 64 KB. See tähendab, et 3, 10 või 30 KB suuruste failide jaoks on kettal vaja 64 KB. Kui faile on veerand miljardit, kaotame 2–10 terabaiti. Uusi faile ei saa lõputult luua, kuna MooseFS-il on piirang: mitte rohkem kui 1 miljard iga faili ühe koopiaga.
Failide arvu kasvades on metaandmete jaoks vaja palju RAM-i. SSD-draivide kulumisele aitavad kaasa ka sagedased suured metaandmete tõmmised.
wZD server. Panime ketastel asjad korda.
Server on kirjutatud Go. Esiteks oli mul vaja failide arvu vähendada. Kuidas seda teha? Arhiveerimise tõttu, kuid antud juhul ilma tihendamiseta, kuna minu failid on lihtsalt tihendatud pildid. Appi tuli BoltDB, mis tuli siiski oma puudustest kõrvaldada, see kajastub dokumentatsioonis.
Kokku jäi minu puhul veerand miljardi faili asemel alles vaid 10 miljonit Bolti arhiivi. Kui mul oleks võimalus muuta praegust kataloogifaili struktuuri, oleks võimalik seda vähendada ligikaudu 1 miljoni failini.
Kõik väikesed failid pakitakse Bolti arhiividesse, mis saavad automaatselt kataloogide nimed, kus nad asuvad, ja kõik suured failid jäävad arhiivide kõrvale, neid pole mõtet pakkida, see on kohandatav. Väikesed arhiveeritakse, suured jäetakse muutmata. Server töötab mõlemaga läbipaistvalt.
wZD-serveri arhitektuur ja funktsioonid.
Server töötab Linuxi, BSD, Solarise ja OSX operatsioonisüsteemide all. Testisin Linuxi all ainult AMD64 arhitektuuri, kuid see peaks töötama ARM64, PPC64, MIPS64 jaoks.
Põhijooned:
- Mitmelõimeline;
- Multiserver, mis pakub tõrketaluvust ja koormuse tasakaalustamist;
- maksimaalne läbipaistvus kasutaja või arendaja jaoks;
- Toetatud HTTP-meetodid: GET, HEAD, PUT ja DELETE;
- Lugemis- ja kirjutamiskäitumise juhtimine kliendipäiste kaudu;
- Paindlike virtuaalsete hostide tugi;
- Toetage CRC andmete terviklikkust kirjutamisel/lugemisel;
- Pooldünaamilised puhvrid minimaalse mälutarbimise ja optimaalse võrgu jõudluse häälestamiseks;
- Edasilükatud andmete tihendamine;
- Lisaks pakutakse failide migreerimiseks ilma teenust peatamata mitme lõimega arhiivi wZA.
Tõeline kogemus:
Olen serverit ja arhiveerijat arendanud ja testinud reaalajas andmetel päris pikka aega, nüüd töötab see edukalt klastris, mis sisaldab 250,000,000 15,000,000 10 väikest faili (pilti), mis asuvad 2 2 XNUMX kataloogis eraldi SATA-draividel. XNUMX serverist koosnev klaster on CDN-võrgu taha installitud Origin-server. Selle teenindamiseks kasutatakse XNUMX Nginxi serverit + XNUMX wZD serverit.
Neil, kes otsustavad seda serverit kasutada, oleks mõistlik enne kasutamist planeerida kataloogistruktuur, kui see on asjakohane. Lubage mul teha kohe reservatsioon, et server ei ole mõeldud kõike 1 Bolti arhiivi toppima.
Jõudluskatse:
Mida väiksem on ZIP-faili suurus, seda kiiremini tehakse sellega GET- ja PUT-operatsioone. Võrdleme HTTP-kliendi kirjutamise koguaega tavafailide ja Bolti arhiividega, aga ka lugemist. Võrreldakse tööd failidega suurusega 32 KB, 256 KB, 1024 KB, 4096 KB ja 32768 KB.
Bolti arhiividega töötades kontrollitakse iga faili andmete terviklikkust (kasutatakse CRC-d), enne salvestamist ja ka pärast salvestamist toimub käigupealt lugemine ja ümberarvutamine, see toob loomulikult kaasa viivitusi, kuid peamine on andmete turvalisus.
Viisin läbi SSD-draivide jõudlustestid, kuna SATA-draivide testid ei näita selget erinevust.
Testimistulemustel põhinevad graafikud:
Nagu näete, on väikeste failide puhul arhiveeritud ja mittearhiveeritud failide lugemis- ja kirjutamisaegade erinevus väike.
32 MB suuruste failide lugemise ja kirjutamise testimisel saame hoopis teistsuguse pildi:
Failide lugemise ajavahe on 5-25 ms. Salvestamisega on asi hullem, vahe on ca 150 ms. Kuid sel juhul pole vaja suuri faile üles laadida, seda pole lihtsalt mõtet teha, need võivad elada arhiividest eraldi.
*Tehniliselt saate seda serverit kasutada NoSQL-i nõudvate ülesannete jaoks.
Põhimeetodid wZD serveriga töötamiseks:
Tavalise faili laadimine:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgFaili üleslaadimine Bolti arhiivi (kui ei ületata serveri parameetrit fmaxsize, mis määrab maksimaalse failimahu, mida saab arhiivi kaasata; selle ületamisel laaditakse fail üles tavapäraselt arhiivi kõrvale):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgFaili allalaadimine (kui kettal ja arhiivis on sama nimega faile, siis allalaadimisel on vaikimisi prioriteet arhiveerimata failile):
curl -o test.jpg http://localhost/test/test.jpgFaili allalaadimine Bolti arhiivist (sunnitud):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgTeiste meetodite kirjeldused on dokumentatsioonis.
Server toetab praegu ainult HTTP-protokolli, see ei tööta veel HTTPS-iga. Samuti ei toetata POST meetodit (pole veel otsustatud, kas seda on vaja või mitte).
Kes lähtekoodi süveneb, see leiab sealt butterscotch’i, see ei meeldi kõigile, aga ma ei sidunud põhikoodi veebiraamistiku funktsioonidega, välja arvatud katkestuste töötleja, nii et edaspidi saan selle peaaegu iga jaoks kiiresti ümber kirjutada mootor.
Tegema:
- Oma replikaatori ja turustaja + geo arendamine, et seda saaks kasutada suurtes süsteemides ilma klastri failisüsteemideta (kõik täiskasvanutele)
- Metaandmete täieliku tagurpidi taastamise võimalus, kui need on täielikult kadunud (turustaja kasutamisel)
- Native protokoll, mis võimaldab kasutada püsivaid võrguühendusi ja draivereid erinevate programmeerimiskeelte jaoks
- Täpsemad võimalused NoSQL komponendi kasutamiseks
- Erinevat tüüpi pakkimised (gzip, zstd, snappy) Bolti arhiivides olevate failide või väärtuste ja tavaliste failide jaoks
- Erinevat tüüpi failide või väärtuste krüptimine Bolti arhiivides ja tavaliste failide jaoks
- Hilinenud serveripoolne video teisendamine, sealhulgas GPU-s
Mul on kõik olemas, loodan, et see server on kellelegi kasulik, BSD-3 litsents, topeltautoriõigus, sest kui poleks ettevõtet, kus ma töötan, poleks serverit kirjutatud. Olen ainus arendaja. Oleksin tänulik kõigi leitud vigade ja funktsioonitaotluste eest.
Allikas: www.habr.com