Utilizzo di SQL Server come archivio immagini

Question

SQL Server 2008 è una buona opzione da utilizzare come archivio di immagini per un sito Web di e-commerce? Sarebbe usato per memorizzare immagini di prodotti di varie dimensioni e angoli. Un server Web produrrebbe tali immagini, leggendo la tabella con un ID cluster. La dimensione totale dell'immagine sarebbe di circa 10 GB, ma dovrà essere ridimensionata. Vedo molti vantaggi sull'uso del file system, ma sono preoccupato che il server SQL, non avendo una ricerca O (1), non sia la soluzione migliore, dato che il sito ha molto traffico. Sarebbe anche un collo di bottiglia? Quali sono alcuni pensieri o forse altre opzioni?

Answer 1

10 Gb non è una quantità enorme di dati, quindi probabilmente puoi usare il database per archiviarlo e non avere grossi problemi, ma ovviamente è meglio usare il filesystem in termini di prestazioni, e saggia gestione della sicurezza è meglio utilizzare il DB (backup e coerenza).

Fortunatamente, Sql Server 2008 ti permette di avere la tua torta e anche di mangiarla, con:

L'attributo FILESTREAM

In SQL Server 2008, è possibile applicare l'attributo FILESTREAM a una colonna varbinary, quindi SQL Server memorizza i dati per quella colonna sul file system NTFS locale. La memorizzazione dei dati nel file system comporta due vantaggi principali:

• Le prestazioni corrispondono alle prestazioni di streaming del file system.
• Le dimensioni BLOB sono limitate solo dalle dimensioni del volume del file system.

Tuttavia, la colonna può essere gestita come qualsiasi altra colonna BLOB in SQL Server, quindi gli amministratori possono utilizzare le funzionalità di gestibilità e sicurezza di SQL Server per integrare la gestione dei dati BLOB con il resto dei dati nel database relazionale & # 8212; senza la necessità di gestire i dati del file system separatamente.

La definizione dei dati come colonna FILESTREAM in SQL Server garantisce inoltre la coerenza a livello di dati tra i dati relazionali nel database e i dati non strutturati archiviati fisicamente nel file system. Una colonna FILESTREAM si comporta esattamente come una colonna BLOB, il che significa piena integrazione delle operazioni di manutenzione come backup e ripristino, completa integrazione con il modello di sicurezza di SQL Server e supporto completo delle transazioni.

Gli sviluppatori di applicazioni possono lavorare con i dati FILESTREAM attraverso uno dei due modelli di programmazione; possono utilizzare Transact-SQL per accedere e manipolare i dati proprio come le colonne BLOB standard, oppure possono utilizzare le API di streaming Win32 con la semantica transazionale Transact-SQL per garantire coerenza, il che significa che possono utilizzare le chiamate di lettura / scrittura Win32 standard a FILESTREAM BLOB come farebbero se interagissero con i file sul file system.

In SQL Server 2008, le colonne FILESTREAM possono archiviare dati solo sui volumi del disco locale e alcune funzionalità come la crittografia trasparente e i parametri con valori di tabella non sono supportate per le colonne FILESTREAM. Inoltre, non è possibile utilizzare tabelle che contengono colonne FILESTREAM nelle istantanee del database o sessioni di mirroring del database, sebbene sia supportata la distribuzione dei log.

Answer 2

Dai un'occhiata a questo white paper di MS Research ( http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 )

Descrivono esattamente ciò che stai cercando. La versione breve è che qualsiasi dimensione di file superiore a 1 MB inizia a degradare le prestazioni rispetto al salvataggio dei dati sul file system.

Answer 3

Dubito che O (log n) per le ricerche sarebbe un problema. Dici di avere 10 GB di immagini. Supponendo una dimensione media dell'immagine di 50 KB, ovvero 200.000 immagini. Fare una ricerca indicizzata in una tabella per 200K righe non è un problema. Sarebbe piccolo rispetto al tempo necessario per leggere effettivamente l'immagine dal disco e trasferirla attraverso la tua app e sul client.

Vale comunque la pena considerare i soliti pro e contro della memorizzazione di immagini in un database piuttosto che la memorizzazione di percorsi nel database su file nel filesystem. Ad esempio:

• Le immagini nel database obbediscono all'isolamento della transazione, vengono eliminate automaticamente quando viene eliminata la riga e così via
• Il database con 10 GB di immagini è ovviamente più grande di un database che archivia solo i percorsi nei file di immagini. La velocità di backup e altri fattori sono rilevanti.
• Devi impostare le intestazioni MIME sulla risposta quando servi un'immagine da un database, attraverso un'applicazione.
• Le immagini su un filesystem sono più facilmente memorizzate nella cache dal server web (ad es. Apache mod_mmap), oppure potrebbero essere servite da un server web più snello come lighttpd. Questo è in realtà un grande vantaggio.

Answer 4

Per qualcosa di simile a un sito Web di e-commerce, è molto probabile che vada con la memorizzazione dell'immagine in un archivio BLOB nel database. Anche se non vuoi impegnarti nell'ottimizzazione prematura, solo il vantaggio di avere le mie immagini facilmente organizzabili insieme ai miei dati, oltre che molto portatile, è un vantaggio automatico per qualcosa come l'e-commerce.

Answer 5

Se le immagini sono indicizzate, la ricerca non sarà un grosso problema. Non sono sicuro ma non credo che la ricerca del file system sia O (1), più o meno O (n) (non credo che i file siano indicizzati dal file system).

Ciò che mi preoccupa in questa configurazione è la dimensione del database, ma se gestito correttamente non sarà un grosso problema, e un grande vantaggio è che hai solo una cosa di cui fare il backup (il database) e di cui non preoccuparti file su disco.

Answer 6

Normalmente una buona soluzione è quella di archiviare le immagini stesse sul filesystem e i metadati (nome del file, dimensioni, ora dell'ultimo aggiornamento, qualsiasi altra cosa di cui hai bisogno) nel database.

Detto questo, non esiste " corretto " soluzione a questo.