Mid-Large Asp.net Progetto MVC: archiviazione di immagini su file system o tramite SQL Server FILESTREAM [duplicato]

1

Abbiamo un progetto MVC ASP.NET con database AngularJS ed Entity Framework, un portale di notizie già in produzione da circa un anno. Il progetto è principalmente incentrato sulla fornitura di contenuti per gli utenti (articoli, notizie e così via) e naturalmente ci sono molte immagini. Attualmente stiamo archiviando le immagini nel File System e in SQL Server memorizziamo solo il percorso.

Il sito oggi ha qualcosa come più di 2000 immagini (ogni giorno vengono caricate molte nuove immagini in modo che questo numero possa crescere molto velocemente). Le dimensioni delle immagini sono nella media di 1 MB (ma possono anche essere maggiori).

Il nostro cliente ha richiesto (davvero non conosciamo le ragioni ...) per noi per iniziare a salvare le immagini all'interno del database, utilizzando FILESTREAM di SQL Server. Come azienda, non avevamo mai sviluppato alcun progetto utilizzando questa tecnologia. Sappiamo già che la memorizzazione di BLOB (come VARCHAR (MAX)) è un approccio davvero brutto, ma che ne è di FILESTREAM? Ne vale veramente la pena?

Gli obiettivi principali sono:

  • FILESTREAM offrirà prestazioni migliori nel tempo?
  • E il modo di gestire (salvare, recuperare) le immagini? È molto diverso dall'usare System.IO.File?
  • E EntityFramework 5? È compatibile? (Impossibile trovare risposte effettive per questo su Internet)

L'utente può caricare fino a 10mb. Inoltre, abbiamo in programma di far caricare anche file (.pdf, .doc, .xls, anche .mp3 max 10mb)

    
posta jpgrassi 14.11.2014 - 14:22
fonte

1 risposta

1

Dato che stai parlando di immagini nel contesto di un portale di notizie, immagino che quelle immagini siano JPEG di piccole dimensioni, non file RAW che possono facilmente avere dimensioni di 30 MB. In tal caso, FILESTREAM non sarà raccomandato, perché il suo scopo principale è quello di ospitare file grandi all'interno del database.

For smaller objects (less than 1MB), storing varbinary(max) BLOBs in the database can provide better streaming performance.

Fonte: Best practice sulle implementazioni di FILESTREAM

FILESTREAM ha uno dei principali vantaggi: puoi archiviare grandi quantità di dati senza essere limitato dalla quantità di memoria sul tuo server. Memorizzando questi dati all'interno del database invece del semplice file system, è possibile unificare la gestione dei dati. Ad esempio, gli amministratori di sistema possono definire la strategia di backup una sola volta per il database e non devono creare una strategia di backup duplicata per i file semplici.

Ma il beneficio si ferma qui. In altre parole, ottieni prestazioni quasi identiche a quelle che puoi ottenere con file semplici e il vantaggio di una singola strategia, ma non c'è niente di più lì.

Se non hai bisogno di questa gestione unificata dei dati, non utilizzare FILESTREAM. Sfortunatamente, FILESTREAM è sopravvalutato nella comunità Microsoft, portando molte persone a usarlo in progetti che non ne hanno bisogno.

FILESTREAM will offer better performance over time?

Uno dei vantaggi che riesco a vedere è che non dovrai più interrogare il percorso del file. A parte questo, non vedrai un vantaggio nell'uso di FILESTREAM rispetto all'accesso diretto a un file, perché aggiungerai semplicemente un livello di complessità.

Fai attenzione all'ubicazione esatta dei tuoi file effettivi e alla possibile posizione dei file FILESTREAMed: se al momento i file sono archiviati localmente e in FILESTREAM verranno spostati nelle macchine che bloccheranno SQL Server, dovrai considerare l'utilizzo della larghezza di banda tra i server delle app e i server del database.

What about the way to manage (save, retrieve) images? Is it a lot of different than using System.IO.File ?

No. L'accesso ai file è davvero semplice e simile al modo in cui accedi a un file ordinario. Puoi trovare facilmente gli esempi su MSDN.

What about EntityFramework 5? Is it compatible? (Couldn’t really find actual answers for this on the internet)

Non era ancora supportato nel 2011. Non so se le cose sono cambiate da allora, ma in tutto casi, probabilmente eluderai Entity Framework se hai bisogno di accedere ai dati memorizzati in un FILESTREAM (che non sarà difficile neanche).

    
risposta data 14.11.2014 - 14:37
fonte

Leggi altre domande sui tag