2010-02-09 6 views
5

Ho circa 7 terabyte di vari file multimediali (PDF, JPG, TIFF 's) che attualmente risiedono su un server di file molto rinforzato. Sto cercando di spostare i dati su SQL Server 2008 e utilizzare l'attributo Filestream per aiutarmi a gestire i dati. Voglio farlo perché ho pagine web che gestiscono questo media e loro (le pagine web) stanno diventando sempre più lente man mano che più file multimediali vengono aggiunti quotidianamente al file server.SQL Server 2008 di posizione Filestream

MODIFICA: Le pagine Web sono lente perché molte di esse producono report che riflettono vari dettagli del file server e cosa è memorizzato su di esso. In sostanza, le pagine Web vengono raggruppate in migliaia di cartelle e file per generare report su ciò che è contenuto in essi. Alcune pagine Web consentono agli utenti di manipolare cartelle e file e spostarli in posizioni diverse. Quindi, in breve, sto cercando un modo più veloce nella gestione di questi file. Permetterebbe anche a me di conservare i metadati relativi a questi file all'interno del database, consentendomi quindi di interrogare il database per queste informazioni anziché utilizzare il file server per utilizzarlo.

miei problemi:

1) ho fatto una prova di concetto e verificato che posso creare un FileStream locale al database di SQL Server 2008, e ho letto e scritto i media ad esso con successo. Tuttavia, devo ancora capire come utilizzare un UNC come filestream. In altre parole, il database è ospitato su MySQLDB08, ed i miei file sono memorizzati su TheFileServer01. Ho letto che è possibile, ma non ci sono ancora arrivato. Qualsiasi aiuto su questo sarebbe molto apprezzato!

2) Dal momento che ho 7 terabyte (e crescente) dei mezzi di comunicazione, saranno i miei sostegni essere ingestibile a causa delle loro dimensioni? È qualcosa che potrebbe dissuadermi dall'usare Filestream?

Tutti i suggerimenti o aiuto sarebbe molto apprezzato!

risposta

5
  1. Non è possibile. I dati di filestream Afaik vengono memorizzati localmente e SQL rifiuterà di leggere/scrivere da/verso un UNC.
  2. vostri backup completi conterrà tutti i dati FILESTREAM. Ingestibile? Sicuramente una sfida molto seria.

La mia domanda sarebbe qual è il vantaggio che si desidera estrarre dal filestream? I vantaggi abituali provengono da integrazione BLOB con le operazioni di database, mantenendo la disponibilità per le operazioni di base di gestione del file Win32:

Anche se la tecnologia ha FILESTREAM molte caratteristiche interessanti, potrebbe non essere la scelta ottimale in tutte le situazioni . Come accennato in precedenza, la dimensione dei dati BLOB e gli schemi di accesso sono i più significativi fattori al momento di decidere se memorizzare i dati BLOB interamente all'interno del database oppure utilizzando FILESTREAM.

Dimensione interessa le seguenti:

  • efficienza con la quale i dati BLOB possibile accedere utilizzando stoccaggio meccanismo. Come accennato in precedenza, l'accesso streaming di grandi dati BLOB è più efficiente con FILESTREAM, ma gli aggiornamenti parziali sono (potenzialmente molto) più lenti.
  • Efficienza del backup dei dati combinati strutturati e BLOB utilizzando entrambi i meccanismi di archiviazione. Un backup che unisce file di database e un gran numero di file FILESTREAM SQL Server sarà più lento di un backup del solo database di SQL Server file di una dimensione totale equivalente. Ciò è dovuto al sovraccarico supplementare di backup di ciascun file NTFS (uno per il valore di dati FILESTREAM ). Questo overhead è più piccolo quando i filesono più piccoli (poiché l'overhead dello diventa una percentuale maggiore di tempo totale per il backup di per MB di dati).

Da un punto di vista delle prestazioni pure, ci sono molti passi si possono fare su un livello di file system per migliorare le prestazioni. Qual è il problema attuale, perché il rendimento del sistema è influenzato dalle dimensioni del supporto? Significa che hai un punto di discontinuità da qualche parte, forse un'enumerazione di directory o qualche altra barriera che ti fa scalare il tempo di risposta con la dimensione del supporto. Il tuo accesso al media dovrebbe essere O (1), forse O (logn), in definitiva non O (n).

Si consiglia di andare oltre il White Paper SQL FILESTREAM Storage in SQL Server 2008, da dove ho trovato la mia citazione sui casi d'uso.

+0

Ho letto attraverso la pagina bianca numerose volte, ma, francamente, alcuni dei quali va sopra la mia testa, perché si tratta di aree di cui io non sono a conoscenza (ad esempio - i backup). Inoltre, il white paper dice * L'uso di un driver di filtro del file system consente anche l'accesso remoto ai dati FILESTREAM attraverso un percorso UNC *, il che indica che è possibile memorizzare i dati di filestream in una posizione diversa dal server di database effettivo . Inoltre, per favore vedi la mia modifica nella mia domanda originale; Spero che spieghi meglio perché sto cercando di usare Filestream. – Jagd

+2

Il driver di sistema consente l'accesso attraverso un UNC * a * il filestream da * altra * posizione. In altre parole, ti permette di condividere il filestream. Non consente di memorizzare fielstream su UNC. Nota che a 7Tb, 'local' dovrebbe probabilmente significare una sorta di utility SAN. –

+1

Informazioni sulla modifica: mi sembra che un aspetto del problema sia che non si dispone di metadati in un formato relazionale sui file e che è necessario controllare il file system. Puoi tenere i metadati nelle tabelle, o sarà rapidamente deviato dalla sincronizzazione con il filesystem? –

1

Ho intenzione di non essere d'accordo con @RemusRusanu sul problema UNC. Anche se @RemusRusanu rende alcuni punti positivi su , perché sceglieresti di usare un filestream.

In ogni caso, è possibile utilizzare UNC per i filestreams, altrimenti non sarebbe molto utile. Attualmente, costruisco un sito che utilizza la funzionalità UNC per i server in una Web farm per leggere i file da un Filestream SQL.

Alcuni punti su come utilizzare UNC filestreams ...

  • L'accesso a UNC è recintato di server SQL. WTF? Il punto del flusso di file è di unire i vantaggi del file system (buon streaming) e i vantaggi di SQL Server (buoni metadati, transazioni e query ~ abilità). In che modo SQL assicura che l'accesso ai file sia transazionale? È necessario aprire la transazione e all'interno della transazione chiedere a SQL Server un handle di file.

  • Detto in altro modo, non si può semplicemente passare alla Filestream UNC da Windows Explorer.

  • Se si memorizza il file binario in SQL server, in genere ~ 1,2 MB è il punto di interruzione in cui si dovrebbe preferire il filestream su VarBinary. Here MS suggeriscono 1 MB, ma c'è un altro nel documento di ricerca non riesco a trovare nel momento in cui ha suggerito 1.2 è il punto di pareggio.

  • Abilitazione accesso UNC richiede una transazione distribuita, in modo sia il server SQL e il consumatore del percorso UNC Basti distribuiti transazioni abilitate.

Di seguito è riportato uno snippet di codice che mostra come recuperare un handle per un Filestream. V'è un grande avvertimento: l'operazione non è chiusa in questo frammento. Dovrai leggere il file binario, quindi chiudere la transazione. Lasciare aperte le transazioni è chiaramente un no-no.

public FileStream GetStream(string FilePath){ 
     FileStream FStream = null; 

     Conn = new SqlConnection(MyConnectionStringHere); 
     Conn.Open(); 
     txn = Conn.BeginTransaction(); 

     using (SqlCommand cmd = new SqlCommand("SELECT GET_FILESTREAM_TRANSACTION_CONTEXT()", Conn, txn)){ 

      Object obj = cmd.ExecuteScalar(); 
      TransContext = (byte[])obj; 
     } 

     SafeFileHandle SHandle = NativeSqlClient.GetSqlFilestreamHandle (FilePath, NativeSqlClient.DesiredAccess.Read, TransContext); 
     FStream = new FileStream(SHandle, FileAccess.Read); 

     return FStream; 
    } 
+1

Credo che tu abbia frainteso la mia domanda riguardo all'UNC. Stavo semplicemente chiedendo perché il [Filestream White Paper] (http://msdn.microsoft.com/en-us/library/cc949109.aspx) sembrava indicare che un filestream poteva essere memorizzato su un server diverso da dove Il database di SQL Server 2008 si trova. Il white paper afferma: "L'uso di un driver di filtro del file system consente anche l'accesso remoto ai dati FILESTREAM attraverso un percorso UNC." Remus mi ha chiarito questo spiegando che questo significa semplicemente che il filestream può essere condiviso (in tal modo accessibile) sulla rete da un percorso UNC. – Jagd

+0

(cont.) - In altre parole, non ho mai avuto problemi ad accedere al filestream stesso tramite l'API di Win32. Anche se, credo che il tuo esempio sia alquanto anticonvenzionale. Preferisco usare le librerie SqlFileStream durante la lettura o la scrittura. – Jagd

+0

Inoltre, non ti ho dato il -1. Non sono sicuro di chi sia stato. Non vedo nulla di sbagliato con la tua risposta; Penso solo che tu abbia frainteso il coraggio di ciò che io e Remus stavamo ricevendo. – Jagd