O GridFS é rápido e confiável o suficiente para a produção?

Eu desenvolvo um novo site e quero usar o GridFS como armazenamento para todos os uploads do usuário, porque oferece muitas vantagens em comparação com um armazenamento de sistema de arquivos normal.

Benchmarks com GridFS servido por nginx indicam que não é tão rápido quanto um sistema de arquivos normal servido por nginx.

Referência com nginx

Alguém aí usa o GridFS já em um ambiente de produção ou o usaria para um novo projeto?

Eu uso o gridfs no trabalho em um de nossos servidores, que faz parte de um site de comparação de preços com estatísticas de tráfego honrosas (cerca de 25 mil visitantes por dia). O servidor não tem muita ram, 2gigs, e até mesmo a cpu não é muito rápida (Core 2 duo 1.8Ghz), mas o servidor tem bastante espaço de armazenamento: 10Tb (sata) na configuração raid 0. O trabalho que o servidor está fazendo é muito simples:

Cada produto em nosso comparador de preços tem uma imagem (há cerca de 10 milhões de produtos de acordo com nosso banco de dados de produto), e o trabalho dos servidores é baixar a imagem, redimensioná-la, armazená-la no gridfs e entregá-la ao navegador do visitante. .. se não estiver presente na grade ... ou ... entregue ao navegador do visitante se já estiver armazenado na grade. Portanto, isso poderia ser chamado de 'esquema cdn tradicional'.

Armazenamos e processamos 4 milhões de imagens neste servidor desde que ele está instalado e funcionando. O redimensionamento e armazenamento são feitos por um script php simples ... mas com certeza, um script python ou algo como java poderia ser mais rápido.

Tamanho de dados atual: 11,23g

Tamanho de armazenamento atual: 12,5g

Índices: 5

Tamanho do índice: 849,65 m

Sobre a confiabilidade: Isso é muito confiável. O servidor não carrega, o tamanho do índice está ok, as consultas são rápidas

Sobre a velocidade: Com certeza, não é rápido como o armazenamento local de arquivos, talvez 10% mais lento, mas rápido o suficiente para ser usado em tempo real mesmo quando a imagem precisa ser processada, o que no nosso caso é muito dependente do php. Os tempos de manutenção e desenvolvimento também foram reduzidos: ficou muito simples excluir uma ou várias imagens: basta consultar o banco de dados com um simples comando de exclusão. Outra coisa interessante: quando reinicializamos nosso servidor antigo, com armazenamento local de arquivos (tantos milhões de arquivos em milhares de pastas), às vezes ele trava por horas porque o sistema estava realizando uma verificação de integridade de arquivos (isso realmente levou horas ...). Não temos mais esse problema com o gridfs, nossas imagens agora são armazenadas em grandes blocos mongodb (arquivos 2gb)

Então ... na minha cabeça ... Sim, o gridfs é rápido e confiável o suficiente para ser usado na produção.

Como mencionei, pode não ser tão rápido quanto um sistema de arquivos comum, mas dá a você muitas vantagens sobre os sistemas de arquivos comuns, e acho que vale a pena abrir mão de um pouco de velocidade.

No final das contas, com o sharding, você pode chegar a um ponto onde o armazenamento GridFS realmente se torna a opção mais rápida em oposição a um sistema de arquivos comum e um único nó.

No entanto, avisamos sobre os reparos para bancos de dados maiores - um novo sistema que estamos desenvolvendo, o mongo não foi encerrado de forma limpa e o reparo do GridFS de 7 TB parece que levará 130 horas.

Por causa disso, acho que vou tentar mudar para OpenStack Swift ou Ceph. Mesmo assim, até então estava bom. E o módulo nginx-gridfs é ótimo.

O módulo nginx-gridfs do mdirolf é ótimo e bastante fácil de configurar. Estamos usando-o na produção da paint.ly para atender a todas as pinturas e não houve problemas até agora.

Eu não recomendo usar o gridfs a menos que você saiba o que está fazendo. GridFS é apenas uma camada de abstração que divide os arquivos em pedaços e os armazena em duas coleções. Mais arquivos - mais sobrecarga. Se você espera que os arquivos tenham praticamente o mesmo tamanho, não excedendo 32 MB ou mais - você está no caminho certo. Não tente armazenar arquivos grandes em gridfs. Por quê?

1. Drivers em idiomas diferentes podem ler o arquivo inteiro (por exemplo, pedaços) ao ler uma pequena parte do arquivo.
2. Modificar o arquivo pode afetar todos os fragmentos e aumentar a carga do banco de dados. Se o seu sistema de arquivos estiver crescendo, você terá que decidir fragmentar os gridfs. Seja cuidadoso! A consistência não é garantida quando a fragmentação está inicializando!

Se você pensar em ler o projeto carregado - considere carregar os arquivos diretamente no docs (se o tamanho for 16M ou menos) ou escolha outro clusterfs e vincule o nome do arquivo / inode à sua lógica.

Espero que isto ajude.