{"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\/pt\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Armazenamento eficiente de centenas de milh\u00f5es de pequenos arquivos. Solu\u00e7\u00e3o Self-Hosted","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Armazenamento
\n
\nPrezada comunidade, este artigo ser\u00e1 dedicado ao armazenamento e \u00e0 entrega eficientes de centenas de milh\u00f5es de pequenos arquivos. Neste est\u00e1gio, apresentamos uma solu\u00e7\u00e3o final para sistemas de arquivos compat\u00edveis com POSIX, com suporte completo a bloqueios, incluindo cluster, e parece que at\u00e9 mesmo sem gambiarras.<\/p>\n

Por isso, para esse fim, escrevi meu pr\u00f3prio servidor especializado.
\nAo longo da implementa\u00e7\u00e3o dessa tarefa, consegui resolver o problema principal, ao mesmo tempo que economizei espa\u00e7o em disco e mem\u00f3ria RAM, que nossa sistema de arquivos de cluster consumia desenfreadamente. Tal quantidade de arquivos \u00e9 prejudicial para qualquer sistema de arquivos de cluster. <\/a><\/noindex><\/p>\n

A ideia \u00e9 a seguinte:<\/p>\n

De forma simples, por meio do servidor, pequenos arquivos s\u00e3o carregados, s\u00e3o salvos diretamente em um arquivo de arquivamento, e assim tamb\u00e9m s\u00e3o lidos dele, enquanto arquivos grandes s\u00e3o armazenados ao lado. Esquema: 1 pasta = 1 arquivo de arquivamento, resultando em v\u00e1rios milh\u00f5es de arquivos de arquivamento com pequenos arquivos, em vez de v\u00e1rias centenas de milh\u00f5es de arquivos. E tudo isso \u00e9 implementado de forma completa, sem quaisquer scripts e sem a distribui\u00e7\u00e3o de arquivos em arquivos tar\/zip.<\/p>\n

Tentarei ser breve, pe\u00e7o desculpas antecipadamente se o post for extenso.<\/p>\n

Tudo come\u00e7ou porque n\u00e3o consegui encontrar um servidor adequado que pudesse armazenar dados recebidos via protocolo HTTP diretamente em arquivos de arquivamento, de modo que n\u00e3o houvesse as desvantagens t\u00edpicas dos arquivos de arquivamento comuns e dos armazenamentos de objetos. O motivo da busca foi o Origin, um cluster que cresceu para grandes propor\u00e7\u00f5es com 10 servidores, que j\u00e1 acumulou 250.000.000 pequenos arquivos, e a tend\u00eancia de crescimento n\u00e3o parecia ter fim.<\/p>\n

Para aqueles que n\u00e3o gostam de ler artigos e preferem uma documenta\u00e7\u00e3o mais simples:<\/b><\/p>\n

aqui<\/a><\/noindex> e aqui<\/a><\/noindex>.<\/p>\n

E docker junto, atualmente h\u00e1 a op\u00e7\u00e3o apenas com nginx dentro, por precau\u00e7\u00e3o:<\/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
\nPr\u00f3ximo:<\/p>\n
Se houver muitos arquivos, s\u00e3o necess\u00e1rios recursos significativos e, o mais frustrante, parte deles \u00e9 desperdi\u00e7ada. Por exemplo, ao usar um sistema de arquivos em cluster (neste caso, o MooseFS), cada arquivo, independentemente do tamanho real, ocupa sempre no m\u00ednimo 64 KB. Ou seja, para arquivos de 3, 10 ou 30 KB, no disco, cada um requer 64 KB. Se houver um quarto de bilh\u00e3o de arquivos, perdemos entre 2 a 10 terabytes. N\u00e3o conseguiremos criar novos arquivos indefinidamente, pois no MooseFS h\u00e1 uma limita\u00e7\u00e3o: n\u00e3o mais de 1 bilh\u00e3o, com uma r\u00e9plica de cada arquivo.<\/p>\n
\u00c0 medida que o n\u00famero de arquivos aumenta, \u00e9 necess\u00e1ria uma grande quantidade de mem\u00f3ria RAM para os metadados. Al\u00e9m disso, grandes dumps de metadados frequentes aceleram o desgaste dos SSDs.<\/p>\n
Servidor wZD. Organizando os discos.<\/b><\/p>\n
O servidor \u00e9 escrito na linguagem Go. Antes de tudo, eu precisava reduzir a quantidade de arquivos. Como fazer isso? Atrav\u00e9s da arquiva\u00e7\u00e3o, mas neste caso sem compress\u00e3o, pois meus arquivos s\u00e3o apenas imagens comprimidas. O BoltDB foi \u00fatil, embora eu tivesse que corrigir algumas defici\u00eancias, o que est\u00e1 refletido na documenta\u00e7\u00e3o.<\/p>\n
Assim, em vez de um quarto de bilh\u00e3o de arquivos, fiquei apenas com 10 milh\u00f5es de arquivos Bolt. Se eu tivesse a oportunidade de mudar a estrutura atual de preenchimento de diret\u00f3rios com arquivos, poderia reduzir para cerca de 1 milh\u00e3o de arquivos. <\/p>\n
Todos os pequenos arquivos s\u00e3o empacotados em arquivos Bolt, que automaticamente recebem os nomes das pastas em que est\u00e3o, enquanto todos os arquivos grandes permanecem pr\u00f3ximos aos arquivos, pois n\u00e3o h\u00e1 sentido em empacot\u00e1-los, isso \u00e9 personaliz\u00e1vel. Arquivamos os pequenos e deixamos os grandes inalterados. O servidor funciona de forma transparente com ambos.<\/p>\n
Arquitetura e caracter\u00edsticas do servidor wZD.<\/b><\/p>\n
\"Armazenamento
\n
\nO servidor funciona sob os sistemas operacionais Linux, BSD, Solaris e OSX. Eu testei apenas para a arquitetura AMD64 sob Linux, mas ele deve funcionar tamb\u00e9m para ARM64, PPC64, MIPS64.<\/p>\n
Principais caracter\u00edsticas:<\/b><\/p>\n