Immagini nel database rispetto al file system

Question

Abbiamo un progetto in arrivo in cui costruiremo un intero sistema CMS backend che alimenterà tutta la nostra extranet e intranet con un unico pacchetto.La domanda a cui sto cercando di trovare una risposta è: quale è meglio:memorizzare le immagini nel database (SQL Server 2005) in modo da poter avere integrità, piano di replica singolo, ecc. OPPURE memorizzare nel file system?

Un problema che abbiamo è che abbiamo più server bilanciati nel carico che richiedono di avere sempre gli stessi dati.Al momento abbiamo la replica SQL che si occupa di questo, ma la replica dei file sembra essere un po' più difficile.Un'altra preoccupazione che abbiamo è che vorremmo avere più risoluzioni della stessa immagine, non siamo sicuri se creare e archiviare ciascuna versione sul file system sarebbe la soluzione migliore o magari estrarre e creare dinamicamente l'immagine con la risoluzione che vorremmo su richiesta.

Le nostre preoccupazioni sono le seguenti:

• Integrità dei dati
• Replica dei dati
• Risoluzioni multiple
• Velocità del database rispetto al file system
• Carico eccessivo del database rispetto al file system
• Gestione e backup dei dati

Qualcuno ha una situazione simile o ha qualche suggerimento su cosa sarebbe consigliabile?Grazie in anticipo per l'aiuto!

Answer 1

C'è stato un bel documento di ricerca pubblicato da Microsoft Research chiamato Per Blob o non Blob dove hanno guardato tutti i tipi di variabili e gli impatti.

La loro scoperta alla fine:

• fino a 256 KB di dimensione, blob vengono memorizzati nel database in modo più efficiente rispetto al file system
• per 1 MB e più grande, il file system è più efficiente
• in mezzo è un lancio-up

Da quel documento è stato pubblicato, SQL Server 2008 ha anche aggiunto l'attributo FILESTREAM che rende la memorizzazione roba nel file system, ma sotto controllo transazionale, una realtà. Consiglia vivamente di verificare che fuori!

Answer 2

Questa domanda viene spesso - vedi questo SO risultato della ricerca

.

Non c'è una risposta giusta -. Dipende dalle circostanze

Personalmente - mantenere un percorso di file nel DB e il file sul filesystem. Ognuno ha i suoi punti di forza. È possibile backup dei file e database. Questa è anche la conclusione di questo ragazzo, che gestisce TB di dati.

Answer 3

La replica di file statici, in particolare attraverso un certo numero di server, può essere difficile da gestire. Si tratta in realtà fino ad un compromesso tra la gestione, il monitoraggio e il debug dei problemi di replica contro la dimensione del database e del carico.

Credo che avrei probabilmente scegliere il metodo di database, e se il carico è diventato un problema guardo mettendo su una sorta di strato di cache intorno alle chiamate di immagini.

Suggerimenti per memorizzare un percorso nel db mancano il vero problema, che è replicando questo su più macchine.

Answer 4

Le vostre preoccupazioni si suddividono in due campi. I seguenti preoccupazioni favoriscono la memorizzazione dei documenti nel database:

• L'integrità dei dati
• replica dei dati
• Più risoluzioni
• Gestione dei dati e di backup

Queste preoccupazioni (probabilmente) i documenti favore la memorizzazione nel file system:

• Velocità della banca dati vs file system
• carico ambientale della banca dati vs file system

Quindi, decidere ciò che conta di più e scegliere di conseguenza.

Answer 5

Bene, se le tue due esigenze principali sono integrità e replica, la risposta è sicuramente DB.

Altri punti però:

• Integrità - DB, ecco perché esistono i database vs.sistemi di file flat.

• Replica: non sono sicuro che intendi la replica dell'immagine, ma se è così, ovviamente DB poiché sicuramente non bilancerai il carico.

• È possibile eseguire più risoluzioni dall'immagine DB, tuttavia ciò comporta costi di elaborazione aggiuntivi.Inoltre, maggiore è la risoluzione, maggiore è la dimensione, maggiore sarà il tempo di attesa della rete.Risoluzioni multiple scambiano spazio con velocità.

• Velocità: a seconda dell'accesso alle immagini, potrebbe essere trascurabile.Se stai scattando immagini attraverso una condivisione di file, dovrai comunque attendere sulla rete e la rete è praticamente sempre il collo di bottiglia.

• Spese generali: francamente, dipende dalla tua definizione di spese generali e da come accedi alle immagini.

• Gestione, DB, senza dubbio.Archiviazione singola = una preoccupazione in meno e in ogni caso dovresti sempre eseguire i backup sul database.I backup del file system su più server sono costosi sotto molti aspetti.

Answer 6

Non ci sono preoccupazioni valide su entrambi i lati del dibattito, in modo sempre dare le vostre esigenze. La quantità di dati, quante immagini, quanto è grande?

Inline / storage BLOB

inversa : semplifica l'architettura e l'implementazione, semplifica il backup e ripristino o migrazione del sistema; basta fare una discarica, il backup, l'esportazione (qualunque sia il termine per il sapore della DB) e spostarlo nel nuovo database. La versione di controllo / consistenza è gestito da DB, in modo da permette il recupero point-in-time. controllo / accesso di sicurezza è anche più pulito, poiché l'accesso ad un blob immagine è intrinseco per accedere alla riga complessiva. Spostare l'immagine al di fuori del DB e lasciando che il server HTTP prenderlo in su, mentre meglio per la concorrenza e la scalabilità, possono avere problemi con assicurando la gente non può incidere URL e immagini di richiesta cui non sono proprietari. Se li casa fuori DB, assicurarsi che sia i criteri di sicurezza si estende il controllo degli accessi di immagini tra gli utenti. Sia l'autenticazione server HTTP deve integrare con l'autenticazione del sistema nel suo complesso, o il vostro programma server HTTP che serve le immagini utilizza una sorta di meccanismo di sessione per garantire la richiesta HTTP è valido. Questo è un grande preoccupazione nei database multi-tenant. Meno di una preoccupazione in unico scopo, i sistemi single-tenant, con l'autenticazione semplice.

Downside : Per davvero davvero grandi database, il backup e il recupero diventa frustrante, o addirittura problematico e costoso, perché dove si può avere un piccolo insieme di dati di base in caso contrario, si può avere molti GB o TB di i dati delle immagini. Trattare il tutto come una banca dati coerente è sia buono dal punto di vista dell'integrità, ma un male per i backup a meno di utilizzare DBMS con la qualità aziendale, magazzino sintonizzato il backup e ripristino dei dati (ad esempio è Oracle RMAN e backup di laminazione).

Sempre in considerazione il tempo di recupero in qualsiasi sistema. Se i requisiti di storage sono

Answer 7

In generale, la persistenza dei dati immagine nel DB potrebbe non essere efficiente quanto il FileSystem, per quanto riguarda un CMS.Una volta probabilmente vorrai solo visualizzare l'immagine in modo statico, altre volte vuoi che l'immagine sia disponibile ai tuoi grafici per aggiornamenti, ecc.

Considera il sovraccarico di elaborazione associato al recupero dell'immagine ogni volta che desideri lavorarci.

Alcuni punti per cui dovresti considerare il FileSystem

1. Il browser fa tutto il lavoro e beneficiate della memorizzazione nella cache delle immagini, ecc.
2. Come conseguenza di quanto sopra, puoi utilizzare facilmente le reti per la distribuzione di contenuti (CDN)
3. La replica dei dati dell'immagine è semplice con strumenti come rsync ecc
4. Elaborazione (es.CPU) il tempo è drasticamente ottimizzato

Answer 8

Dando per scontato che in un ambiente Windows non v'è alcun buon motivo per utilizzare il file system. Si consiglia di fare attenzione a come si memorizzano le immagini nelle tabelle per evitare divisioni di pagina indesiderate, ma questo è un tweak prestazioni, non è un problema enorme.

aspetti negativi di filesystem

-non automaticamente replicato

-Può complicarsi la replica avendo posizioni fisiche diverse per ogni istanza

-Slow con un gran numero di file

Upside al filesystem

-Se sei memorizzare alcuni file di grandi dimensioni, eseguirà un po 'meglio.

Answer 9

lo farei;

1) Assegnare identificatore univoco (GUID) per ogni immagine 2) Tag / Name l'immagine con quella GUID 3) GUID Conservare nel sistema operativo (File System) 4) Conservare Nome Fully Qualified File (FQN) puntatore nel database.

Memorizzazione immagini nel database è troppo costoso in termini di conservazione e la manutenzione. Memorizzazione appena il puntatore FQN fornirebbe una migliore soluzione. È inoltre possibile creare back-end controllo di integrità attraverso i trigger e alcune stored procedure.

Answer 10

Non vorrei memorizzare le immagini nel database per un motivo (la mia risposta arriva da sql server):

Non vorrei che SQL Server Data Cache popolato da semplici immagini per il sito web. Voglio la cache di dati di avere in realtà i dati in essa contenuti. Anche se si dispone di un'architettura a più livelli la sua molto più facile far passare un URL di un'immagine di un blob di dati binari. Dove non esegue in problemi anche se desideri solo certe persone a vedere le immagini (di sicurezza).