Kæra samfélag, Þessi grein mun leggja áherslu á að geyma og endurheimta hundruð milljóna smáskráa á skilvirkan hátt. Á þessu stigi er lokalausnin lögð til fyrir POSIX-samhæf skráarkerfi með fullum stuðningi fyrir lása, þar á meðal klasalása, og að því er virðist jafnvel án hækja.
Svo ég skrifaði minn eigin sérsniðna netþjón í þessum tilgangi.
Við innleiðingu þessa verkefnis tókst okkur að leysa aðalvandamálið og á sama tíma ná fram sparnaði í diskplássi og vinnsluminni, sem klasaskráakerfið okkar eyddi miskunnarlaust. Reyndar er slíkur fjöldi skráa skaðlegur fyrir öll þyrpuð skráarkerfi.
Hugmyndin er þessi:
Í einföldum orðum, litlum skrám er hlaðið upp í gegnum netþjóninn, þær eru vistaðar beint inn í skjalasafnið og einnig lesnar úr því og stórar skrár eru settar hlið við hlið. Skema: 1 mappa = 1 skjalasafn, samtals höfum við nokkrar milljónir skjalasafna með litlum skrám, en ekki nokkur hundruð milljón skrár. Og allt þetta er útfært að fullu, án nokkurra forskrifta eða setja skrár í tar/zip skjalasafn.
Ég skal reyna að hafa það stutt, ég biðst fyrirfram afsökunar ef færslan er löng.
Þetta byrjaði allt með því að ég fann ekki hentugan netþjón í heiminum sem gæti vistað gögn sem berast í gegnum HTTP samskiptareglur beint inn í skjalasafn, án þeirra ókosta sem felast í hefðbundnum skjalasöfnum og hlutageymslu. Og ástæðan fyrir leitinni var uppruna þyrpingin af 10 netþjónum sem höfðu stækkað í stórum stíl, þar sem 250,000,000 litlar skrár höfðu þegar safnast saman og vöxturinn ætlaði ekki að hætta.
Fyrir þá sem líkar ekki við að lesa greinar er smá skjöl auðveldari:
и .
Og docker á sama tíma, nú er valkostur aðeins með nginx inni bara ef:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdNext:
Ef skrárnar eru margar þarf umtalsvert fjármagn og það versta er að sumt þeirra er sóað. Til dæmis, þegar þú notar klasaskráakerfi (í þessu tilfelli, MooseFS), tekur skráin, óháð raunverulegri stærð, alltaf að minnsta kosti 64 KB. Það er, fyrir skrár sem eru 3, 10 eða 30 KB að stærð, þarf 64 KB á disknum. Ef það eru fjórðungur milljarðs skráa töpum við frá 2 til 10 terabætum. Það verður ekki hægt að búa til nýjar skrár endalaust, þar sem MooseFS hefur takmörkun: ekki meira en 1 milljarður með einni eftirmynd af hverri skrá.
Eftir því sem skrám fjölgar þarf mikið vinnsluminni fyrir lýsigögn. Tíðar stórar lýsigagnasendingar stuðla einnig að sliti á SSD-drifum.
wZD miðlara. Við setjum hlutina í röð á diskunum.
Miðlarinn er skrifaður í Go. Fyrst af öllu þurfti ég að fækka skrám. Hvernig á að gera það? Vegna skjalavistunar, en í þessu tilviki án þjöppunar, þar sem skrárnar mínar eru bara þjappaðar myndir. BoltDB kom til bjargar, sem enn þurfti að útrýma úr göllum sínum, þetta kemur fram í skjölunum.
Alls, í stað fjórðungs milljarðs skráa, voru í mínu tilfelli aðeins 10 milljónir Bolt skjalasafna eftir. Ef ég hefði tækifæri til að breyta núverandi möppuskráarskipulagi væri hægt að minnka hana í um það bil 1 milljón skrár.
Öllum litlum skrám er pakkað inn í Bolt skjalasafn sem fá sjálfkrafa nöfn möppanna sem þær eru staðsettar í og allar stórar skrár eru eftir við hlið skjalasafnsins; það þýðir ekkert að pakka þeim, þetta er sérhannaðar. Litlir eru geymdir, stórir eru óbreyttir. Miðlarinn vinnur gagnsætt með báðum.
Arkitektúr og eiginleikar wZD netþjónsins.
Miðlarinn starfar undir Linux, BSD, Solaris og OSX stýrikerfum. Ég prófaði aðeins fyrir AMD64 arkitektúr undir Linux, en það ætti að virka fyrir ARM64, PPC64, MIPS64.
Aðalatriði:
- Fjölþráður;
- Multiserver, sem veitir bilanaþol og álagsjafnvægi;
- Hámarks gagnsæi fyrir notandann eða þróunaraðilann;
- Studdar HTTP aðferðir: GET, HEAD, PUT og DELETE;
- Stjórna lestrar- og skrifahegðun í gegnum hausa viðskiptavinarhliðar;
- Stuðningur við mjög stillanlega sýndargestgjafa;
- Styðja CRC gagnaheilleika þegar þú skrifar/lestur;
- Hálfdýnamískir biðminni fyrir lágmarks minnisnotkun og bestu stillingu á afköstum netsins;
- Frestað gagnaþjöppun;
- Að auki er boðið upp á fjölþráða skjalavörslu wZA til að flytja skrár án þess að stöðva þjónustuna.
Raunveruleg reynsla:
Ég hef verið að þróa og prófa netþjóninn og skjalavörðinn á lifandi gögnum í nokkuð langan tíma, nú er hann starfræktur á þyrping sem inniheldur 250,000,000 litlar skrár (myndir) staðsettar í 15,000,000 möppum á aðskildum SATA-drifum. Þyrping af 10 netþjónum er uppruna netþjónn settur upp á bak við CDN net. Til að þjónusta það eru 2 Nginx netþjónar + 2 wZD netþjónar notaðir.
Fyrir þá sem ákveða að nota þennan netþjón væri skynsamlegt að skipuleggja möppuskipulagið, ef við á, fyrir notkun. Leyfðu mér að gera fyrirvara strax um að þjóninum sé ekki ætlað að troða öllu inn í 1 Bolt skjalasafn.
Frammistöðupróf:
Því minni sem þjappaða skráin er, því hraðari eru GET og PUT aðgerðir gerðar á henni. Við skulum bera saman heildartímann fyrir ritun HTTP biðlara við venjulegar skrár og Bolt skjalasafn, auk lestrar. Unnið er með skrár af stærðunum 32 KB, 256 KB, 1024 KB, 4096 KB og 32768 KB.
Þegar unnið er með Bolt skjalasafni er gagnaheilleiki hverrar skráar kannaður (CRC er notað), fyrir upptöku og einnig eftir upptöku á sér stað lestur og endurútreikningur á flugi, það leiðir að sjálfsögðu af sér tafir en aðalatriðið er gagnaöryggi.
Ég gerði afkastapróf á SSD drifum, þar sem prófanir á SATA drifum sýna ekki skýran mun.
Gröf byggð á niðurstöðum prófs:
Eins og þú sérð, fyrir litlar skrár er munurinn á les- og skriftíma milli geymdra og ógeymdra skráa lítill.
Við fáum allt aðra mynd þegar við prófum að lesa og skrifa skrár sem eru 32 MB að stærð:
Tímamunur á milli lestrarskráa er innan 5-25 ms. Með upptöku er allt verra, munurinn er um 150 ms. En í þessu tilfelli er engin þörf á að hlaða upp stórum skrám; það er einfaldlega ekkert mál að gera það; þær geta lifað aðskildar frá skjalasafninu.
* Tæknilega séð geturðu notað þennan netþjón fyrir verkefni sem krefjast NoSQL.
Grunnaðferðir til að vinna með wZD miðlara:
Hleður venjulegri skrá:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgAð hlaða upp skrá í Bolt skjalasafnið (ef ekki er farið yfir færibreytu miðlarans fmaxsize, sem ákvarðar hámarks skráarstærð sem hægt er að taka með í skjalasafninu; ef farið er yfir það verður skránni hlaðið upp eins og venjulega við hlið skjalasafnsins):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgAð hlaða niður skrá (ef það eru skrár með sömu nöfnum á disknum og í skjalasafninu, þá er sjálfgefið forgang að skránni sem er ekki í geymslu við niðurhal):
curl -o test.jpg http://localhost/test/test.jpgAð hlaða niður skrá úr Bolt skjalasafninu (þvingað):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgLýsingar á öðrum aðferðum eru í skjölunum.
Miðlarinn styður sem stendur aðeins HTTP samskiptareglur; hún virkar ekki með HTTPS ennþá. POST aðferðin er heldur ekki studd (ekki hefur enn verið ákveðið hvort þörf sé á henni eða ekki).
Sá sem pælir í frumkóðann finnur butterscotch þar, ekki allir eru hrifnir af því, en ég tengdi ekki aðalkóðann við virkni veframmans, nema truflastjórnunina, þannig að í framtíðinni get ég fljótt endurskrifað hann fyrir næstum hvaða vél.
Að gera:
- Þróun eigin afritunar og dreifingaraðila + geo fyrir möguleika á notkun í stórum kerfum án klasaskráarkerfa (Allt fyrir fullorðna)
- Möguleiki á algjörri öfugri endurheimt lýsigagna ef þau glatast alveg (ef dreifingaraðili er notaður)
- Innfædd samskiptareglur fyrir getu til að nota viðvarandi nettengingar og rekla fyrir mismunandi forritunarmál
- Ítarlegir möguleikar til að nota NoSQL íhlutinn
- Þjöppun af mismunandi gerðum (gzip, zstd, snappy) fyrir skrár eða gildi inni í Bolt skjalasafni og fyrir venjulegar skrár
- Dulkóðun af mismunandi gerðum fyrir skrár eða gildi inni í Bolt skjalasafni og fyrir venjulegar skrár
- Seinkuð myndbandsbreyting á miðlara, þar á meðal á GPU
Ég á allt, ég vona að þessi server muni nýtast einhverjum, BSD-3 leyfi, tvöfaldur höfundarréttur, þar sem ef það væri ekkert fyrirtæki þar sem ég vinn, þá hefði þjónninn ekki verið skrifaður. Ég er eini verktaki. Ég væri þakklátur fyrir allar villur og eiginleikabeiðnir sem þú finnur.
Heimild: www.habr.com