SQL Server 2008 prestazioni FILESTREAM

Question

ho avuto alcune domande intorno alla capacità di FILESTREAM di SQL Server 2008.

1. Quale sarebbe la differenza in termini di prestazioni sia di restituire un file in streaming da SQL Server 2008 utilizzando il vs. capacità FILESTREAM accedendo direttamente al file da una directory condivisa?

2. Se 100 utenti hanno richiesto 100 file 100Mb (memorizzati tramite FILESTREAM) in una finestra di 10 secondi, le prestazioni di SQL Server 2008 rallenterebbero a una scansione?

Answer 1

Se 100 utenti hanno chiesto 100 file 100Mb (memorizzati tramite FILESTREAM) all'interno di una seconda finestra 10, sarebbe SQL Server 2008 un rallentamento delle prestazioni a passo d'uomo?

Su che tipo di server ?? Che tipo di hardware serve per questi file? Che tipo di dischi, rete ecc. ?? Tante domande .......

C'è un post sul blog davvero buono di Paul Randal su SQL Server 2008: FILESTREAM Performance - dai un'occhiata. È disponibile anche un 25-page whitepaper on FILESTREAM, che copre anche alcuni suggerimenti per l'ottimizzazione delle prestazioni.

---

Ma controlla anche il rapporto di ricerca Microsoft To BLOB or Not To BLOB.

È un articolo molto profondo e molto ben fatto che mette tutte queste domande al loro esame.

La loro conclusione:

Lo studio indica che, se gli oggetti sono più grandi di un megabyte sul media, NTFS ha un chiaro vantaggio su SQL Server. Se gli oggetti sono sotto 256 kilobyte, il database ha un chiaro vantaggio. All'interno di questo intervallo, dipende da quanto è impegnativo il carico di lavoro e l'età di archiviazione di una replica tipica nel sistema.

Quindi, a giudicare da ciò, se i BLOB sono in genere inferiori a 1 MB, archiviarli come VARBINARY (MAX) nel database. Se sono generalmente più grandi, solo la funzione FILESTREAM.

Io non mi preoccuperei tanto di prestazioni piuttosto che altri benefici di FILESTREAM oltre archiviazione "non gestito" in una cartella di file NTFS: la memorizzazione di file al di fuori del database senza FILESTREAM, si ha alcun controllo su di loro:

• nessun controllo di accesso fornito dal database
• i file non fanno parte del backup di SQL Server
• i file non vengono gestiti a livello di transazione, ad es. si potrebbe finire con i file di "zombie", che non si fa riferimento dal database più, o le voci di "scheletro" nel database senza il file corrispondente sul disco

alone Tali caratteristiche lo rendono assolutamente la pena di utilizzare FILESTREAM.

Answer 2

Leggere un FILESTREAM su Win32 è abbastanza veloce. Vedi Managing FILESTREAM Data by Using Win32. Dovresti comunque seguire lo FILESTREAM best practices. Dopotutto, questo è ciò che powers Sharepoint e MS non scommetterebbero qualcosa di importante come Office (== Sharepoint) sullo storage non performante. Ci sono alcuni casi di studio e white paper su FILESTREAM, potrei solo scovare Laren Electronics Fuels Analysis of Formula One Racing Data with SQL Server ma so che ce ne sono altri con dati numerici più dettagliati. Se ricordo correttamente, questo mostra che FILESTREAM in generale oscura le prestazioni SMB di circa il 90-95% del fattore, su una certa dimensione del file. Per i file di piccole dimensioni, il sovraccarico di ottenere l'handle dell'API FILESTREAM inizia a essere visualizzato.

Vorrei anche Marc in secondo luogo raccomandando la lettura del documento di ricerca sull'argomento (c'è anche un'intervista di Channel 9 con Catharine van Ingen, disponibile anche sui podcast di iTunes, dove parla di questo lavoro), ma tenete presente Si noti che il documento è stato pubblicato nel 2006 prima del FILESTREAM è stato rilasciato ufficialmente, quindi non considera le specifiche di FILESTREAM.

Per quanto riguarda la seconda domanda, chiedere informazioni sulle prestazioni specificando solo il carico e non la capacità del sistema è un non senso. Un Superdome da 128 CPU con una montagna di SAN di storage non noterà nemmeno il tuo carico. Una run di SQL su un laptop da 256 MB con una montagna di spyware non vedrà nemmeno il tuo carico ...