{"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\/sv\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Effektiv lagring av hundratals miljoner sm\u00e5 filer. Sj\u00e4lvhostad l\u00f6sning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Effektiv
\n
\nB\u00e4sta community, denna artikel kommer att handla om effektiv lagring och hantering av hundratals miljoner sm\u00e5 filer. F\u00f6r n\u00e4rvarande presenteras en slutgiltig l\u00f6sning f\u00f6r POSIX-kompatibla filsystem med fullst\u00e4ndig st\u00f6d f\u00f6r l\u00e5sningar, inklusive klusterl\u00e5sningar, och verkar till och med vara utan tillf\u00e4lliga l\u00f6sningar.<\/p>\n

D\u00e4rf\u00f6r har jag skrivit en egen specialiserad server f\u00f6r detta \u00e4ndam\u00e5l.
\nUnder implementeringen av denna uppgift lyckades vi l\u00f6sa det grundl\u00e4ggande problemet och samtidigt uppn\u00e5 en betydande besparing i diskutrymme och RAM, som v\u00e5r klusterfilsystem slukade. En s\u00e5dan m\u00e4ngd filer \u00e4r skadlig f\u00f6r vilket klusterfilsystem som helst. <\/a><\/noindex><\/p>\n

Id\u00e9n \u00e4r enkel:<\/p>\n

Med andra ord, sm\u00e5 filer laddas upp via servern, de sparas direkt i ett arkiv och l\u00e4ses ocks\u00e5 d\u00e4rifr\u00e5n, medan stora filer placeras bredvid. Schema: 1 mapp = 1 arkiv, vilket ger oss flera miljoner arkiv med sm\u00e5 filer, ist\u00e4llet f\u00f6r flera hundra miljoner filer. Och allt \u00e4r fullt genomf\u00f6rt utan skript och utan att sprida filer i tar\/zip-arkiv.<\/p>\n

Jag ska f\u00f6rs\u00f6ka sammanfatta det kort, jag ber om urs\u00e4kt p\u00e5 f\u00f6rhand om inl\u00e4gget blir omfattande.<\/p>\n

Allt b\u00f6rjade med att jag inte kunde hitta en l\u00e4mplig server i v\u00e4rlden som kunde spara data som mottagits via HTTP-protokollet direkt i arkiv, utan bristerna som k\u00e4nnetecknar vanliga arkiv och objektlager. Anledningen till s\u00f6kandet var den v\u00e4xande Origin-klustret med 10 servrar, d\u00e4r det redan hade samlats 250 000 000 sm\u00e5 filer, och v\u00e4xttrenden s\u00e5g inte ut att avta.<\/p>\n

F\u00f6r dem som inte gillar att l\u00e4sa artiklar och f\u00f6redrar kortare dokumentation:<\/b><\/p>\n

hit<\/a><\/noindex> och hit<\/a><\/noindex>.<\/p>\n

Och docker samtidigt, just nu finns det bara ett alternativ med nginx inuti f\u00f6r s\u00e4kerhets skull:<\/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\u00e4sta:<\/p>\n
Om antalet filer \u00e4r mycket stort kr\u00e4vs betydande resurser, och det mest frustrerande \u00e4r att en del av dem g\u00e5r till spillo. Till exempel, vid anv\u00e4ndning av ett klusterfilssystem (i det h\u00e4r fallet \u2013 MooseFS), upptar en fil, oavsett dess faktiska storlek, alltid minst 64 KB. Det inneb\u00e4r att f\u00f6r filer med storlekar p\u00e5 3, 10 eller 30 KB kr\u00e4vs 64 KB p\u00e5 disken. Om det finns en kvarts miljard filer, f\u00f6rlorar vi mellan 2 och 10 terabyte. Det \u00e4r inte m\u00f6jligt att skapa nya filer i o\u00e4ndlighet, eftersom MooseFS har en begr\u00e4nsning: h\u00f6gst 1 miljard med en replik av varje fil.<\/p>\n
Allt eftersom antalet filer \u00f6kar, beh\u00f6vs mycket RAM f\u00f6r metadata. Dessutom bidrar frekventa stora dumpningar av metadata till slitage p\u00e5 SSD-lagringsenheter.<\/p>\n
Server wZD. Vi ordnar upp p\u00e5 diskarna.<\/b><\/p>\n
Servern \u00e4r skriven i Go. F\u00f6rst och fr\u00e4mst beh\u00f6vde jag minska antalet filer. Hur g\u00f6r man detta? Genom att arkivera, men i detta fall utan kompression, eftersom mina filer \u00e4r en serie av komprimerade bilder. Till min hj\u00e4lp kom BoltDB, \u00e4ven om jag var tvungen att \u00e5tg\u00e4rda vissa brister, vilket \u00e4r dokumenterat.<\/p>\n
Ist\u00e4llet f\u00f6r en kvarts miljard filer kvarst\u00e5r det bara 10 miljoner Bolt-arkiv i mitt fall. Om jag haft m\u00f6jlighet att \u00e4ndra den nuvarande filstrukturen f\u00f6r katalogerna, skulle det kanske ha kunnat minskas till ungef\u00e4r 1 miljon filer. <\/p>\n
Alla sm\u00e5filer packas i Bolt-arkiv, som automatiskt f\u00e5r namn efter de kataloger d\u00e4r de ligger, medan alla stora filer f\u00f6rblir i n\u00e4rheten av arkiven; det \u00e4r meningsl\u00f6st att paketera dem, detta \u00e4r konfigurerbart. Sm\u00e5 \u2013 arkivera, stora \u2013 l\u00e4mna of\u00f6r\u00e4ndrade. Servern fungerar transparent f\u00f6r b\u00e5de och.<\/p>\n
Arkitekturen och egenskaperna hos servern wZD.<\/b><\/p>\n
\"Effektiv
\n
\nServern k\u00f6rs under operativsystemen Linux, BSD, Solaris och OSX. Jag har testat endast f\u00f6r AMD64-arkitektur under Linux, men den b\u00f6r ocks\u00e5 fungera f\u00f6r ARM64, PPC64, MIPS64.<\/p>\n
Huvudfunktioner:<\/b><\/p>\n