it-swarm.it

È meglio archiviare immagini in un BLOB o solo nell'URL?

Possibile duplicato:
File - nel database o no?

Mi chiedevo se ci fosse qualche buona ragione per usare ancora i campi BLOB in un database. Un paio d'anni fa ho lavorato con un DB con un mucchio di immagini, il DB era molto lento e non riuscivo a vedere alcun buon motivo per mantenere le immagini all'interno del DB, quindi ho estratto le immagini e memorizzato i nomi dei file anziché.

È stata una mossa intelligente? Cosa faresti tu al mio posto?

38
eiefai

Come puoi vedere dalle altre risposte, questo è un grande "Dipende". Alcuni altri fattori potrebbero essere se si paga per l'hosting, fanno pagare di più per l'archiviazione dei file o l'archiviazione del database. L'archiviazione dei file è in genere più economica, soprattutto per i servizi cloud.

Se si è ospitati autonomamente e si utilizza SQL Server, la versione imminente, nome in codice Denali, estende FILESTREAM per consentire l'accesso sia tramite TSQL sia dal file system. Inoltre assicurerà che rimangano sincronizzati. Puoi accedere, aggiornare, eliminare da entrambi i lati e manterrà tutto organizzato.

Fai le tue ricerche e scopri cosa è importante per te e scegli la direzione in base a quella scelta.

Il motivo per utilizzare i BLOB è semplicemente la gestibilità: hai esattamente un metodo per eseguire il backup e il ripristino del database, puoi facilmente fare backup incrementali, non c'è rischio per l'immagine e i suoi metadati memorizzati nelle tabelle dei DB non si sincronizzano mai , hai anche un'interfaccia di programmazione per eseguire query o caricare/salvare immagini, quindi non è necessario concedere l'accesso al filesystem dei client remoti e sai che le stesse GRANT si applicheranno alle immagini e ai loro dati associati. Inoltre hai un metodo di gestione dello storage (ad es. In Oracle potresti mettere tutto su ASM e usare Oracle come LVM per tutto).

Un'altra applicazione è quella di mescolare dati relazionali con oggetti serializzati (un BLOB può essere qualsiasi binario, non è necessario che siano immagini). Oppure è possibile eseguire una query su dati di relazione e byte x-y in BLOB, che potrebbe essere ad esempio un'intestazione di file. Le applicazioni sono infatti infinite.

Se l'accesso a un BLOB è stato più lento dell'accesso al file system, è molto probabile che il database sia stato configurato in modo errato.

17
Gaius

Non utilizzo i BLOB, principalmente dal punto di vista del backup e del ripristino, poiché non voglio che i dati del BLOB rallentino i miei backup.

Non memorizzo un URL completo, tuttavia ... Memorizzo solo il percorso file al di sotto di un determinato punto e creo il percorso in quanto ho più di un modo in cui persone e programmi accedono ai miei file (FTP, HTTP, directory locale, Directory montate su NFS).

... ovviamente, probabilmente mi occupo di immagini più grandi e più grandi della maggior parte delle persone ... uno dei miei set di dati ottiene circa 700 GB di immagini (compresse) al giorno. Ma anche le anteprime di quelle immagini, le conservo ancora esternamente.

13
Joe

Sono un grande fan della memorizzazione della copia "di riferimento" dell'immagine nel database: dal punto di vista della gestibilità/del ripristino di emergenza questo è davvero il modo di volare.

Ora, puoi ancora fare molte cose per servire l'immagine fuori dal filesystem per la maggior parte delle applicazioni, quindi non stai esercitando troppa pressione sul server di database stesso per fare cose che in realtà non vuole fare.

8
Wyatt Barnett

Se stai lavorando con Linux, la memorizzazione delle immagini nel filesystem e non nel database ha prestazioni significativamente migliori, vedi questo estratto del libro di Brad Ediger Advanced Rails .

8
j.p.

Non sono un grande fan della memorizzazione di immagini nel database. In una piccola app con pochi utenti, sembra una soluzione facile, ma quando inizi a ridimensionare, rende le cose più difficili.

La mia preferenza è iniziare a memorizzare le immagini in una cartella sul server Web, ma mantenere il percorso in una configurazione facilmente accessibile in modo che, quando necessario, posso spostarle rapidamente sul loro server di immagini dedicato e ottimizzato. Più tardi, potrei voler spostarli altrove (pensa S3 o Akamai) allo stesso modo. Tutto ciò è molto più complicato se devo cambiare il codice che si aspettava di leggerli dal database.

5
phred

È stata una mossa intelligente?

Se è stata una mossa intelligente o meno, dipende dal tuo caso specifico:

Se il percorso del file influisce direttamente su qualsiasi struttura di URL o se stai memorizzando gli indirizzi di file completi nel database (errato), posso dire che è stata una mossa sbagliata poiché avrai problemi nel caso in cui qualcuno sposti o rinomini una directory.

Ma se Ma se la tua applicazione è costruita in un modo devi semplicemente puntare la directory dei file e la logica di accesso ai file è dinamica, hai fatto una mossa intelligente per i seguenti motivi:

  • Con l'archiviazione del database, se è necessario servire molte immagini per richiesta, si aumenterà il tempo di risposta dell'applicazione poiché i file verranno inviati in modo sincrono alla rete. Inoltre aggiungerai un po 'più di elaborazione al tuo server.

  • L'archiviazione dei file è generalmente più economica dell'archiviazione del database.

  • Con l'archiviazione dei file (a meno che non vi siano restrizioni all'accesso alle immagini: solo un determinato utente può accedere a un determinato gruppo di immagini), non è necessario alcun trattamento per accedere alle immagini o a qualsiasi altro tipo di file.

  • Con l'archiviazione del database non è possibile accedere ai file tramite FTP (abbastanza ovvio, ma è bene ricordare).

  • L'archiviazione dei file di database rallenta e/o ingombra i backup periodici del database.

Cosa faresti tu al mio posto?

Terrei quella decisione a meno che non appaia un fattore dominante contrario.

Spero che aiuti.

4
marcio