it-swarm.it

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. Ho bisogno di metterli sotto controllo e sto prendendo in considerazione tutte le opzioni. Cosa ne pensi dei pro e contro delle seguenti pratiche:

  • Pro di SQL Server: facile da eseguire 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 a fini 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'hai affrontata?

12
Webjedi

Non abbiamo milioni di immagini, ma ne abbiamo centinaia di migliaia e utilizziamo l'approccio ibrido: mysql per metadati, immagini archiviate sul disco locale per il backup e trasferito ad Amazon s3 dove vengono offerti 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 sul 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 (ovvero 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 )

6
mooreds

Ignora le persone che dicono " Non archiviare immagini/dati binari nel database " in quanto stanno basando le loro risposte su vecchie informazioni (supponendo che lo sarai memorizzazione dei dati in una colonna di tipo VarBinary). Le prestazioni relative all'utilizzo di SQL Server per l'archiviazione di 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 in il database con le prestazioni ottenute dalla pubblicazione di 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 .

3
Dan Diplo

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

3
Mark Henderson

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 tu stia utilizzando un server dedicato o almeno un vps dove 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.

2

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 e l'applicazione gestisce più o temporanei URL 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 .

1
Gary