Memorizza le immagini del profilo utente sul disco o nel database?

Question

Sto creando un'applicazione asp.net mvc in cui gli utenti possono allegare un'immagine al proprio profilo, ma anche in altre aree del sistema come un gadget di messaggistica sul dashboard che visualizza messaggi recenti ecc.

Quando l'utente carica questi mi chiedo se sarebbe meglio memorizzarli nel database o su disco.

vantaggi Databse

• semplice per il backup dell'intero database e tenere aggiornati i contenuti del profilo/immagini con associate le tabelle profilo/utente

• quando costruire servizi web più avanti lungo la pista, si può solo estrarre tutti i dati relativi profiile da un posto (il database)

Filesystem vantaggi

• caricamento dei file dal disco è probabilmente più veloce

• altri vantaggi?

Dove altri siti memorizzano questo tipo di informazioni. Ho ragione di essere un po 'preoccupato per le prestazioni del database per qualcosa di simile?

Forse ci sarebbe un modo per memorizzare le immagini estratte dal database per un periodo di tempo?

In alternativa, che dire dell'idea di archiviare queste immagini nel database, ma shadow copiandole su disco in modo che il web server possa caricarle da lì? Ciò sembrerebbe dare sia il backup che la convenienza di un Db, pur offrendo i vantaggi di velocità dei file su disco.

dell'infrastruttura in questione

• Il sito sarà distribuito a IIS in Windows Server 2003 che esegue il file system NTFS.
• Il database sarà SQL Server 2008

Sommario

leggendo in giro su un sacco di fili collegati qui su SO, molte persone sono ora trend verso il tipo di SQL Server Filestream. Tuttavia, da quello che potrei raccogliere (potrei sbagliarmi), non c'è molto vantaggio quando i file sono piuttosto piccoli. Tuttavia, Filestreaming sembra migliorare notevolmente le prestazioni quando i file sono multipli o più di un MB.

Poiché le immagini del mio profilo tendono a circa 5kb, ho deciso di lasciarle memorizzate nel filestore nel database come varbinary (max).

In ASP.NET MVC ho visto un po 'di un problema di prestazioni restituendo FileContentResults per le immagini estratte dal database come questo. Così ho finito con la cache del file su disco quando viene letto se la posizione di questo file non si trova nella cache dell'applicazione.

Quindi immagino di essere stato un ibrido;

• archiviazione database per rendere la cottura da dati più facili e file sono collegati direttamente ai profili
• Ombra copia su disco per consentire una migliore caching

In qualsiasi momento posso cancellare la cartella della cache su disco e siccome le immagini vengono richieste nuovamente, saranno copiate nuovamente al primo colpo e servite dalla cache lì dopo.

Answer 1

In realtà il tuo datastore cerca con il database in realtà potrebbe essere più veloce a seconda del numero di immagini che hai, a meno che tu non stia utilizzando un motore di filesystem altamente ottimizzato. I database sono progettati per ricerche veloci e usano un sacco di tecniche più interessanti di un file system.

reiserfs (obsoleto) davvero fantastico per le ricerche, zfs, xfs e NTFS hanno tutti fantastici algoritmi di hashing, anche il linux ext4 sembra promettente.

L'impatto sul sistema non sarà diverso in termini di letture di blocchi. La domanda è: cosa è più veloce una ricerca di query che restituisce il nome del file (potrebbe essere un hash?) A cui si accede a sua volta utilizzando un open separato, fine file fine? o semplicemente scaricando il blob?

Ci sono diverse cose da considerare, tra cui hit della rete, hit dell'elaborazione, distribuibilità, ecc. Se memorizzi elementi nel database, puoi spostarli. Poi di nuovo, se memorizzi le immagini su un servizio di consegna di contenuti che potrebbe essere PIÙ veloce poiché non stai facendo alcun contatto di rete su te stesso.

Pensateci, e ricordare po 'di analisi comparativa mai fatto male a nessuno :-) così provarlo con il formato tipico insieme di dati e prendere in considerazione le cose come le query simultanee ecc

Answer 2

Conservare i riferimenti ai file su un database e memorizzare i file stessi sul disco.

Questo approccio è molto più flessibile e più semplice da scalare.

È possibile avere un singolo database e diversi server che servono contenuto statico. Sarà molto più complicato avere diversi database che lo fanno funzionare.

Flickr funziona in questo modo.

Spero che aiuti.