{"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\/da\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Effektiv opbevaring af hundredvis af millioner sm\u00e5 filer. Selvhostet l\u00f8sning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Effektiv
\n
\nK\u00e6re f\u00e6llesskab, denne artikel vil fokusere p\u00e5 effektiv opbevaring og udlevering af hundredvis af millioner sm\u00e5 filer. P\u00e5 nuv\u00e6rende tidspunkt pr\u00e6senteres der en endelig l\u00f8sning for POSIX-kompatible filsystemer med fuld underst\u00f8ttelse af l\u00e5se, herunder klyngel\u00e5se, og angiveligt uden brug af hurtigfikser.<\/p>\n

Derfor har jeg skrevet min egen specialiserede server til dette form\u00e5l.
\nUnder implementeringen af denne opgave lykkedes det at l\u00f8se det prim\u00e6re problem og samtidig opn\u00e5 besparelser p\u00e5 diskplads og RAM, som vores klyngedrevne filsystem ellers forbrugte ukontrolleret. En s\u00e5dan m\u00e6ngde filer er skadelig for ethvert klyngedrevet filsystem. <\/a><\/noindex><\/p>\n

Id\u00e9en er s\u00e5dan:<\/p>\n

Kort sagt, sm\u00e5 filer uploades via serveren, de gemmes direkte i arkivet og l\u00e6ses ogs\u00e5 derfra, mens store filer placeres ved siden af. Skema: 1 mappe = 1 arkiv, hvilket resulterer i flere millioner arkiver med sm\u00e5 filer i stedet for flere hundrede millioner filer. Og alt dette er implementeret fuldst\u00e6ndigt, uden brug af scripts eller opdeling af filer i tar\/zip-arkiver.<\/p>\n

Jeg vil fors\u00f8ge at v\u00e6re kortfattet, og jeg beklager p\u00e5 forh\u00e5nd, hvis indl\u00e6gget bliver omfangsrigt.<\/p>\n

Det hele startede med, at jeg ikke kunne finde en passende server i verden, der kunne gemme data modtaget via HTTP-protokollen direkte i arkiver, s\u00e5 der ikke ville v\u00e6re ulemper forbundet med almindelige arkiver og objektlagre. \u00c5rsagen til s\u00f8gningen var en oprindelig klynge best\u00e5ende af 10 servere, der voksede sig stor, og som allerede havde samlet 250.000.000 sm\u00e5 filer, og tendensen til v\u00e6kst skulle ikke stoppe.<\/p>\n

Til dem, der ikke kan lide at l\u00e6se artikler, er her en kortere dokumentation:<\/b><\/p>\n

herhen<\/a><\/noindex> og herhen<\/a><\/noindex>.<\/p>\n

Og Docker samtidig, der er i \u00f8jeblikket kun en mulighed for dette med Nginx indeni for sikkerheds skyld:<\/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
\nN\u00e6ste:<\/p>\n
Hvis der er mange filer, kr\u00e6ves der betydelige ressourcer, og det mest frustrerende er, at en del af dem g\u00e5r til spilde. For eksempel, ved brug af et klyngesystem til filh\u00e5ndtering (i dette tilf\u00e6lde - MooseFS), optager en fil, uanset dens faktiske st\u00f8rrelse, altid minimum 64 KB. Det betyder, at for filer p\u00e5 3, 10 eller 30 KB, kr\u00e6ves der stadig 64 KB plads p\u00e5 disken. Hvis der er en kvart milliard filer, mister vi mellem 2 til 10 terabyte. Det vil ikke v\u00e6re muligt uendeligt at oprette nye filer, da der i MooseFS er en gr\u00e6nse: h\u00f8jst 1 milliard med \u00e9n kopi af hver fil.<\/p>\n
Efterh\u00e5nden som antallet af filer stiger, kr\u00e6ves der meget RAM til metadataene. Hyppige store dumps af metadata bidrager ogs\u00e5 til slid p\u00e5 SSD-diskene.<\/p>\n
Server wZD. Vi rydder op p\u00e5 diskene.<\/b><\/p>\n
Serveren er skrevet i Go. F\u00f8rst og fremmest havde jeg brug for at reducere antallet af filer. Hvordan g\u00f8r man det? Ved at arkivere, men i dette tilf\u00e6lde uden kompression, da mine filer er fuldst\u00e6ndig komprimerede billeder. BoltDB kom til hj\u00e6lp, som jeg ogs\u00e5 m\u00e5tte rette nogle mangler ved, hvilket er beskrevet i dokumentationen.<\/p>\n
I alt er der i mit tilf\u00e6lde kun blevet 10 millioner Bolt-arkiver tilbage i stedet for en kvart milliard filer. Hvis jeg havde mulighed for at \u00e6ndre den nuv\u00e6rende struktur for udfyldning af mapper med filer, kunne man m\u00e5ske reducere det til cirka 1 million filer. <\/p>\n
Alle sm\u00e5 filer pakkes i Bolt-arkiver, som f\u00e5r navne automatisk baseret p\u00e5 de mapper, de ligger i, mens alle store filer forbliver t\u00e6t p\u00e5 arkiverne; det giver ikke mening at pakke dem, og det er konfigurerbart. Sm\u00e5 filer arkiveres, store filer forbliver u\u00e6ndrede. Serveren fungerer problemfrit med b\u00e5de typer.<\/p>\n
Arkitektur og funktioner af serveren wZD.<\/b><\/p>\n
\"Effektiv
\n
\nServeren fungerer under styresystemerne Linux, BSD, Solaris og OSX. Jeg har kun testet det for AMD64-arkitekturen under Linux, men det burde ogs\u00e5 fungere for ARM64, PPC64, MIPS64.<\/p>\n
Hovedfunktionerne:<\/b><\/p>\n