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


86

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?


1
Uma postagem do blog sobre como armazenar imagens em mongodb para futuros pesquisadores que tinham uma intenção semelhante a mim: menge.io/2015/03/24/storing-small-images-in-mongodb (compara GridFS com simplesmente jogá-lo no documento como binário data)

Existem muitas compensações a serem consideradas ao decidir se você deseja armazenar dados binários no MongoDB - consulte: alexmarquardt.com/2017/03/02/…
Alexander Marquardt

Respostas:


118

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.


9
Estou chocado que alguém usaria o raid 0 como armazenamento primário em um site de produção. Mesmo com bons backups, aumentar a probabilidade de falha de armazenamento é um preço muito alto a pagar por um desempenho aprimorado.
mikerobi

67
Usamos raid 0 porque, em nosso caso particular, os dados da imagem podem ser voláteis. Não importa se a imagem for perdida, pois faremos o download novamente do site do comerciante. Pragmaticamente, podemos considerar que nosso servidor é um simples servidor de cache de imagens.
Manu Eidenberger

Mas você está aumentando ativamente a chance de falha (fator de falha da unidade inicial multiplicado pelo número de eixos). O Raid 10 seria ideal se você precisar de mais gravações do que leituras ou o Raid 5/6 se você precisar de mais leituras do que gravações.
NeuroScr

9
@ManuEidenberger Por que você está usando o GridFS para armazenar imagens que prefeririam ser armazenadas em um documento MongoDB? Acho que você não atingiu o limite de tamanho de documento de 16 MB. E armazenar a imagem como BLOB em um documento MongoDB seria mais eficiente, já que você não precisa da camada GridFS sobre os documentos MongoDB.
Arnaud Bouchez

1
Também estou curioso sobre a pergunta de @ArnaudBouchez. Houve algum benefício que fez você escolher o GridFS em vez de simplesmente armazená-lo como dados binários em um documento, Manu? Obrigado!

12

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ó.


6

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.


Então, como você foi?
Mukus 01 de

5

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.


3
paint.ly não está mais disponível, ao que parece. :(
Marian

2

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.


4
Sou bastante novo no GridFS, embora, pelo que entendi, o GridFS seja mais do que apenas uma camada de abstração que dobra o número de arquivos. O GridFS oferece uma maneira simples de aproveitar as vantagens dos recursos de replicação e fragmentação do MongoDB. Acredito que outros também mencionaram que os arquivos são armazenados em blocos de 2 GB, o que imagino que reduziria o número total de arquivos, especialmente se alguém tiver uma grande quantidade de imagens pequenas.

+1 Você está certo. Mesmo arquivos menores não se beneficiariam em serem armazenados com GridFS. Se o seu arquivo pudesse ser armazenado em um documento MongoDB (ou seja, <de seu limite de tamanho de 16 MB), você prefere armazenar o arquivo como um BLOB dentro de um documento MongoDB. Ele contornará a sobrecarga de uso do GridFS no topo do armazenamento do MongoDB. Veja compose.io/articles/gridfs-and-mongodb-pros-and-cons
Arnaud Bouchez
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.