Da fare o da non fare: memorizzare le immagini in un database [duplicato]

https://stackoverflow.com/questions/815626

03-07-2019
|

Domanda

Questa domanda ha già una risposta qui:

Archiviazione di immagini in DB - Sì o No? 56 risposte

Nel contesto di un'applicazione web, il mio vecchio capo diceva sempre di mettere un riferimento a un'immagine nel database, non all'immagine stessa. Tendo a concordare sul fatto che archiviare un URL rispetto all'immagine stessa nel DB sia una buona idea, ma dove lavoro ora, archiviamo molte immagini nel database.

L'unica ragione a cui riesco a pensare è forse che è più sicuro? Non vuoi che qualcuno abbia un link diretto a un URL? Ma in tal caso, puoi sempre che il sito web / server gestisca le immagini, come i gestori in asp.net, in modo che un utente debba autenticarsi per visualizzare l'immagine. Sto anche pensando che le prestazioni sarebbero danneggiate estraendo le immagini dal database. Qualche altro motivo per cui potrebbe essere una buona / non buona idea archiviare immagini in un database?

Duplicato esatto: Immagini utente: archiviazione database o filesystem ?
Duplicazione esatta: Memorizzazione delle immagini nel database: sì o no ?
Duplicazione esatta: Dovrei memorizzare le mie immagini nel database o nelle cartelle?
Duplicazione esatta: Conserveresti i dati binari nel database o nelle cartelle?
Duplicazione esatta: Archivia le immagini come file o o nel database di un'app Web?
Duplicazione esatta: Memorizzazione di un piccolo numero di immagini: blob o fs?
Duplicazione esatta: archivia l'immagine nel filesystem o database?

Soluzione

Se in occasioni è necessario recuperare un'immagine e deve essere disponibile su diversi server Web. Ma penso che sia praticamente tutto.

Se non deve essere disponibile su più server, è sempre meglio inserirli nel file system.
Se deve essere disponibile su più server e in realtà è presente un tipo di carico nel sistema, è necessario un tipo di archiviazione distribuita.

Stiamo parlando di un caso limite qui, in cui puoi evitare di aggiungere un ulteriore livello di complessità al tuo sistema sfruttando il database.

A parte questo, non farlo.

Altri suggerimenti

Pro di mettere le immagini in un database.

Le transazioni. Quando si salva il BLOB, è possibile eseguirne il commit proprio come qualsiasi altro pezzo di dati DB. Ciò significa che è possibile eseguire il commit del BLOB insieme a uno qualsiasi dei metadati associati ed essere certi che i due siano sincronizzati. Se esaurisci lo spazio su disco? Nessun impegno. Il file non è stato caricato completamente? Nessun impegno. Errore di applicazione sciocco? Nessun impegno. Se mantenere le immagini e i metadati associati coerenti tra loro è importante per la tua applicazione, le transazioni che un DB può fornire possono essere un vantaggio.
Un sistema da gestire. Devi eseguire il backup dei metadati e dei BLOB? Eseguire il backup del database. Hai bisogno di replicarli? Replica il database. Hai bisogno di recuperare da un errore di sistema parziale? Ricarica il DB e sposta i log in avanti. Tutti i vantaggi che i DB apportano ai dati in generale (mappatura del volume, controllo dell'archiviazione, backup, replica, ripristino, ecc.) Si applicano ai BLOB. Più coerenza, gestione più semplice.
Sicurezza. I database hanno funzioni di sicurezza molto dettagliate che possono essere sfruttate. Schemi, ruoli utente, anche cose come "leggi solo visualizzazioni" per fornire un accesso sicuro a un sottoinsieme di dati. Tutte queste funzionalità funzionano anche con tabelle che contengono BLOB.
Gestione centralizzata. Relativi al n. 2, ma sostanzialmente i DBA (come se non avessero abbastanza potenza) riescono a gestire una cosa: il database. I database moderni (specialmente quelli più grandi) funzionano molto bene con installazioni di grandi dimensioni su più macchine. Un'unica fonte di gestione semplifica le procedure, semplifica il trasferimento delle conoscenze.
La maggior parte dei database moderni gestisce bene i BLOB. Con il supporto di prima classe di BLOB nel livello dati, è possibile eseguire facilmente lo streaming di BLOB dal DB al client. Mentre ci sono operazioni che puoi fare, "succherai" " l'intero blob tutto in una volta, se non hai bisogno di quella funzione, allora non usarla. Studia l'interfaccia SQL per il tuo DB e sfrutta le sue funzionalità. Nessun motivo per trattarli come "grandi stringhe" che vengono trattati monoliticamente e trasformano i tuoi BLOB in grandi bombe che inghiottono la memoria e distruggono la cache.
Proprio come è possibile configurare file server dedicati per le immagini, è possibile configurare server BLOB dedicati nel database. Assegna loro volumi di dischi dedicati, schemi dedicati, cache dedicate, ecc. Tutti i tuoi dati nel DB non sono gli stessi o si comportano allo stesso modo, nessun motivo per configurarli tutti uguali. Buoni database hanno un ottimo livello di controllo.

Il nit principale per quanto riguarda la gestione di un BLOB da un DB è garantire che il proprio livello HTTP sfrutti effettivamente tutto il protocollo HTTP per eseguire il servizio.

Molte implementazioni ingenue prendono semplicemente il BLOB e lo scaricano all'ingrosso nel socket. Tuttavia, l'HTTP ha diverse caratteristiche importanti che ben si adattano allo streaming di immagini, ecc. In particolare la memorizzazione nella cache di intestazioni, ETag e trasferimento in blocco per consentire ai clienti di richiedere "pezzi". del blob.

Assicurati che il tuo servizio HTTP rispetti correttamente tutte queste richieste e che il tuo DB possa essere un ottimo cittadino Web. Memorizzando nella cache i file in un filesystem affinché vengano serviti dal server HTTP, si ottengono alcuni di questi vantaggi "gratuiti" (dal momento che un buon server lo farà comunque per le risorse "statiche"), ma assicurati che se lo fai, onori cose come le date di modifica ecc. per le immagini.

Ad esempio, qualcuno richiede spaceshuttle.jpg, un'immagine creata il 1 ° gennaio 2009. Ciò finisce nella cache sul file system alla data della richiesta, ad esempio il 1 ° febbraio 2009. Successivamente, l'immagine viene eliminata dalla cache (Politica FIFO, o qualsiasi altra cosa) e qualcuno, più tardi, il 1 ° marzo 2009 lo richiede nuovamente. Bene, ora ha una data di creazione del 1 ° marzo 2009, anche se l'intera data di creazione è stata il 1 ° gennaio. Quindi, puoi vedere, specialmente se la tua cache gira molto, i client che potrebbero utilizzare If -Le intestazioni modificate potrebbero ottenere più dati di quelli di cui hanno effettivamente bisogno, poiché il server PENSA che la risorsa sia cambiata, quando in realtà non lo è stata.

Se mantieni sincronizzata la data di creazione della cache con la data di creazione effettiva, questo può essere un problema minore.

Ma il punto è che è qualcosa su cui riflettere sull'intero problema al fine di essere un "buon cittadino web", e salvare te e i tuoi clienti potenzialmente un po 'di larghezza di banda ecc.

Ho appena passato tutto questo per un progetto Java che serve video da un DB, e tutto funziona a meraviglia.

Comprendo che la maggior parte dei professionisti del database incrociano le dita e ti sibilano se memorizzi immagini nel database (o addirittura lo menzioni). Sì, ci sono sicuramente implicazioni in termini di prestazioni e archiviazione quando si utilizza il database come repository per grandi blocchi di dati binari di qualsiasi tipo (le immagini tendono ad essere i bit di dati più comuni che non possono essere normalizzati). Tuttavia, ci sono certamente circostanze in cui l'archiviazione di immagini di database non è solo consentita ma consigliabile .

Ad esempio, nel mio vecchio lavoro avevamo un'applicazione in cui gli utenti avrebbero allegato le immagini a diversi punti di un rapporto che stavano scrivendo e quelle immagini dovevano essere stampate al termine. Questi report sono stati spostati tramite la replica di SQL Server e avrebbe introdotto un enorme mal di testa per provare a gestire queste immagini e percorsi di file su più sistemi e server con qualsiasi tipo di affidabilità. La loro memorizzazione nel database ci ha fornito tutto ciò che " gratuitamente, " e lo strumento di reporting non doveva uscire nel file system per recuperare l'immagine.

Il mio consiglio generale sarebbe di non limitarti a un approccio o all'altro - segui la tecnica adatta alla situazione. I file system sono molto bravi a archiviare i file e i database sono molto bravi a fornire blocchi di dati di dimensioni ridotte su richiesta. D'altra parte, uno dei prodotti della mia azienda ha l'obbligo di memorizzare l'intero stato dell'applicazione nel database, il che significa che anche gli allegati di file vanno lì. Con il nostro server DB (SQL Server 2005) non ho ancora riscontrato problemi di prestazioni osservabili anche con clienti e database di grandi dimensioni.

L'SQL 2008 di Microsoft ti offre il meglio dei due mondi con la funzione FileStream: vale la pena dare un'occhiata. http://technet.microsoft.com/en-us/library/bb933993.aspx

Uno dei vantaggi della memorizzazione delle immagini nel database è che è portatile su tutti i sistemi e indipendente dal layout del filesystem.

La soluzione più semplice / più performante / più scalabile è quella di archiviare le tue immagini sul file system. Se la sicurezza è un problema, inseriscili in una posizione non accessibile dal server Web e scrivi uno script che gestisca la sicurezza e fornisca i file.

Supponendo che il tuo server web / app e il server DB siano macchine diverse, otterrai alcuni hit inserendo le immagini nel DB: (1) latenza di rete tra le due macchine, (2) sovraccarico della connessione DB, (3) consumo una connessione DB aggiuntiva per ogni immagine servita. Sarei più preoccupato per l'ultimo punto: se il tuo sito offre molte immagini, i tuoi server web consumeranno molte connessioni DB e potrebbero esaurire i tuoi pool di connessioni.

Se la tua applicazione viene eseguita su più server, memorizzerei la copia di riferimento delle tue immagini nel database e poi li memorizzerei su richiesta nel filesystem. In questo modo è solo meno un errore soggetto a errori nel culo rispetto al tentativo di sincronizzare i filesystem lateralmente.

Se l'applicazione si trova su un singolo server, sì, attenersi al filesystem e fare in modo che il database mantenga un percorso per i dati.

Ovviamente la maggior parte dei database SQL non è progettata pensando alle immagini, ma c'è una certa comodità associata ad averle nel database.

Ad esempio, se si dispone già di un database in esecuzione e la replica è configurata. Hai immediatamente un archivio di immagini HA piuttosto che provare a lavorare con qualche replica di filesystem basata su rsync o nfs. Inoltre, avere un sacco di processi Web (o progettare alcuni nuovi servizi) per scrivere file su disco aumenta un po 'la tua complessità. In realtà sono solo più parti in movimento.

Per lo meno, consiglierei di conservare i 'meta' dati sull'immagine (come qualsiasi permesso, chi lo possiede, ecc.) e i dati effettivi separati in diverse tabelle, quindi sarà abbastanza facile passare a un diverso archivio dati lungo la linea. Questo accoppiato con una sorta di CDN o cache dovrebbe darti prestazioni abbastanza buone fino a un certo punto, quindi suppongo che dipenda da quanto deve essere scalabile questa applicazione e da come la bilanci con facilità di implementazione.

Non è necessario memorizzare l'URL (se ritieni che ciò non sia sicuro). Puoi semplicemente memorizzare un ID univoco che fa riferimento all'immagine altrove.

L'archiviazione del database tende ad essere più costosa e costosa da mantenere rispetto a un file system, quindi non archiverei MOLTE immagini in un database.

il ripristino di emergenza non è assolutamente divertente quando nel database sono presenti terabyte di dati immagine. Stai meglio trovare un modo migliore per distribuire i tuoi dati per renderli più affidabili, ecc ... Naturalmente tutto il sovraccarico (menzionato sopra) viene moltiplicato durante la replica e così via ...

Basta non farlo!

Sembra davvero un problema dei KISS (mantienilo stupido). I file system sono creati per gestire facilmente la memorizzazione di file di immagini, ma non è facile eseguirli in un database e confondere facilmente i dati. Perché subire un colpo alle prestazioni e tutte le difficoltà in sql e rendering quando puoi semplicemente preoccuparti della sicurezza dei file? Puoi anche gestire sistemi misti e con NFS o CIFS. I file system sono tecnologie mature. Molto più semplice, più robusto.

Ho archiviato immagini in un database per un'applicazione dimostrativa. La ragione per cui l'ho fatto è stata la sicurezza: cancellare un record che non avrei dovuto non era un grosso problema, ma cancellare un file che non avrei dovuto avrebbe potuto essere un problema!

Se le prestazioni fossero diventate un problema, avrei indagato se la cancellazione di file non autorizzati fosse una possibilità reale o meno.

Se sono immagini che vengono estratte regolarmente dal database, proverei sempre ad usare il filesystem.

Se fossero immagini che devono essere estratte di tanto in tanto e salvarle nel database semplifica la vita, non ho alcun problema con questo.

database per dati
filesystem per file

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow