Quindi sto usando un'app che archivia pesantemente le immagini nel DB. Qual è la tua opinione al riguardo? Sono più di un tipo per memorizzare la posizione nel filesystem, piuttosto che memorizzarla direttamente nel DB.
Quali pensi siano i pro / contro?
Risposte:
Sono responsabile di alcune applicazioni che gestiscono molte TB di immagini. Abbiamo scoperto che l'archiviazione dei percorsi dei file nel database è la migliore.
Ci sono un paio di problemi:
Come con la maggior parte dei problemi, non è così semplice come sembra. Ci sono casi in cui avrebbe senso archiviare le immagini nel database.
D'altra parte ci sono problemi associati
Archivio file. Gli ingegneri di Facebook ne hanno parlato molto bene. Un take away era conoscere il limite pratico dei file in una directory.
Needle in a Haystack: conservazione efficiente di miliardi di foto
Potrebbe essere un po 'lungo, ma se stai usando (o stai pianificando di usare) SQL Server 2008 ti consiglio di dare un'occhiata al nuovo tipo di dati FileStream .
FileStream risolve la maggior parte dei problemi relativi alla memorizzazione dei file nel DB:
Tuttavia, "Transparent Data Encryption" di SQL non crittografa gli oggetti FileStream, quindi se è una considerazione, è meglio archiviarli come varbinary.
Dall'articolo MSDN:
Le istruzioni Transact-SQL possono inserire, aggiornare, interrogare, cercare ed eseguire il backup dei dati FILESTREAM. Le interfacce del file system Win32 forniscono l'accesso in streaming ai dati.
FILESTREAM utilizza la cache di sistema NT per la memorizzazione nella cache dei dati del file. Ciò aiuta a ridurre qualsiasi effetto che i dati FILESTREAM potrebbero avere sulle prestazioni del Motore di database. Il pool di buffer di SQL Server non viene utilizzato; pertanto, questa memoria è disponibile per l'elaborazione delle query.
I percorsi dei file nel DB sono sicuramente la strada da percorrere - ho sentito storie su storie dai clienti con TB di immagini che è diventato un incubo tentare di archiviare qualsiasi quantità significativa di immagini in un DB - la performance da sola è troppo.
Nella mia esperienza, a volte la soluzione più semplice è denominare le immagini in base alla chiave primaria . Quindi è facile trovare l'immagine che appartiene a un particolare record e viceversa. Ma allo stesso tempo non stai memorizzando nulla sull'immagine nel database.
Il trucco qui è di non diventare un fanatico.
Una cosa da notare qui è che nessuno nel campo del file system pro ha elencato un determinato file system. Questo significa che tutto, da FAT16 a ZFS, batte facilmente ogni database?
No.
La verità è che molti database battono molti file system, anche quando parliamo solo di velocità pura.
Il corretto modo di agire è prendere la decisione giusta per il tuo preciso scenario e, per farlo, avrai bisogno di alcuni numeri e di alcune stime dei casi d'uso.
Nei luoghi in cui DEVI garantire l'integrità referenziale e la conformità ACID, è richiesta la memorizzazione delle immagini nel database.
Non è possibile garantire transazionalmente che l'immagine e i metadati relativi all'immagine memorizzata nel database facciano riferimento allo stesso file. In altre parole, è impossibile garantire che il file sul filesystem sia sempre e solo modificato contemporaneamente e nella stessa transazione dei metadati.
Come altri hanno già detto, SQL 2008 viene fornito con un tipo Filestream che consente di archiviare un nome file o identificatore come puntatore nel db e memorizza automaticamente l'immagine sul proprio filesystem, il che è un ottimo scenario.
Se si trova in un database più vecchio, direi che se lo si archivia come dati BLOB, in realtà non si otterrà nulla dal database nel modo di cercare funzionalità, quindi probabilmente è meglio per memorizzare un indirizzo su un filesystem e memorizzare l'immagine in quel modo.
In questo modo risparmi anche spazio sul tuo filesystem, poiché risparmierai solo l'esatta quantità di spazio, o anche lo spazio compattato sul filesystem.
Inoltre, potresti decidere di salvare con qualche struttura o elementi che ti consentono di sfogliare le immagini grezze nel tuo filesystem senza alcun db hit o di trasferire i file in blocco su un altro sistema, disco rigido, S3 o un altro scenario - aggiornando la posizione in il tuo programma, ma mantieni la struttura, ancora una volta senza molto successo, cercando di estrarre le immagini dal tuo db quando provi ad aumentare la memoria.
Probabilmente, ti permetterebbe anche di gettare alcuni elementi della cache, basati sugli URL delle immagini comunemente colpiti nel tuo motore / programma web, quindi ti stai salvando anche lì.
Le piccole immagini statiche (non più di un paio di mega) che non vengono modificate frequentemente, devono essere archiviate nel database. Questo metodo offre numerosi vantaggi, tra cui una portabilità più semplice (le immagini vengono trasferite con il database), un backup / ripristino più semplice (il backup delle immagini viene eseguito con il database) e una migliore scalabilità (una cartella del file system con migliaia di piccoli file di miniature sembra un incubo di scalabilità per me).
Servire le immagini da un database è facile, basta implementare un gestore http che serve l'array di byte restituito dal server DB come flusso binario.
Ecco un interessante white paper sull'argomento.
BLOB o Non BLOB: archiviazione di oggetti di grandi dimensioni in un database o un filesystem
La risposta è, dipende." Certamente dipenderà dal server di database e dal suo approccio all'archiviazione BLOB. Dipende anche dal tipo di dati archiviati nei BLOB, nonché dalla modalità di accesso a tali dati.
I file di dimensioni inferiori possono essere archiviati e consegnati in modo efficiente utilizzando il database come meccanismo di archiviazione. I file più grandi dovrebbero probabilmente essere archiviati nel modo migliore usando il file system, specialmente se verranno modificati / aggiornati spesso. (La frammentazione dei BLOB diventa un problema per quanto riguarda le prestazioni.)
Ecco un ulteriore punto da tenere a mente. Uno dei motivi che supportano l'uso di un database per archiviare i BLOB è la conformità ACID. Tuttavia, l'approccio utilizzato dai tester nel white paper (opzione Bulk Logged di SQL Server) che ha raddoppiato il throughput di SQL Server, ha effettivamente modificato la "D" in ACID in una "d", poiché i dati BLOB non erano registrati con le scritture iniziali per la transazione. Pertanto, se la piena conformità ACID è un requisito importante per il sistema, dimezzare le cifre della velocità effettiva di SQL Server per le scritture del database quando si confrontano l'I / O dei file con l'I / O del BLOB del database.
Una cosa che non ho ancora visto nessuno menzionato, ma che vale sicuramente la pena notare è che ci sono problemi associati alla memorizzazione di grandi quantità di immagini anche nella maggior parte dei filesystem. Ad esempio, se segui l'approccio sopra citato e dai un nome a ciascun file di immagine dopo la chiave primaria, sulla maggior parte dei filesystem ti imbatterai in problemi se provi a mettere tutte le immagini in una grande directory una volta raggiunto un numero molto elevato di immagini ( ad esempio in centinaia di migliaia o milioni).
Una volta una soluzione comune a questo è quella di portarli in un albero equilibrato di sottodirectory.
Qualcosa che nessuno ha menzionato è che il DB garantisce azioni atomiche, integrità transazionale e gestione della concorrenza. Anche l'integrità referenziale è fuori dalla finestra con un filesystem - quindi come fai a sapere che i nomi dei tuoi file sono ancora corretti?
Se hai le tue immagini in un file system e qualcuno sta leggendo il file mentre stai scrivendo una nuova versione o addirittura cancellando il file - cosa succede?
Utilizziamo i BLOB perché sono anche più facili da gestire (backup, replica, trasferimento). Funzionano bene per noi.
Il problema con l'archiviazione di solo percorsi di file su immagini in un database è che l'integrità del database non può più essere forzata.
Se l'immagine effettiva a cui punta il percorso file non è disponibile, il database ha involontariamente un errore di integrità.
Dato che le immagini sono i dati effettivi ricercati e che possono essere gestite più facilmente (le immagini non scompaiono improvvisamente) in un database integrato anziché dover interfacciarsi con un qualche tipo di filesystem (se si accede in modo indipendente al filesystem, le immagini POTREBBE improvvisamente "scomparire"), andrei per memorizzarle direttamente come BLOB o simili.
In un'azienda in cui lavoravo, abbiamo archiviato 155 milioni di immagini in un database Oracle 8i (poi 9i). Valore di 7,5 TB.
Normalmente, sono fermamente contrario a prendere la parte più costosa e più difficile da scalare della tua infrastruttura (il database) e a caricarci tutto. D'altra parte: semplifica notevolmente la strategia di backup, soprattutto quando si hanno più server Web e si deve in qualche modo mantenere sincronizzati i dati.
Come la maggior parte delle altre cose, dipende dalle dimensioni e dal budget previsti.
Abbiamo implementato un sistema di imaging dei documenti che archivia tutte le sue immagini nei campi BLOB SQL2005. Al momento ci sono diverse centinaia di GB e stiamo assistendo a tempi di risposta eccellenti e ad un degrado delle prestazioni ridotto o nullo. Inoltre, per quanto riguarda la conformità normativa, disponiamo di un livello middleware che archivia i documenti appena pubblicati su un sistema di jukebox ottico che li espone come un file system NTFS standard.
Siamo rimasti molto soddisfatti dei risultati, in particolare per quanto riguarda:
Presupposto: l'applicazione è abilitata per il web / basata sul web
Sono sorpreso che nessuno lo abbia mai menzionato ... delegalo ad altri specialisti -> usa un provider di hosting di file / immagini di terze parti .
Archivia i tuoi file su un servizio online a pagamento come
Un altro thread StackOverflow ne parla qui .
Questa discussione spiega perché dovresti usare un provider di hosting di terze parti.
Ne vale davvero la pena. Lo memorizzano in modo efficiente. Nessuna banda senza essere caricata dai tuoi server alle richieste del client, ecc.
Se non sei su SQL Server 2008 e hai dei solidi motivi per inserire specifici file di immagine nel database, puoi adottare l'approccio "entrambi" e utilizzare il file system come cache temporanea e utilizzare il database come repository principale .
Ad esempio, la tua logica aziendale può verificare se esiste un file immagine sul disco prima di servirlo, recuperandolo dal database quando necessario. Ciò ti offre la possibilità di più server Web e meno problemi di sincronizzazione.
Non sono sicuro di quanto sia un esempio di "mondo reale", ma al momento ho un'applicazione che memorizza i dettagli di un gioco di carte collezionabili, comprese le immagini per le carte. Ad oggi, il numero di record per il database è solo di 2851 record, ma dato il fatto che alcune carte sono state rilasciate più volte e hanno disegni alternativi, in realtà è stato più efficiente dimensionalmente scansionare il "quadrato primario" del disegno e quindi dinamicamente genera il bordo e gli effetti vari per la carta quando richiesto.
Il creatore originale di questa libreria di immagini ha creato una classe di accesso ai dati che esegue il rendering dell'immagine in base alla richiesta e lo fa abbastanza velocemente per la visualizzazione e la singola scheda.
Ciò facilita anche l'implementazione / gli aggiornamenti quando vengono rilasciate nuove schede, invece di comprimere un'intera cartella di immagini e inviarle nel pipe e assicurandomi che venga creata la struttura delle cartelle corretta, aggiorno semplicemente il database e faccio scaricare nuovamente l'utente. Questo attualmente misura fino a 56 MB, il che non è eccezionale, ma sto lavorando a una funzione di aggiornamento incrementale per le versioni future. Inoltre, esiste una versione "senza immagini" dell'applicazione che consente agli utenti con accesso remoto di ottenere l'applicazione senza il ritardo del download.
Questa soluzione ha funzionato alla grande sin da quando l'applicazione stessa è destinata come singola istanza sul desktop. Esiste un sito Web in cui tutti questi dati sono archiviati per l'accesso online, ma per questo non utilizzerei la stessa soluzione. Sono d'accordo che l'accesso ai file sarebbe preferibile perché ridimensionerebbe meglio la frequenza e il volume delle richieste fatte per le immagini.
Spero che questa non sia troppa chiacchiera, ma ho visto l'argomento e volevo fornire alcune mie intuizioni da un'applicazione su piccola / media scala relativamente riuscita.
SQL Server 2008 offre una soluzione che offre il meglio dei due mondi: il tipo di dati filestream .
Gestirlo come una normale tabella e avere le prestazioni del file system.
Dipende dal numero di immagini che stai per memorizzare e anche dalle loro dimensioni. Ho usato database per archiviare immagini in passato e la mia esperienza è stata abbastanza buona.
IMO, I professionisti dell'utilizzo del database per archiviare le immagini sono,
A. Non è necessaria la struttura FS per contenere le immagini
B. Gli indici del database hanno prestazioni migliori rispetto agli alberi FS quando deve essere memorizzato un numero maggiore di elementi
C. Il database ottimizzato in modo intelligente svolge un buon lavoro nella memorizzazione nella cache dei risultati della query
D. I backup sono semplici. Funziona bene anche se hai impostato la replica e il contenuto viene consegnato da un server vicino all'utente. In tali casi, non è richiesta la sincronizzazione esplicita.
Se le tue immagini saranno piccole (diciamo <64k) e il motore di archiviazione del tuo db supporta BLOB in linea (nei record), migliora ulteriormente le prestazioni in quanto non è richiesta alcuna indiretta (viene raggiunta la località di riferimento).
La memorizzazione di immagini può essere una cattiva idea quando si ha a che fare con un numero limitato di immagini di dimensioni enormi. Un altro problema con la memorizzazione delle immagini in db è che, come la creazione, i metadati, le date di modifica devono essere gestiti dall'applicazione.
Di recente ho creato un'app PHP / MySQL che memorizza file PDF / Word in una tabella MySQL (fino a 40 MB per file finora).
Professionisti:
Contro:
Definirei la mia implementazione un successo, si occupa dei requisiti di backup e semplifica il layout del progetto. Le prestazioni vanno bene per le 20-30 persone che usano l'app.
Nella mia esperienza ho dovuto gestire entrambe le situazioni: immagini archiviate nel database e immagini sul file system con percorso archiviato in db.
La prima soluzione, le immagini nel database, è in qualche modo "più pulita" poiché il livello di accesso ai dati dovrà occuparsi solo degli oggetti del database; ma questo va bene solo quando devi fare i conti con numeri bassi.
Ovviamente le prestazioni di accesso al database quando si trattano oggetti binari di grandi dimensioni stanno peggiorando e le dimensioni del database aumenteranno molto, causando di nuovo una perdita di prestazioni ... e normalmente lo spazio del database è molto più costoso dello spazio del file system.
D'altra parte, avere oggetti binari di grandi dimensioni memorizzati nel file system ti farà avere piani di backup che devono considerare sia il database che il file system, e questo può essere un problema per alcuni sistemi.
Un altro motivo per scegliere il file system è quando devi condividere i dati delle tue immagini (o suoni, video, qualunque cosa) con accesso di terze parti: in questi giorni sto sviluppando un'app Web che utilizza immagini a cui è necessario accedere dall'esterno "la mia web farm in modo tale che l'accesso al database per recuperare i dati binari sia semplicemente impossibile. Quindi a volte ci sono anche considerazioni di progettazione che ti guideranno a una scelta.
Considera anche, quando fai questa scelta, se devi avere a che fare con l'autorizzazione e l'autenticazione quando accedi agli oggetti binari: questi requisiti normalmente possono essere risolti in modo più semplice quando i dati sono archiviati in db.
Una volta ho lavorato su un'applicazione di elaborazione delle immagini. Abbiamo archiviato le immagini caricate in una directory simile a / images / [data odierna] / [numero ID]. Ma abbiamo anche estratto i metadati (dati exif) dalle immagini e archiviati nel database, insieme a un timestamp e simili.
In un precedente progetto ho archiviato immagini sul filesystem e questo ha causato molti mal di testa con backup, replica e il filesystem non sincronizzato con il database.
Nel mio ultimo progetto sto memorizzando le immagini nel database e memorizzandole nella cache sul filesystem, e funziona davvero bene. Finora non ho avuto problemi.
Secondo la raccomandazione sui percorsi dei file. Ho lavorato su un paio di progetti che dovevano gestire raccolte di risorse di grandi dimensioni e qualsiasi tentativo di archiviare le cose direttamente nel DB ha provocato dolore e frustrazione a lungo termine.
L'unico vero "pro" che mi viene in mente per quanto riguarda l'archiviazione nel DB è il potenziale per la facilità di risorse di immagine individuali. Se non ci sono percorsi di file da usare e tutte le immagini vengono trasmesse in streaming direttamente dal DB, non c'è pericolo che un utente trovi i file a cui non dovrebbe avere accesso.
Sembra che sarebbe meglio risolverlo con uno script intermedio che estrae i dati da un archivio di file inaccessibile al web. Quindi l'archiviazione DB non è REALMENTE necessaria.
La parola per strada è che a meno che tu non sia un fornitore di database che prova a dimostrare che il tuo database può farlo (come, diciamo, Microsoft che si vanta di Terraserver che memorizza immagini bajillion in SQL Server) non è una buona idea. Quando l'alternativa: archiviare immagini su file server e percorsi nel database è molto più semplice, perché preoccuparsi? I campi BLOB sono un po 'come le capacità fuoristrada dei SUV: la maggior parte delle persone non li usa, quelli che di solito si mettono nei guai, e poi ci sono quelli che lo fanno, ma solo per divertimento.
La memorizzazione di un'immagine nel database significa comunque che i dati dell'immagine finiscono da qualche parte nel file system ma sono oscurati in modo da non poter accedervi direttamente.
+ ves:
-ves:
Entrambi i metodi sono comuni e praticati. Dai un'occhiata ai vantaggi e agli svantaggi. Ad ogni modo, dovrai pensare a come superare gli svantaggi. La memorizzazione nel database di solito significa modificare i parametri del database e implementare un qualche tipo di memorizzazione nella cache. L'uso del filesystem richiede di trovare un modo per mantenere sincronizzati filesystem + database.