Memorizzare un numero limitato di immagini: blob o fs?

Question

Sto aggiungendo alcune funzionalità al mio sito in modo che gli utenti possano caricare le proprie foto del profilo, quindi mi chiedevo se memorizzarle nel database come BLOB o inserirle nel file system.

Ho trovato una domanda simile a questa qui: Memorizzazione delle immagini nel DB: Sì o Nay , ma le risposte fornite erano più orientate verso le persone che si aspettavano molte migliaia o addirittura milioni di immagini, mentre io sono più preoccupato per le piccole immagini (JPEG fino a forse 150x150 pixel) e per un piccolo numero di esse: forse fino a uno o duemila.

Quali sono i sentimenti di DB BLOB vs Filesystem per questo scenario? In che modo i client vanno con la memorizzazione nella cache delle immagini dal DB rispetto al filesystem?

Se i BLOB archiviati nel DB sono la strada da percorrere - c'è qualcosa che dovrei sapere su dove per memorizzarli? Poiché immagino che la maggior parte dei miei utenti non stia caricando una foto, dovrei creare una tabella user_pics per (esterna) unirmi alla normale tabella utenti quando necessario?

---

Modifica: sto riaprendo questa domanda, perché è non un duplicato di quei due a cui sei collegato. Questa domanda riguarda in particolare i pro / contro dell'utilizzo di un DB o FS per un PICCOLO numero di immagini. Come ho detto sopra, l'altra domanda è rivolta alle persone che devono archiviare migliaia e migliaia di immagini di grandi dimensioni.

Answer 1

Per rispondere a parti della tua domanda:

  

Come vanno i client con la memorizzazione nella cache delle immagini dal DB rispetto al filesystem?

Per un database: disporre di un campo last_modified nel database. Utilizzare l'intestazione HTTP Ultima modifica in modo che il browser del client possa memorizzare correttamente nella cache. Assicurati di inviare le risposte appropriate quando il browser richiede un'immagine "se più recente" (non ricordo come si chiama; qualche intestazione di richiesta HTTP).

Per un filesystem: fai la stessa cosa, ma con l'ora modificata del file.

  

Se i BLOB archiviati nel DB sono la strada da percorrere - c'è qualcosa che dovrei sapere su dove memorizzarli? Poiché immagino che la maggior parte dei miei utenti non stia caricando un'immagine, dovrei creare una tabella user_pics per (esterna) unirmi alla tabella degli utenti normali quando necessario?

Vorrei mettere BLOB e i metadati correlati nella sua tabella, con una sorta di relazione tra esso e la tua tabella utente. In questo modo sarà più semplice ottimizzare il metodo di archiviazione della tabella per i tuoi dati, rendere le cose più ordinate e lasciare spazio per l'espandibilità (ad esempio una tabella generale "file").

Answer 2

Una volta ho affrontato una domanda simile con un piccolo DMS per file pdf. Lo scenario era diverso dal tuo: un massimo di 100 file con dimensioni fino a 10 MB ciascuno - non quello che ti aspetti dalle immagini del profilo. Ma la risposta che mi ha dato un amico si applica anche al tuo caso:

  

Usa ogni sistema di archiviazione per quello per cui è progettato.

     

Memorizza dati in un database . Memorizza file in un file system .

Questa non è la risposta definitiva (*), ma è una buona regola empirica per i principianti.

Non ho mai sentito parlare di Windows FS lento e talvolta inaffidabile, come afferma Aaron Digulla nella sua risposta. Se ci sono problemi del genere, è necessario tenerne conto. Ma per le foto di avatar non mi sembra importante.

(*) Lo so, lo so, 42 ...

Answer 3

Cosa sarebbe più conveniente, dal punto di vista del servizio, della scrittura del codice per servirli, delle procedure di backup, ecc.? Vuoi la risposta giusta per te, non la risposta giusta per qualcun altro.

Answer 4

Dal mio punto di vista tutto ciò che può essere lasciato al di fuori del database dovrebbe rimanere all'esterno. Può essere un file system o tabelle separate che non si replicano o si esegue il backup ogni giorno. Rende il database molto più leggero, diventa più lento e più facile da capire e mantenere.

Se si utilizza MSSQL, assicurarsi che i BLOB siano archiviati in un file di dati separato. Non in PRIMARY come tutto il resto.

Answer 5

Su Windows, inserisci il più possibile nel database. Il filesystem è piuttosto lento e talvolta persino inaffidabile.

Su Linux, hai più opzioni. Qui, dovresti considerare di spostare file di grandi dimensioni in un filesystem e mantenere il nome nel DB. Se usi un filesystem moderno come Ext3 o ReiseFS, puoi persino creare molti piccoli file con prestazioni piuttosto buone.

Devi anche tener conto di come puoi accedere ai dati. Se nel DB è presente tutto, si dispone di un percorso di accesso, non è necessario preoccuparsi di un'altra serie di autorizzazioni, ma è necessario gestire la complessità aggiuntiva della lettura / scrittura dei BLOB. In molti DB, i BLOB non possono essere cercati.

Sul filesystem, puoi eseguire altri strumenti sui tuoi dati, cosa impossibile se i file sono memorizzati in un DB.

Answer 6

Li memorizzerei nel database:

1. Il backup / ripristino è semplice (se si esegue il backup dei file e anche del database, il recupero temporizzato è più complicato)
2. Le transazioni nel db significano che non dovresti mai finire per indicare un nome file che non è presente
3. Meno possibilità che qualcuno abbia intenzione di escogitare un modo subdolo di inserire uno script sul tuo server tramite un trucco di caricamento delle immagini ingannevole

Dato che stai parlando di un numero limitato di immagini, la facilità d'uso / amministrazione dovrebbe privilegiare i problemi di prestazioni che sono discussi nelle domande collegate.

Answer 7

Penso che ci sia un vantaggio di gestibilità memorizzandoli nel database; possono essere sottoposti a backup e ripristinati in modo coerente con gli altri dati: non dimenticherai di eliminare quelli obsoleti (beh, potresti, ma è un po 'meno probabile), e se esegui la migrazione del database su un altro computer, le immagini vanno con esso.