[OT] immagini memorizzate nel database

[fm]

...tecnica che non ho mai usato
(utilizzo sempre link a file esterno al db).


Attualmente vedo la Canistracci srl ( di livello tecnico IMO non elevato)
incontrare svariati problemi nell'inserimento/aggiornamento di immagini nel
db.

Riferendosi a siti di e-commerce aziendali (no sitarello della pizzeria),
... pro e contro di questa metodologia?

Vs esperienze?


TIA


ciao
fm

[rootkit]

Il Wed, 08 May 2013 05:21:12 +0200, fm ha scritto:


> Riferendosi a siti di e-commerce aziendali (no sitarello della
> pizzeria), ... pro e contro di questa metodologia?

pro: ricerca/indicizzazione, performance sui grandi numeri, replicazione
e alta disponibilità in base alle caratteristiche del database.
contro: maggiori difficoltà a gestirli a mano.

[nicholas...@gmail.com]

Ricerca e indicizzazione penso sia sui metadati, non sulle immagini in se

ngw

[rootkit]

Il giorno mercoledì 8 maggio 2013 12:10:12 UTC+2, nicholas...@gmail.com ha scritto:

> > > Riferendosi a siti di e-commerce aziendali (no sitarello della
> > > pizzeria), ... pro e contro di questa metodologia?
>
> > pro: ricerca/indicizzazione, performance sui grandi numeri, replicazione
> > e alta disponibilità in base alle caratteristiche del database.
> > contro: maggiori difficoltà a gestirli a mano.
>
> Ricerca e indicizzazione penso sia sui metadati, non sulle immagini in se

si naturalmente non intendevo ricerche nel contenuto bitmap.

[nicholas...@gmail.com]

Magari sbaglio ma penso l'OP intenda salvare fisicamente il file nel DB.
Se e' quello il caso, direi che e' molto molto meglio evitare, i DB sono per dati
strutturati, non per blob di dati.

ngw

[rootkit]

Il giorno mercoledì 8 maggio 2013 14:42:45 UTC+2, nicholas...@gmail.com ha scritto:


> Magari sbaglio ma penso l'OP intenda salvare fisicamente il file nel DB.
> Se e' quello il caso, direi che e' molto molto meglio evitare, i DB sono per dati
> strutturati, non per blob di dati.

si si, è corretto, io intendevo proprio il confronto fra salvare il file
sul db (campi blob, gridfs, datastore o simila) rispetto al file system.
la ricercabilità mi riferivo alla ricercabilità dell'immagine stessa a
partire dai dati indicizzati sul db, es. cercare l'immagine di un certo
articolo in un certo formato. chiaro che il db può mantenere anche solo
il riferimento al file e funziona identico ma sono comunque due tecniche a mio
avviso che hanno i loro pro e i loro contro. nessuna delle due la battezzo
sciocchezza tout court, per intendersi... poi nel caso specifico non
discuto.

[Soprano]

On Wed, 08 May 2013 05:42:45 -0700, nicholas.wieland wrote:

> i DB sono
> per dati strutturati, non per blob di dati.

e in SQL i tipi BLOB, CLOB etc allora che ci stanno a fare ? :)

diciamo che, come per quasi qualsiasi soluzione nell'informatica, ci sono
vantaggi e svantaggi

--
Soprano

[felice_pago]

per mettere le fatture, in formato in pdf :)
magari 1000 fatture a pdf, da indicizzare

e ti toglie il pensiero di "spostare" le fatture per sempre,
beh lo so' questa e' un po' criptica :)

felice pago

.

[nicholas...@gmail.com]

Puoi mantenere i metadati e usare una convenzione per il naming, non c'e' motivo per
mantenere il file stesso nel DB.
Se hai tutto sul FS, o ancora meglio su uno storage terzo come ad esempio S3, hai una
soluzione che costa pochissimo, molto piu' facile da distribuire (anche senza cloudfront),
e che mantiene tutti i vantaggi dell'uso del DB.

ngw

[ispas]

On 8 Mag, 15:35, Soprano <do...@chello.at> wrote:

> On Wed, 08 May 2013 05:42:45 -0700, nicholas.wieland wrote:
> > i DB sono
> > per dati strutturati, non per blob di dati.
>
> e in SQL i tipi BLOB, CLOB etc allora che ci stanno a fare ? :)

Forse non è questo il caso, ,ma magari tali tipi li hanno fatti e
subito hanno imprecato, deprecandoli :-) L'informatica è pure piena di
pseudo-standard fasulli, buttati nella monnezza 10 minuti dopo essere
stati lanciati in pompa magna.

[ispas]

On 8 Mag, 16:06, nicholas.wiel...@gmail.com wrote:
> Se hai tutto sul FS, o ancora meglio su uno storage terzo come ad esempio S3, hai una
> soluzione che costa pochissimo, molto piu' facile da distribuire (anche senza cloudfront),
> e che mantiene tutti i vantaggi dell'uso del DB.

Su servizi come S3 non so. Ma se hai tutto su un file system locale
del server, non c'è paragone tra mantenere migliaia di file singoli
(parlando di applicazioni di un certo impegno) piuttosto che un
database. Specialmente se questi files immagine non sono statici, ma
sono generati dall'applicazione. Basta pensare a quanto diventa
complesso gestire un "semplice" rollback in caso di qualche errore
elaborativo di un processo batch, che ti ha creato centinaia o
migliaia di files (es. proprio una fatturazione di massa).
Ma si potrebbe pensare anche ad altro, ad es. all'allocazione fisica:
quella del file system è efficiente tanto quanto quella del db? Nel
senso di ottimizzazione spazio e velocità di recupero dell'immagine.

[Soprano]

ci sono tanti motivi per i quali può avere senso salvare degli oggetti
binari in un database, me ne vengono in mente:

- l'oggetto stesso partecipa alla transazione, in caso di rollback è il
database che ripristina la situazione precedente

- l'oggetto segue le regole di cascade impostate nel database

- è molto più semplice tenere sincronizzati gli oggetti con i riferimenti
ad essi

- l'oggetto non ha un nome da mantenere, non è sottoposto ai diritti di
accesso sul file system, ma a quelli di accesso al database

- se fai un backup del db automaticamente lo fai anche dei relativi
oggetti binari

- puoi usare funzioni preimpostate del db, tipo "select unzip(colonna)
from table"

naturalmente ci sono anche i contro: più spreco di memoria dedicata al
database, operazioni di lettura/scrittura meno performanti, costo dei
dischi dedicati ai database generalemnte più alti ecc.


--
Soprano

[Marcoxxx]

ispas ha scritto:

> On 8 Mag, 16:06, nicholas.wiel...@gmail.com wrote:
> > Se hai tutto sul FS, o ancora meglio su uno storage terzo come ad esempio
S3, hai una
> > soluzione che costa pochissimo, molto piu' facile da distribuire (anche
senza cloudfront),
> > e che mantiene tutti i vantaggi dell'uso del DB.

> database. Specialmente se questi files immagine non sono statici, ma
> sono generati dall'applicazione. Basta pensare a quanto diventa
> complesso gestire un "semplice" rollback in caso di qualche errore
> elaborativo di un processo batch, che ti ha creato centinaia o
> migliaia di files (es. proprio una fatturazione di massa).

Curiosita' mia personale:

a me capito' nel lontano 2001 di dover inserire delle immagini in campi
BLOB di un DB. Quello su cui lavoravo io era un semplice sito per fare una
specie di catalogo online di un calzaturificio, ma la stessa tecnica
volevano poi usarla per un prototipo (sul quale avevo iniziato a lavorare)
per un sistema abbastanza piu' complesso che sarebbe dovuto servire alla
Piaggio per informatizzare l'ufficio acquisti (nel prototipo il DBMS era
MySQL, nel sistema reale avrebbe dovuto essere Oracle). Solo che nel caso
del sistema per la piaggio, almeno quando si fosse passati dal protoripo
al sistema reale loro volevano inserire come BLOB non tanto delle immagini
tipo jpeg o simili, ma volevano inserire dei file generati da autocad,
quindi dei disegni meccanici e roba simile; All'epoca ogni file di questo
genere "pesava" varie centinaia di mega (oggi non saprei). Considerate le
capacita' dei DB di allora e il numero di file autocad generati da
un'azienda come la Piaggio, questa agli ing. informatici che lavoravano al
progetto sembrava un'idea piuttosto folle (quella di tenere nelle tabelle
del DB dati del genere).

Non so dire come abbiano risolto, visto che io me ne andai praticamente
quando era appena stato iniziato il prototipo.

Pero' volevo capire se oggi come oggi, cioe' 13 anni dopo la mia
esperienza, qualcuno andasse da un DBA e gli dicesse:

"ho bisogno di un DB che mi consenta di memorizzare direttamente in
tabella come blob, alcuni file binari, ciascuno dei quali e' grande
qualche centinaio di mega e ogni giorno l'azienda produce decine se non
centinaia di questi file che devono essere inseriti del db."

Cosa direbbe il dba ?



Ciao,
Marco.

--

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it

[rootkit]

Il Wed, 08 May 2013 11:04:10 -0700, ispas ha scritto:

> Su servizi come S3 non so. Ma se hai tutto su un file system locale del
> server, non c'è paragone tra mantenere migliaia di file singoli
> (parlando di applicazioni di un certo impegno) piuttosto che un
> database.

migliaia di file non sono nulla, se si parla di applicazioni come dici te
di un certo impegno i numeri sono di qualche ordine di grandezza
superiori. gestire milioni di file come dici te in un file system locale
del server non sono certo tutte rose e fiori.

> Specialmente se questi files immagine non sono statici, ma
> sono generati dall'applicazione. Basta pensare a quanto diventa
> complesso gestire un "semplice" rollback in caso di qualche errore
> elaborativo di un processo batch, che ti ha creato centinaia o migliaia
> di files (es. proprio una fatturazione di massa).

non è certo un problema, anzi, lo vedo molto più problematico se questo
rollback lo devi fare in due posti diversi.

> Ma si potrebbe pensare anche ad altro, ad es. all'allocazione fisica:
> quella del file system è efficiente tanto quanto quella del db? Nel
> senso di ottimizzazione spazio e velocità di recupero dell'immagine.

premesso che, ovviamente, non ha senso fare un confronto tout court fra
questi due metodi di memorizzazione, si presuppone che se uno si pone il
problema è perché 1) ha un database e 2) ha delle informazioni sul
database come minimo da tenere collegate al file (e viceversa). ora
converrai che avere la possibilità di gestire gli aggiornamenti del file
binario e dei suoi dati in modo transazionale nonché di avere un legame
"indissolubile" fra questo contenuto e i suoi dati non sono vantaggi da
poco. ma anche la semplificazione della gestione della sicurezza. insomma
è chiaro che sono tanti gli aspetti da valutare ma i vantaggi ci sono.

[fm]

> ci sono tanti motivi per i quali pu� avere senso salvare degli oggetti

> binari in un database, me ne vengono in mente:
>

> - l'oggetto stesso partecipa alla transazione, in caso di rollback � il

> database che ripristina la situazione precedente
>
> - l'oggetto segue le regole di cascade impostate nel database
>

> - � molto pi� semplice tenere sincronizzati gli oggetti con i riferimenti
> ad essi
>
> - l'oggetto non ha un nome da mantenere, non � sottoposto ai diritti di

> accesso sul file system, ma a quelli di accesso al database
>
> - se fai un backup del db automaticamente lo fai anche dei relativi
> oggetti binari
>
> - puoi usare funzioni preimpostate del db, tipo "select unzip(colonna)
> from table"
>

> naturalmente ci sono anche i contro: pi� spreco di memoria dedicata al

> database, operazioni di lettura/scrittura meno performanti, costo dei

> dischi dedicati ai database generalemnte pi� alti ecc.
>
Grazie a tutti quelli che hanno risposto !!!

ciao
fm

[Francesco Da Riva]

On Thursday, May 9, 2013 12:27:16 AM UTC+2, Marcoxxx wrote:
> Solo che nel caso
> del sistema per la piaggio, almeno quando si fosse passati dal protoripo
> al sistema reale loro volevano inserire come BLOB non tanto delle immagini
> tipo jpeg o simili, ma volevano inserire dei file generati da autocad,
> quindi dei disegni meccanici e roba simile;

In pratica una qualche forma di PDM, i PDM usavano ed usano sempre un Vault esterno per la gestione dei file, in pratica un'area dl File System gestita direttamente dal DB mediante opportune procedure.

Alcuni DB hanno funzioni native per gestire questa cosa, in altri lo si fa via SP, in ogni caso nel caso di file di quelle dimensioni è la cosa migliore.

Ciao
Francesco

[ispas]

On 8 Mag, 20:40, Soprano <do...@chello.at> wrote:
> ci sono tanti motivi per i quali può avere senso salvare degli oggetti
> binari in un database, me ne vengono in mente:
>
> - l'oggetto stesso partecipa alla transazione, in caso di rollback è il
> database che ripristina la situazione precedente
>
> - l'oggetto segue le regole di cascade impostate nel database
>
> - è molto più semplice tenere sincronizzati gli oggetti con i riferimenti
> ad essi
>
> - l'oggetto non ha un nome da mantenere, non è sottoposto ai diritti di
> accesso sul file system, ma a quelli di accesso al database
>
> - se fai un backup del db automaticamente lo fai anche dei relativi
> oggetti binari
>
> - puoi usare funzioni preimpostate del db, tipo "select unzip(colonna)
> from table"
>
> naturalmente ci sono anche i contro: più spreco di memoria dedicata al
> database, operazioni di lettura/scrittura meno performanti, costo dei
> dischi dedicati ai database generalemnte più alti ecc.

Su questo sono d'accordo, potenzialmente un dbms è specificatamente
progettato per ottimizzare tutte le operazioni di gestione dei dati.
Anche dal punto di vista dell'I/O fisico potrebbe essere che il db lo
sfrutta meglio.
Poi se tutti questi vantaggi potenziali trovano piena attuazione nella
pratica non l'ho mai sperimentato.
Addirittura mi sembra che certi tipi speciali in certi db (purtroppo
non ricordo quali) mantengono automaticamente dei singoli files come
se fossero dei campi, quindi unificando i due approcci.

[ispas]

Centinaia di mega per singolo file mi sembra veramente tanto da
gestire entro un singolo campo di db; magari con una compressione si
ha una riduzione significativa. E' anche vero che oggi una cosa simile
si verifica, ad es., con i file video. Esattamente quello che fa
Youtube e gestori simili.

[ispas]

On 9 Mag, 01:00, rootkit <root...@email.it> wrote:
> migliaia di file non sono nulla, se si parla di applicazioni come dici te
> di un certo impegno i numeri sono di qualche ordine di grandezza
> superiori. gestire milioni di file come dici te in un file system locale
> del server non sono certo tutte rose e fiori.

Certo.

> > Specialmente se questi files immagine non sono statici, ma
> > sono generati dall'applicazione. Basta pensare a quanto diventa
> > complesso gestire un "semplice" rollback in caso di qualche errore
> > elaborativo di un processo batch, che ti ha creato centinaia o migliaia
> > di files (es. proprio una fatturazione di massa).
>
> non è certo un problema, anzi, lo vedo molto più problematico se questo
> rollback lo devi fare in due posti diversi.
>
> > Ma si potrebbe pensare anche ad altro, ad es. all'allocazione fisica:
> > quella del file system è efficiente tanto quanto quella del db? Nel
> > senso di ottimizzazione spazio e velocità di recupero dell'immagine.
>
> premesso che, ovviamente, non ha senso fare un confronto tout court fra
> questi due metodi di memorizzazione, si presuppone che se uno si pone il
> problema è perché 1) ha un database e 2) ha delle informazioni sul
> database come minimo da tenere collegate al file (e viceversa). ora
> converrai che avere la possibilità di gestire gli aggiornamenti del file
> binario e dei suoi dati in modo transazionale nonché di avere un legame
> "indissolubile" fra questo contenuto e i suoi dati non sono vantaggi da
> poco. ma anche la semplificazione della gestione della sicurezza. insomma
> è chiaro che sono tanti gli aspetti da valutare ma i vantaggi ci sono.

In sostanza mi sembra che siamo d'accordo, potenzialmente meglio avere
tutto entro il db. Salvo successive analisi e verifiche del caso
effettivo.

[Manlio Perillo]

Il Thu, 09 May 2013 02:39:08 -0700, ispas ha scritto:

> [...]

> Addirittura mi sembra che certi tipi speciali in certi db (purtroppo non
> ricordo quali) mantengono automaticamente dei singoli files come se
> fossero dei campi, quindi unificando i due approcci.

PostgreSQL offre supporto per i "Large Objects".
In pratica memorizzi l'Oid del file, e poi i dati sono salvati altrove in
chunks da M kb (e viene fornita un API apposita per gestirli).


Ciao Manlio

[felice_pago]

On 9 Mag, 15:31, Manlio Perillo <manlio_perill...@SPAMlibero.it>
wrote:

e un backup/storicizzazione come funge ?


felic epago
.

[Mau C]

Il 09/05/2013 15:31, Manlio Perillo ha scritto:
> PostgreSQL offre supporto per i "Large Objects".
> In pratica memorizzi l'Oid del file, e poi i dati sono salvati altrove in
> chunks da M kb (e viene fornita un API apposita per gestirli).

Lo fanno anche Oracle e MySQL.

M.

[Francesco Da Riva]

On Friday, May 10, 2013 9:13:55 AM UTC+2, Mau C wrote:

> Lo fanno anche Oracle e MySQL.

Anche MS SQL Server sia con gli RBS sia con il FILESTEAM

Ciao
Francesco

[Manlio Perillo]

Con altrove, intendevo in una tabella di sistema, che contiene le colonne:

Column | Type | Modifiers
--------+---------+-----------
loid | oid | not null
pageno | integer | not null
data | bytea |

Il backup, quindi, funziona normalmente.



Ciao Manlio

[kojak]

nel posto in cui ho lavorato fino a poche settimane fa qualche
volta mi è capitato di sviluppare web applications in cui
erano previste delle sezioni nelle quali c'era la necessità
di memorizzare un'immagine.

Qualunque fosse il db utilizzato per la webapp (per lo più
mysql e sql server), noi procedevamo in questo modo:
per prima cosa definivamo il percorso, ossia la (o le)
directory, in cui dovevano essere messe fisicamente le
immagini (non ho voluto scrivere "uploadate", lo so che si
usa così, ma a me questi termini fanno davvero cagare il
cazzo, per cui cerco di non usarli, a costo di usare
lunghe perifrasi). Per definire il percorso, di norma
si andava nel web.xml a mettere una variabile contenente
la stringa del path, in modo che la si potesse poi
chiamare agevolmente e gestire in un unico punto, anche se
mi pare che qualche volta invece il percorso lo
avessimo definito nella classe java in cui si faceva l'upload.

Poi, una volta definito il percorso, nella classe java (la
servlet) facevamo l'upload dell'immagine presa dall'input
file della jsp, e nello stesso metodo si faceva la insert
sul db del nome dell'immagine.
In sostanza:


public void salvaImmagine()
{
eseguiUpload();
salvaNomeImmagineSulDb();
}



questo era in genere lo standard. Se poi si voleva togliere
l'immagine memorizzata, semplicemente si faceva la delete
su db, ed eventualmente la cancellazione fisica del file
(ma non necessariamente).
Poi ovviamente nell'eseguiUpload() se necessario facevamo
altre operazioni, tipo cambiare il nome dell'immagine in
base alle esigenze del progetto stesso (ed è successo
più di una volta, che ne so, mettere la data, o mettere
un id di qualche oggetto, ecc.), e salvando poi
ovviamente su db col nome corretto.


E' chiaro che questo approccio non è perfetto, perché
in pratica, come puoi vedere dallo schemino, tu devi
fare un'unica operazione (salvare l'immagine) e la
trasformi in due operazioni, cioè upload e salvataggio
su db, per cui può benissimo accadere che una va a buon
fine e l'altra no, cosa che naturalmente non è buona.

Con un po' di gestione eccezioni io cercavo di limitare
il rischio, ma d'altra parte se hai due operazioni invece
di una si sa che un po' di rischio rimane.




Però sinceramente devo dire che a me questo approccio
sembra buono, naturalmente in base alle conoscenze che
ho io: una volta mi è capitato di vedere invece un db
(non ricordo che tipo) in cui proprio si memorizzavano
i bit dell'immagine, ma a me sembra una cosa inguardabile,
così.

L'immagine non è mica una stringa o una data, né un numero,
come puoi salvarla su db come se lo fosse? Almeno questo è
quello che penso io.

[Tony]

<L'immagine non � mica una stringa o una data, n� un numero,
<come puoi salvarla su db come se lo fosse? Almeno questo �
<quello che penso io.

� un array di byte (byte[] ),lo puoi considerare e salvare in tal modo.

[bramante]

Il 11/05/2013 15:46, kojak ha scritto:

l'approccio da te descritto � quello che utilizzano il 90% delle
aziende, per farti capire FB utilizza lo stesso approccio (molto pi�
sofisticato ma in line di principio lo stesso).

Questo consente di avere alte prestazioni su db, e risparmio di spazio
(condivisione delle immagini con pi� persone), ridondanza, e possibilit�
di avere un db snello e suddividere il carico dei file su pi� server,
oppure gestire i file con servizi esterni (tipo dropbox, S3 di amazon, e
altri)

facilt� nell'ispezionare il contenuto qualora necessario, ecc..

Ciao