memorizzazione delle immagini su un database

Question

Eventuali duplicati:
Storing Images in DB - Yea or Nay?

Per anni mi è stato detto di non memorizzare le immagini nel database, o qualsiasi grande BLOB per quella materia. Mentre capisco perché i database non sono/non sono efficienti per questo non ho mai capito perché non potevano. Se riesco a mettere un file da qualche parte e fare riferimento, perché il motore di database non può fare lo stesso. Sono lieto che Damien Katz ne abbia parlato in un recente podcast di Stack Overflow e Joel Spolsky e Jeff Atwood, almeno in silenzio, hanno concordato.

Ho letto suggerimenti che Microsoft SQL Server 2008 dovrebbe essere in grado di gestire i BLOB in modo efficiente, è vero? In tal caso, cosa ci impedisce di archiviare le immagini e di eliminare un problema? Una cosa che posso pensare è che mentre l'immagine può essere servita da un server web statico molto velocemente se si tratta di un file da qualche parte, quando è nel database deve spostarsi dal database all'applicazione del server web (che potrebbe essere più lento di il server web statico) e quindi viene servito. Non dovrebbe aiutare nella cache/risolvere l'ultimo problema?

Answer 1

Sì, è vero, SQL Server 2008 ha appena implementato una funzionalità come quella che hai citato, si chiama "filestream". Ed è un buon argomento, infatti, per la memorizzazione di BLOB in un DB, se sei sicuro di voler utilizzare SQL Server solo per la tua app (o sei disposto a pagare il prezzo in entrambe le prestazioni o nello sviluppo di un livello simile in cima al nuovo Server DB). Anche se mi aspetto che i layer simili inizieranno ad apparire se non esistono già per diversi server DB.

Come sempre, quali sarebbero i reali benefici dipendono dallo scenario particolare. Se servirai molti file relativamente statici e di grandi dimensioni, allora questo scenario più il caching sarà probabilmente l'opzione migliore considerando una combinazione di prestazioni/gestibilità.

This white paper descrive la funzionalità FILESTREAM di SQL Server 2008, che consente l'archiviazione e un accesso efficiente ai dati BLOB utilizzando una combinazione di SQL Server 2008 e del file system NTFS. Comprende le scelte per l'archiviazione BLOB, la configurazione di Windows e SQL Server per l'utilizzo dei dati FILESTREAM, considerazioni sulla combinazione di FILESTREAM con altre funzionalità e dettagli di implementazione come il partizionamento e le prestazioni.

Answer 2

Ci sono opzioni all'interno di SQL Server per gestire la posizione in cui memorizza grandi quantità di dati, poiché sono presenti in Lease SQL2005, quindi non so perché non è possibile archiviare grandi BLOB di dati. Ad esempio, MOSS memorizza tutti i documenti che carichi in un database SQL.

Ci sono naturalmente alcune implicazioni sulle prestazioni, come per qualsiasi cosa, quindi è necessario fare attenzione a non ritirare il BLOB se non ne ha bisogno, e non includerlo negli indici, ecc.

Answer 3

Solo perché puoi fare qualcosa non significa che dovresti.

Se ci si preoccupa dell'efficienza, è molto probabile che non vogliate farlo per una porzione di file sufficientemente grande.

Anche sembra che questo argomento sia stato ampiamente discusso ...

• duplicato esatto: User Images: Database or filesystem storage?
• duplicato esatto: Storing images in database: Yea or nay?
• duplicato esatto: Should I store my images in the database or folders?
• duplicato esatto: Would you store binary data in database or folders?
• duplicato esatto: Store pictures as files or or the database for a web app?
• duplicato esatto: Storing a small number of images: blob or fs?
• duplicato esatto : store image in filesystem or database?

Answer 4

Uno dei motivi classici per cautela sulla memorizzazione blob nei database è che i dati verranno memorizzati e modificati (modificato) sotto il controllo dell'operazione, il che significa che il DBMS deve garantire che possa far ritirare modifiche e recuperare le modifiche dopo un arresto anomalo. Questo è normalmente fatto da qualche variazione sul tema di un log delle transazioni. Se il DBMS deve registrare la modifica in un blob da 2 GB, deve avere un modo per identificare ciò che è cambiato. Ciò potrebbe essere semplice (l'immagine precedente e l'immagine successiva) o più sofisticata (una sorta di operazione delta binaria) che è più dispendiosa dal punto di vista computazionale. Anche così, a volte il risultato netto sarà gigabyte di dati da memorizzare attraverso i registri. Ciò danneggia le prestazioni del sistema. Esistono vari modi per limitare l'impatto delle modifiche, riducendo la quantità di dati che scorre attraverso i registri, ma ci sono dei compromessi.

La penalità per la memorizzazione dei nomi file nel database è che il DBMS non ha alcun controllo (in generale) su quando i file cambiano, e quindi di nuovo, la riproducibilità dei dati è compromessa; non puoi garantire che qualcosa al di fuori del DBMS non abbia cambiato i dati. (C'è una versione molto generale di questo argomento - non si può essere sicuri che qualcuno non abbia manomesso i file di archiviazione del database in generale, ma mi riferisco alla memorizzazione di un nome di file nel database che fa riferimento a un file non controllato dal DBMS. i file controllato dal DBMS sono protetti contro il cambiamento casuale dal non privilegiato.)

la nuova funzionalità di SQL Server sembra interessante. Non ho esplorato ciò che fa, quindi non posso commentare fino a che punto evita o limita i problemi di cui sopra.

Answer 5

Cercherò di scomporre la tua domanda e soddisfare le vostre varie parti come meglio posso.

• SQL Server 2008 e il tipo di Filestream - la risposta di Vinko sopra è il migliore che ho visto finora. Il tipo Filestream è SQL Server 2008 è ciò che stavi cercando. Filestream è in versione 1 quindi ci sono ancora alcuni motivi per cui non consiglierei l'uso se per un'applicazione aziendale. Ad esempio, il mio ricordo è che non è possibile dividere la memorizzazione dei file fisici sottostanti su più percorsi UNC di Windows. Prima o poi diventerà un limite piuttosto serio per un'app aziendale.

• Memorizzazione dei file nel database - Nello schema grandioso delle cose, direzione originale di Damien Katz era corretta. La maggior parte dei grandi player di content management (ECM) archivia i file sul filesystem e i metadati nell'RDBMS. Se si va ancora più in grande e si guarda al servizio S3 di Amazon, si guardano i file fisici con un back-end database non relazionale. A meno che tu non stia misurando i tuoi file in memoria a miliardi, non ti consiglierei di seguire questa strada e farla da sola.

• Un po 'più dettagli sui file nel database - A prima vista, molte cose parlano di file nel database. Uno è la semplicità, due è l'integrità transazionale. Poiché il file system di Windows non può essere incluso in una transazione, le scritture che devono essere eseguite nel database e nel filesystem devono avere una logica di compensazione delle transazioni integrata. Non ho visto l'altro lato della storia finché non ho parlato con gli amministratori di database. In genere non gradiscono la combinazione di dati aziendali e BLOB (il backup diventa doloroso) quindi, a meno che non si disponga di un database separato dedicato all'archiviazione di file, questa opzione non è generalmente allettante per gli amministratori di database. Hai ragione che il database sarà più veloce, a parità di altre condizioni. Non conoscendo il caso d'uso per la tua applicazione, non posso dire molto sull'opzione di caching. Basti dire che in molte applicazioni aziendali, il tasso di hit cache sui documenti è troppo basso per giustificare la memorizzazione nella cache.

Spero che questo aiuti.