[firebase-br] Banco de dados de Imagens

[Gladiston Santana]

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.