{"id":55408,"date":"2020-01-20T00:00:00","date_gmt":"2020-01-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie"},"modified":"2020-02-18T14:03:31","modified_gmt":"2020-02-18T11:03:31","slug":"effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Efektiivne kui sadade miljonite v\u00e4ikeste failide salvestamine. Isehostitud lahendus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Efektiivne
\n
\nAustatud kogukond, see artikkel k\u00e4sitleb sadade miljonite v\u00e4ikeste failide efektiivset salvestamist ja edastamist. K\u00e4esoleval etapil pakutakse t\u00e4ielikku lahendust POSIX \u00fchilduvatele failis\u00fcsteemidele, mis toetavad t\u00e4ielikult lukustusi, sealhulgas klastrite lukustusi, ja n\u00e4ib, et isegi ilma igasuguste lahendusteta.<\/p>\n

Seet\u00f5ttu kirjutasin selle eesm\u00e4rgi saavutamiseks enda spetsialiseeritud serveri.
\nSelle \u00fclesande t\u00e4itmise k\u00e4igus \u00f5nnestus lahendada peamine probleem ning samal ajal saavutada diskruumi ja RAM-i kokkuhoid, mida meie klastrifailis\u00fcsteem oli \u00e4\u00e4rmiselt palju kasutanud. T\u00f5epoolest, selline failide hulk on kahjulik igasugusele klastrifailis\u00fcsteemile. <\/a><\/noindex><\/p>\n

Kava on j\u00e4rgmine:<\/p>\n

Lihtsate s\u00f5nadega, laaditakse serverisse v\u00e4ikesed failid, mis salvestatakse otse arhiivi ja loetakse sealt samuti, suuremad failid paigutatakse k\u00f5rvale. Skeem: 1 kaust = 1 arhiiv, kokku on meil mitmiljonite v\u00e4ikeste failidega arhiive, mitte sadu miljonite faile. Ja k\u00f5ik see on korralikult teostatud, ilma igasuguste skriptide ja failide jaotamiseta tar\/zip arhiividesse.<\/p>\n

P\u00fc\u00fcan l\u00fchidalt v\u00e4ljendada, vabandan ette, kui postitus osutub tihedaks.<\/p>\n

K\u00f5ik algas sellest, et ma ei suutnud leida sobivat serverit, mis suudaks salvestada andmeid, mis saadakse HTTP protokolli kaudu otse arhiividesse, nii et ei ilmneks tavaliste arhiivide ja objektide hoidlate puudusi. Otsingute p\u00f5hjuseks sai ulatuslik Origin klaster, mis koosnes 10 serverist ja milles oli juba 250 000 000 v\u00e4ikest faili, ning kasvutrend ei paistnud peatuvat.<\/p>\n

Neile, kes ei armasta artiklite lugemist ja eelistavad l\u00fchemat dokumentatsiooni:<\/b><\/p>\n

siia<\/a><\/noindex> ja siia<\/a><\/noindex>.<\/p>\n

Ja docker koos, praegu on variant ainult nginxiga sees, igaks juhuks:<\/p>\n

docker run -d --restart=always -e host=localhost -e root=\/var\/storage \n-v \/var\/storage:\/var\/storage --name wzd -p 80:80 eltaline\/wzd<\/code><\/pre>\n
\nEdasi:<\/p>\n
Kui faile on v\u00e4ga palju, on vajalikud suured ressursid, ja mis veelgi h\u00e4irivam, osa neist kaob raisku. N\u00e4iteks klasterfailis\u00fcsteemi (antud juhul \u2014 MooseFS) kasutamisel v\u00f5tab fail, s\u00f5ltumata tegelikust suurusest, alati v\u00e4hemalt 64 KB. See t\u00e4hendab, et 3, 10 v\u00f5i 30 KB suuruste failide jaoks on kettal vajalik 64 KB. Kui faile on veerand miljardit, kaotame 2 kuni 10 terabaiti. Uute failide l\u00f5putu loomine ei \u00f5nnestu, kuna MooseFS-is on piirang: mitte rohkem kui 1 miljard \u00fche faili repliiki.<\/p>\n
Failide arvu suurenedes on metainfo jaoks vajalik palju RAM-i. Samuti soodustavad tihedad suured metainfotuhandid SSD-kettaste kulumist.<\/p>\n
Server wZD. Teeme kettad korda.<\/b><\/p>\n
Server on kirjutatud Go keeles. Ennek\u00f5ike pidin v\u00e4hendama failide arvu. Kuidas seda teha? Arhiveerimise kaudu, kuid antud juhul ilma kompresseerimiseta, kuna mul on failid, mis on pidevalt kokku surutud pildid. Abiks tuli BoltDB, millel tuli veel puudusi k\u00f5rvaldada, mis kajastub dokumentatsioonis.<\/p>\n
Kokkuv\u00f5ttes on mul alles vaid 10 miljonit Bolt arhiivi, kuigi algselt oli neid veerand miljardit. Kui oleks v\u00f5imalik muuta praegust direktorite failistruktuuri, oleks v\u00f5imalik v\u00e4hendada nende arvu umbes miljoni faili peale. <\/p>\n
K\u00f5ik v\u00e4iksed failid pakitakse Bolt arhiividesse, mis automaatselt saavad direktorite nimed, milles nad asuvad, samas kui k\u00f5ik suured failid j\u00e4\u00e4vad arhivide k\u00f5rvale, neid pole m\u00f5tet pakkida, seda saab seadistada. V\u00e4ikesed \u2014 arhiveerime, suured \u2014 j\u00e4tame muutumatuks. Server t\u00f6\u00f6tab sujuvalt nii nende kui ka teistega.<\/p>\n
wZD serveri arhitektuur ja omadused.<\/b><\/p>\n
\"Efektiivne
\n
\nServer t\u00f6\u00f6tab operatsioonis\u00fcsteemide Linux, BSD, Solaris ja OSX all. Olen testinud ainult AMD64 arhitektuuri Linuxis, kuid see peaks olema sobiv ka ARM64, PPC64, MIPS64 jaoks.<\/p>\n
Peamised omadused:<\/b><\/p>\n