[firebase-br] Banco de dados de Imagens

[Fábio P. Santos]

Obrigado pelas opiniões, concordo que o ambiente pode influenciar na tomada
de decisão, no meu caso vou ter de permanecer com as imagens no banco por
questões de força de contrato, quanto a performance já fiz alguns testes
nas aplicações cliente e o tempo de reposta é muito rápido, agora concordo
com o Gladiston de colocar as imagens em um outro banco.....

Agora conforme o Francis bem diz,,, o problema vai ser o backup de um banco
do 300 MB ou mais.....

Novamente, obrigado a todos pela atenção....

Em 14 de outubro de 2015 16:45, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Olá  Francis, entendi seu esquema de backup e tals, muito melhor ter
> esquema de backup diferencial para dados e imagens, especialmente quando as
> imagens nunca se alteram. Um robocopy da vida sincroniza em 1s o que o gbak
> talvez fizesse em 45min.
> Mas no que se refere a performance das imagens dentro do banco de dados eu
> não posso concordar contigo.
> Tenho um sistema de catalogação de arquivos que salva arquivos de qualquer
> tipo para campos blobs e funciona bem em delphi e também em php e os testes
> preliminares (isso faz 5 anos) indicavam que seriam mais lentos porque o
> servidor em questão não seria dimensionado para ser um file server.
> Mas o que você faz não está errado, sob as condições certas teu esquema
> abriria mão da segunda em prol da performance.
> Por exemplo, o Microsoft SQL Server tem um recurso chamado filestream que
> serve justamente para isso que tu faz, só que é transparente para o app que
> usa comandos SQL para salvar as imagens no banco, quando na realidade o
> banco de dados está salvando um ponteiro para o arquivo no disco - algo que
> embora não seja nativo do FB é perfeitamente possível de se fazer. Mas prá
> que engenheiros criaram isso? Quando vários nomes de arquivos se repetem,
> considera-se que seja o mesmo conteúdo e daí ocupam espaço uma unica vez no
> disco e assim aumenta a indiretamente a performance e o espaço livre do
> disco. Além disso sob alguns tipos de sistema de arquivos, arquivos mesmo
> com nomes diferentes, porém com conteúdo duplicado se tornam ponteiros para
> o mesmo arquivo (similar a links simbólicos) e com isso obtem desenpenho.
> Alguns NAS como os da EMC tem esse recurso, assim como também brtfs no
> Linux onde com um único comando, conteúdo duplicado somam espaço uma unica
> vez e quando um desses arquivos duplicados são alterados então se
> autodesvinculam de seu ponteiro. Da maneira tradicional esse conteúdo blob
> seria duplicado varias vezes no banco de dados, causando não o problema de
> lentidão, mas o disperdicio de espaço.
>
> O que eu quero dizer é que você não pode dizer que X é melhor que Y porque
> o ambiente pode mudar.
> Para mim, guardar imagens num banco trouxe segurança sem abdicar de
> performance. Mas eu mudaria de idéia se o cenário fosse diferente.
>
> Um forte abraço.
>
>
>
>
>
> Em 13 de outubro de 2015 20:00, Francis Lay Silva <fllsilva8 em gmail.com>
> escreveu:
>
> > Eu lhe recomendaria fortemente mudar essa sua estratégia de
> armazenamento.
> >
> > Eu trabalho em um jornal e aqui temos um arquivamento de fotos bem
> pesado.
> > A principio implementei o sistema em cima do banco de dados Oracle que é
> > bem mais robusto que o FB. As fotos eram todas arquivadas em uma tabela
> no
> > próprio banco de dados.
> >
> > Após pouco mais de 1 ano os problemas começaram a surgir. Quando eu
> buscava
> > uma informação referente a pesquisa de um conjunto de fotos qualquer, os
> > dados em texto dela eram recuperados rapidamente, mas quando era preciso
> > linkar os dados com as imagens (para exibir em um browse de fotos para
> > seleção) era um pesadelo. Devido aos grandes tamanhos das fotos o hd do
> > servidor trabalhava feito louco movendo o ponteiro dos registros de
> imagem
> > de um lado pro outro. Chegou uma hora que a aplicação de tornou
> improdutiva
> > e começavam a guardar imagens recentes no HDD local. Então tive que
> mudar a
> > estratégia e consegui resolver o problema.
> >
> > Minha dica para você, independente do BD que for usar, é armazenar as
> > imagens em uma pasta segura na rede, onde os usuários não tenham acesso
> > direto a ela. Dessa forma você armazenaria no BD apenas uma referência
> para
> > a localização da imagem.
> >
> > Minha aplicação já roda a 5 anos agora é nunca mais tive problemas com
> ela.
> > Isso facilitou e muito também o backup do BD que antes levava horas para
> > fazer e ocupava vários gigas cada. Hoje o backup das informações apenas
> não
> > chega a ocupar nem 300Mb. Quanto às fotos, faço apenas uma sincronização
> > delas com um HDD externo de backup, e pára isso utilizo software gratuito
> > que consegui na internet.
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>