Utilizzo di SQL Server come archivio di 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 emetterebbe quelle immagini, leggendo la tabella con un ID cluster. La dimensione totale dell'immagine sarebbe di circa 10 GB, ma sarà necessario ridimensionarla. Vedo molti vantaggi sull'utilizzo 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 a bottiglia? Quali sono alcuni pensieri o forse altre opzioni?

Answer 1

10 Gb non è una quantità enorme di dati, quindi è possibile utilizzare il database per archiviarlo e non avere grossi problemi, ma naturalmente è meglio utilizzare le prestazioni del file system e la gestione della sicurezza è meglio utilizzare il DB (backup e coerenza).

Fortunatamente, SQL Server 2008 consente di avere la botte piena e la moglie ubriaca, con:

The FILESTREAM Attribute

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

• Le prestazioni corrispondono alle prestazioni di streaming del file system.
• La dimensione del BLOB è limitata solo dalla dimensione del volume del file system.

Tuttavia, la colonna può essere gestita come qualsiasi altra colonna BLOB in SQL Server, per cui 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 -non è necessario 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, integrazione completa 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 semantica transazionale Transact-SQL per garantire coerenza, il che significa che possono utilizzare chiamate di lettura/scrittura Win32 standard a FILESTREAM I BLOB come farebbero se interagissero con i file sul file system.

In SQL Server 2008, le colonne FILESTREAM possono solo archiviare dati su volumi disco locali e alcune funzioni come la crittografia trasparente e i parametri con valori di tabella non sono supportate per le colonne FILESTREAM. Inoltre, non è possibile utilizzare tabelle contenenti colonne FILESTREAM negli snapshot del database o nelle sessioni di mirroring del database, sebbene sia supportata la distribuzione dei log.

Answer 2

Per qualcosa di simile a un sito Web di e-commerce, sarei probabilmente disposto a memorizzare l'immagine in un archivio BLOB nel database. Sebbene tu non voglia intraprendere un'ottimizzazione prematura, solo il vantaggio di avere le mie immagini facilmente organizzate insieme ai miei dati, oltre che molto portabile, è un vantaggio automatico per qualcosa come l'e-commerce.

Answer 3

Se le immagini sono indicizzate, la ricerca non sarà un grosso problema. Non sono sicuro, ma non penso che la ricerca del file system sia O (1), più simile a O (n) (non penso 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 si ha solo una cosa da fare il backup (il database) e non preoccuparsi sui file sul disco.

Answer 4

Normalmente una buona soluzione è quella di archiviare le immagini sul filesystem e i metadati (nome del file, dimensioni, ultimo aggiornamento, qualsiasi altra cosa necessaria) nel database.

Detto questo, non c'è una soluzione "corretta" a questo.

Answer 5

Partenza questo white paper da MS Research (http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45)

Essi dettaglio esattamente quello che stai cercando. La versione breve è che qualsiasi dimensione del file superiore a 1 MB inizia a peggiorare le prestazioni rispetto al salvataggio dei dati sul file system.

Answer 6

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

Vale sempre la pena considerare i normali vantaggi e svantaggi dell'archiviazione delle immagini in un database rispetto ai percorsi di memorizzazione nel database per i file sul filesystem. Per esempio:

• Immagini in isolamento delle transazioni database di obbedire, eliminare automaticamente quando la riga viene eliminata, ecc
• database con 10GB di immagini è ovviamente più grande di un database contenente solo i nomi di percorso per i file di immagine. La velocità di backup e altri fattori sono rilevanti.
• È necessario impostare le intestazioni MIME sulla risposta quando si serve un'immagine da un database, tramite un'applicazione.
• Le immagini su un filesystem sono più facilmente memorizzate nella cache dal server web (ad esempio Apache mod_mmap), o potrebbero essere servite da un server web snello come lighttpd. Questo è in realtà un grande vantaggio.