Eu só posso responder pelo MongoDB aqui, não vou fingir que sei muito sobre HDFS e outras tecnologias desse tipo.
A implementação do GridFs é totalmente do lado do cliente dentro do próprio driver. Isso significa que não há carregamento especial ou compreensão do contexto de serviço de arquivo dentro do próprio MongoDB, efetivamente o próprio MongoDB nem mesmo entende que são arquivos ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Isso significa que consultar qualquer parte dos
files ou chunks coleta resultará no mesmo processo que faria para qualquer outra consulta, por meio do qual carrega os dados necessários em seu conjunto de trabalho ( http://en.wikipedia.org/wiki/Working_set ) que representa um conjunto de dados (ou todos dados carregados naquele momento) exigidos pelo MongoDB dentro de um determinado período de tempo para manter o desempenho ideal. Ele faz isso paginando-o na RAM (bem, tecnicamente, o sistema operacional faz). Outro ponto a ser levado em consideração é que este é um driver implementado. Isso significa que a especificação pode variar, no entanto, acho que não. Todos os drivers permitirão que você consulte um conjunto de documentos dos
files coleção que hospeda apenas os metadados dos arquivos, permitindo que você sirva posteriormente o próprio arquivo a partir dos chunks coleção com uma única consulta. No entanto, isso não é importante, você deseja servir o arquivo em si, incluindo seus dados; isso significa que você estará carregando os
files coleção e seus chunks subsequentes coleção em seu conjunto de trabalho. Com isso em mente, já chegamos ao primeiro obstáculo:
Os arquivos do gridfs serão armazenados em cache na ram e como isso afetará o desempenho de leitura e gravação?
O desempenho de leitura de arquivos pequenos pode ser incrível, diretamente da RAM; as gravações seriam tão boas.
Para arquivos maiores, não. A maioria dos computadores não terá 600 GB de RAM e é bastante normal, na verdade, abrigar uma partição de 600 GB de um único arquivo em um único
mongod instância. Isso cria um problema, pois esse arquivo, para ser servido, precisa caber em seu conjunto de trabalho, mas é impossivelmente maior que sua RAM; neste ponto, você pode ter página thrashing ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) em que o servidor está apenas com falha de página 24 horas por dia, 7 dias por semana, tentando carregar o arquivo. As gravações aqui também não são melhores. A única maneira de contornar isso é começar a colocar um único arquivo em vários fragmentos
:\ . Nota:mais uma coisa a considerar é que o tamanho médio padrão de um
chunks "chunk" é 256 KB, então são muitos documentos para um arquivo de 600 GB. Essa configuração é manipulável na maioria dos drivers.
O que acontecerá com o gridfs quando eu tentar escrever alguns arquivos simultaneamente. Haverá algum bloqueio para operações de leitura/gravação? (Vou usá-lo apenas como armazenamento de arquivos)
O GridFS, sendo apenas uma especificação, usa os mesmos bloqueios de qualquer outra coleção, tanto para leitura quanto para gravação em nível de banco de dados (2.2+) ou em nível global (pré-2.2). Os dois interferem um no outro também, ou seja, como você pode garantir uma leitura consistente de um documento que está sendo gravado?
Dito isto, existe a possibilidade de contenção com base nas especificidades do seu cenário, tráfego, número de gravações/leituras simultâneas e muitas outras coisas sobre as quais não temos ideia.
Talvez existam outras soluções que possam resolver meu problema de forma mais eficiente?
Eu pessoalmente descobri que o S3 (como @mluggy disse) em formato de redundância reduzida funciona melhor armazenando uma mera porção de metadados sobre o arquivo dentro do MongoDB, assim como usar o GridFS, mas sem a coleção de pedaços, deixe o S3 lidar com toda essa distribuição, backup e outras coisas para você.
Espero ter sido claro, espero ter ajudado.
Edit:Ao contrário do que eu disse acidentalmente, o MongoDB não possui um bloqueio de nível de coleção, é um bloqueio de nível de banco de dados.
