[firebase-br] Banco de dados de Imagens

[Francis Lay Silva]

Olá Gladiston, eu entendi sua colocação. Mas no meu caso é um pouco
diferente porque trata-se de imagens para serem impressas no jornal, então
devem ser arquivadas com altíssima qualidade, imagens com a média de 10Mb
cada. E no meu caso quando busco por uma imagem eu jogo um texto como
"Dilma Rousseff" e o sistema precisa exibir em um mural (tipo a pesquisa do
Google imagens) todas as imagens encontradas em um período para que possam
ser selecionadas uma ou mais para o editor decidir depois qual a melhor.
Nessa situação, mesmo eu tendo uma tabela separada só com miniaturas o
acesso mesmo assim era muito lento devido os registros das tabelas estarem
extremamente fragmentados no hd devido às imagens maiores arquivadas na
outra tabela.
Mas minha situação é um pouco diferente da sua, é mais de 1 década de
fotografias arquivadas, milhares de fotos e quase 1 tera só o banco de
imagens.
Quanto a fotos duplicadas na pasta externa no hd não tem o risco de
ocorrer, e nem ponteiros perdidos, porque como mencionei apenas o meu
sistema instalado no servidor tem acesso a essa pasta, e ele controla e
renomeia os arquivos de forma a evitar isso. Ninguém adiciona, obtém ou
exclui uma foto se não for via sistema, e ele é capaz de identificar quando
uma foto veio do arquivamento e está voltando com um nome diferente.
Mas de qualquer forma fica só a sugestão, a melhor maneira vai depender de
cada aplicação.

Um abraço a todos.
Em 14/10/2015 15:48, "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
>