Elaborazione di immagini da server SQL vs. file system vs. S3 ecc

La mia applicazione (classica asp yay!) Ha circa 2,1 milioni di immagini a 25 GB e questo rappresenta solo 90 giorni di dati e mi piacerebbe andare almeno 365. Devo tenerli sotto controllo e sto considerando tutte le opzioni. Cosa ne pensi dei pro e contro delle seguenti pratiche:

• Pro di SQL Server: facile da eseguire il backup Contro: prestazioni?
• Pro del file system: Velocità Contro: Ridondanza, Il backup è lento (attualmente la ricerca esegue backup completi sintetici invece che potrebbe migliorare)
• S3 e simili Pro: la larghezza di banda viene spostata dal mio datacenter ad Amazon, spazio di archiviazione praticamente illimitato. Contro: Costo, Analisi dei costi è complicata (stimare l'80% della mia larghezza di banda è immagini per scopi di ROI), Difficile / Costoso per swtich fornitori di servizi nel caso fosse necessario

Qualcun altro affronta la sfida multi-milioni di immagini e come l'ha affrontata?

Non abbiamo milioni di immagini, ma ne abbiamo centinaia di migliaia e utilizziamo l'approccio ibrido: mysql per metadati, immagini archiviate su disco locale per il backup e inviato ad Amazon s3 dove vengono servite agli utenti. Non abbiamo avuto problemi con Amazon e disponibilità. Passare al cloudfront è nei nostri piani, basta trovare il tempo.

Questa discussione può esserti utile nella tua decisione:
http://ask.metafilter.com/59635/Millions-of-images

Vorrei andare con metadati nel server SQL e file nel filesystem (o s3 o cloudfront). Ma la risposta migliore dipende da alcuni altri schemi di utilizzo:

• le immagini cambiano spesso
• puoi servire le immagini direttamente dal filesystem (cioè, img src="...") o hai bisogno che siano controllate dall'accesso? In quest'ultimo caso, una soluzione di database è la migliore
• stai servendo un piccolo numero di immagini per la maggior parte del tempo (il 10% più recente) o la distribuzione è relativamente diffusa.

I backup per milioni di immagini saranno complicati, indipendentemente da come li organizzi: sono solo molti dati. Vorrei trovare un buon caso di studio sul backup dei BLOB in SQL Server prima di dedicarmi a quella soluzione. (Ecco un articolo che potrebbe essere utile: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Se decidi di archiviarli nel file system, potresti voler leggere su questa domanda ServerFault per alcune cose da fare e da non fare: Memorizzare un milione di immagini nel file system .

Ignora le persone che dicono " Non archiviare immagini / dati binari nel database " poiché stanno basando le loro risposte su vecchie informazioni (supponendo che i dati verranno archiviati in una colonna di tipo VarBinary). Le prestazioni relative all'utilizzo di SQL Server per l'archiviazione delle immagini possono ora essere mitigate utilizzando il tipo di dati FILESTREAM in SQL Server 2008. In sostanza, il tipo di dati FILESTREAM consente di combinare la facilità di archiviazione dei dati nel database con le prestazioni ottenute dalla pubblicazione file da un archivio file NTFS.

Per citare SQL Mag :

"Il nuovo supporto FILESTREAM di SQL Server 2008 combina il vantaggio di accedere ai LOB direttamente dal file system NTFS con l'integrità referenziale e la facilità di accesso offerte dal motore di database relazionale di SQL Server."

Per maggiori informazioni leggi questo blog di Ravi S.Maniam su MSDN .

Anche se non mi occupo della sfida multi-milioni di immagini, utilizzerei Amazon CloudFront. Tutti i file sono archiviati in un bucket S3 ma sono server attraverso il sistema di consegna dei contenuti di Amazon. Non userei S3 da solo.

La mia seconda scelta sarebbe il file system. Semplice e facile, l'unico problema è che se tutti questi file finiscono in una directory tutto andrà in crash, difficile.

SQL per me non sarebbe un'opzione per un sistema come questo. Non solo vieni addebitato per il trasferimento della larghezza di banda, ma ti verrà addebitato anche per l'elaborazione della query - questo dipenderà molto dall'hosting, ma presumo che stai utilizzando un server dedicato o almeno un vps in cui ti verrà addebitato per cicli. Quindi rallenterà l'intero sito se utilizza lo stesso database del server di immagini. In caso contrario, aggiungi tutta questa complessità di dover gestire due connessioni al database.

I database sono progettati per dati / coerenza e sicurezza transazionali.

I file multimediali (immagini, audio, video) tendono a essere creati e forse eliminati, ma molto raramente aggiornati. Quindi in genere non è necessario mantenerli transazionalmente coerenti con altri dati e un database non ti darà alcun vantaggio reale lì. Il contenuto del testo potrebbe essere una questione diversa.

Finché non hai alcun problema con il concetto di qualcuno che tira direttamente il tuo file se hanno l'URL del file, allora un file system va bene. Se stavi eseguendo qualcosa come una libreria di foto, dove ti aspetti di caricare prima che le persone scarichino il file, probabilmente questa è una questione diversa. Cioè, una volta che un utente ha pagato, può ottenere un URL specifico per quell'utente o valido solo per un breve periodo di tempo e l'applicazione gestisce URL multipli o temporanei che puntano alla stessa immagine. Questo potrebbe essere ancora gestito dall'app e da un file system, ma finirai per servire i media attraverso l'applicazione piuttosto che come un download di file diretto (che escluderebbe principalmente qualsiasi vantaggio di S3) e c'è meno differenza tra DB e file system .