:: Melhor maneira de armazenamento de documentos (arquivos)

Estou com um requisito de armazenamento de arquivos (imagens, documentos do word, projetos do Corel, etc) em uma arquitetura que estou desenvolvendo e percebi que, apesar de ser um requisito simples, realmente não conheço uma solução específica para isso e que no final das contas acaba ou no banco de dados ou o sistema de arquivos do SO. Por isso gostaria que vocês compartilhassem suas experiências com esse tipo de requisito, qual caminho escolhido, SO ou SGBD, e se existir uma solução mais inteligente para isso, que eu não conheço, comentarem dela também.

Penso o seguinte:

  1. Sistema de arquivo: É rápido e simples, porém devo montar a estrutura de diretório da solução e criar uma estrutura de backup. Devo manter um apontador no banco a esse arquivo e se o infeliz da administração alterar o nome de uma pasta, FUDEU! :lol: :lol: :lol: :lol:

  2. Banco de dados: É um pouco mais complexo, mas tenho toda a infraestrutura de backup, otimização, etc, oferecida pelo banco de dados, mas, não sei, acredito que tenho todo um overhead de um banco que não preciso, além de ter uma leve impressão, e me corrigam se estiver errado, que arquivos não é bem o tipo de dados que se deve colocar em um banco de dados.

Obrigado.

Veja http://hadoop.apache.org/.

[quote=Hal Jordan]Estou com um requisito de armazenamento de arquivos (imagens, documentos do word, projetos do Corel, etc) em uma arquitetura que estou desenvolvendo e percebi que, apesar de ser um requisito simples, realmente não conheço uma solução específica para isso e que no final das contas acaba ou no banco de dados ou o sistema de arquivos do SO. Por isso gostaria que vocês compartilhassem suas experiências com esse tipo de requisito, qual caminho escolhido, SO ou SGBD, e se existir uma solução mais inteligente para isso, que eu não conheço, comentarem dela também.

Penso o seguinte:

  1. Sistema de arquivo: É rápido e simples, porém devo montar a estrutura de diretório da solução e criar uma estrutura de backup. Devo manter um apontador no banco a esse arquivo e se o infeliz da administração alterar o nome de uma pasta, FUDEU! :lol: :lol: :lol: :lol:

  2. Banco de dados: É um pouco mais complexo, mas tenho toda a infraestrutura de backup, otimização, etc, oferecida pelo banco de dados, mas, não sei, acredito que tenho todo um overhead de um banco que não preciso, além de ter uma leve impressão, e me corrigam se estiver errado, que arquivos não é bem o tipo de dados que se deve colocar em um banco de dados.

Obrigado.[/quote]

Sistema de arquivos é furada. o Esqueme é banco de dados mesmo. Agora, não necessáriamene relacional. Os bancos NoSQL são muito usados para arquivar documentos (vide google docs). Isso levaria a uma solução com dois bancos, um de dados transacionais e outro de arquivo. O backup seria mais fácil deste forma. O Postgress tem um modelo hibrido que permite NoSQL, dê uma olhada se atende. Caso contrário tem que partir para um MongoDb ou coisas do tipo, ai não sei qual seria o melhor.

Sérgio, eu estava começando a pensar em uma solução mista entre um sgbd e um NoSQL, obrigado por validá-la, realmente, ela parece ser a mais ideal.

tveronezi, desculpa minha ignorância, mas não to conseguindo ver como o Hadoop pode me ajudar

Obrigado a todos!

[quote=sergiotaborda][quote=Hal Jordan]Estou com um requisito de armazenamento de arquivos (imagens, documentos do word, projetos do Corel, etc) em uma arquitetura que estou desenvolvendo e percebi que, apesar de ser um requisito simples, realmente não conheço uma solução específica para isso e que no final das contas acaba ou no banco de dados ou o sistema de arquivos do SO. Por isso gostaria que vocês compartilhassem suas experiências com esse tipo de requisito, qual caminho escolhido, SO ou SGBD, e se existir uma solução mais inteligente para isso, que eu não conheço, comentarem dela também.

Penso o seguinte:

  1. Sistema de arquivo: É rápido e simples, porém devo montar a estrutura de diretório da solução e criar uma estrutura de backup. Devo manter um apontador no banco a esse arquivo e se o infeliz da administração alterar o nome de uma pasta, FUDEU! :lol: :lol: :lol: :lol:

  2. Banco de dados: É um pouco mais complexo, mas tenho toda a infraestrutura de backup, otimização, etc, oferecida pelo banco de dados, mas, não sei, acredito que tenho todo um overhead de um banco que não preciso, além de ter uma leve impressão, e me corrigam se estiver errado, que arquivos não é bem o tipo de dados que se deve colocar em um banco de dados.

Obrigado.[/quote]

Sistema de arquivos é furada. o Esqueme é banco de dados mesmo. Agora, não necessáriamene relacional. Os bancos NoSQL são muito usados para arquivar documentos (vide google docs). Isso levaria a uma solução com dois bancos, um de dados transacionais e outro de arquivo. O backup seria mais fácil deste forma. O Postgress tem um modelo hibrido que permite NoSQL, dê uma olhada se atende. Caso contrário tem que partir para um MongoDb ou coisas do tipo, ai não sei qual seria o melhor.[/quote]

Concordo. Já utilizei via sistema de arquivos e via DB, com certeza via DB seria a minha primeira opção! Na época que implementei a solução de usar sistemas de arquivos foi pq os arquivos eram imensos e acabaria comprometendo o desempenho do banco e NoSQL não era uma tecnologia muito divulgada (eu nem conhecia). Arquivos pequenos, mesmo num volume grande, podem ser tranquilamente usados com banco de dados relacionais, principalmente se você tiver uma base legada e uma arquitetura mista não for uma alternativa, mas tudo depende do que você quer!

PS: Só não faz que nem um estagiário que eu trabalhei e que fazia SELECT * from TBL_ARQUIVOS :smiley: HAHAHAHHAHA.

[quote=Hal Jordan]Sérgio, eu estava começando a pensar em uma solução mista entre um sgbd e um NoSQL, obrigado por validá-la, realmente, ela parece ser a mais ideal.

tveronezi, desculpa minha ignorância, mas não to conseguindo ver como o Hadoop pode me ajudar

Obrigado a todos! [/quote]

Hadoop pd ser uma opção pq (simplificando ao máximo) é um sistema de computação distribuida para trabalhar com arquivos em java! Tem umas matérias bem legais sobre ele na na MundoJ do ano passado, só não lembro a edição, e que serve como ponto de partida para iniciar na tecnologia!

Mas como disse antes, tudo depende do que você quer! Hadoop e NoSQL podem ser uma bazuca para matar barata! Tem que avaliar bem o que você deseja e se o DB relacional não é a solução mais simples!

[quote=Hal Jordan]1. Sistema de arquivo: É rápido e simples, porém devo montar a estrutura de diretório da solução e criar uma estrutura de backup. Devo manter um apontador no banco a esse arquivo e se o infeliz da administração alterar o nome de uma pasta, FUDEU! :lol: :lol: :lol: :lol:

  1. Banco de dados: É um pouco mais complexo, mas tenho toda a infraestrutura de backup, otimização, etc, oferecida pelo banco de dados, mas, não sei, acredito que tenho todo um overhead de um banco que não preciso, além de ter uma leve impressão, e me corrigam se estiver errado, que arquivos não é bem o tipo de dados que se deve colocar em um banco de dados.
    [/quote]

Amigo,

Evite soluções mirabolantes.
Vá de sistemas de arquivos. Muito mais simples, de fácil implementação, fácil administração, etc
Bancos de Dados modernos suportam armazenamento de arquivos sem problemas, porém eu prefiro a primeira opção conforme disse acima.
Qualquer outra solução além destas como bancos noSQL eu utilizaria apenas se algum requisito o fizesse necessário…

[quote=bombbr][quote=Hal Jordan]1. Sistema de arquivo: É rápido e simples, porém devo montar a estrutura de diretório da solução e criar uma estrutura de backup. Devo manter um apontador no banco a esse arquivo e se o infeliz da administração alterar o nome de uma pasta, FUDEU! :lol: :lol: :lol: :lol:

  1. Banco de dados: É um pouco mais complexo, mas tenho toda a infraestrutura de backup, otimização, etc, oferecida pelo banco de dados, mas, não sei, acredito que tenho todo um overhead de um banco que não preciso, além de ter uma leve impressão, e me corrigam se estiver errado, que arquivos não é bem o tipo de dados que se deve colocar em um banco de dados.
    [/quote]

Amigo,

Evite soluções mirabolantes.
Vá de sistemas de arquivos. Muito mais simples, de fácil implementação, fácil administração, etc
[/quote]

Isto não é verdade. A administração é um problema. Tem que ter acesso previligiado de write , tem que fazer backup , etc… o banco de dados já cuida disso tudo em um lugar só. Fora que o banco de dados pode ser distribuido e o filesystem não.
Usar NoSQL não é mirabolante. É a prática comum no mercado de hoje. Vide twiter, facebook, google , instangram ,… todos os arquivos estão em nosql.

Pela integridade das informacoes use banco de dados. Se o SGDB tiver o conceito de tablespace, coloque as tabelas com blobs em tablespace separado apontando para outro HD dedicado. Sistemas de arquivos só em ultimo caso ou em hospedagens compartilhadas que limitam o tamanho do banco.

:smiley:

Não sei qual o cenário que você tem, mas uma outra solução também é usar um serviço de armazenamento, tipo Amazon S3.

Se possível, eu recomendo usar o S3 da Amazon Web Services. Eu acredito que é o melhor sistema de storage para arquivos. Outra possibilidade é ter um serviço parecido com o S3 no seu ambiente, eu nunca usei, mas existem alternativas open source que você pode instalar no seu próprio servidor.

Já ouviu falar do Apache Jackrabbit?

[]'s