2010-02-09 15 views
5

Tengo aproximadamente 7 terabytes de diversos archivos multimedia (PDF, de JPG, TIFF) de los que residen actualmente en un servidor de archivos muy reforzado. Estoy buscando mover los datos a SQL Server 2008 y usar el atributo Filestream para ayudarme a administrar los datos. Quiero hacer esto porque tengo páginas web que administran este medio, y ellas (las páginas web) son cada vez más lentas a medida que se agregan más medios diariamente al servidor de archivos.SQL Server ubicación Filestream de 2008

EDIT: Las páginas web son lentas porque muchas de ellas producen informes que reflejan varios detalles del servidor de archivos y lo que está almacenado en él. Esencialmente, las páginas web recorren miles de carpetas y archivos para generar informes sobre lo que contienen. Algunas páginas web permiten a los usuarios manipular carpetas y archivos y moverlos a diferentes ubicaciones. Por lo tanto, en pocas palabras, estoy buscando una forma más rápida de administrar estos archivos. También me permitiría mantener los metadatos sobre estos archivos dentro de la base de datos, lo que me permite consultar la base de datos para esta información en lugar de buscar en ella el servidor de archivos.

mis problemas:

1) me han hecho una prueba de concepto y verificado que puedo crear un filestream local a la base de datos SQL Server 2008, y he leído correctamente y escribió los medios de comunicación a la misma. Sin embargo, todavía tengo que descubrir cómo usar un UNC como una extensión de archivos. En otras palabras, la base de datos está alojada en MySQLDB08 y mis archivos están almacenados en TheFileServer01. He leído que es posible, pero aún no he llegado. ¡Cualquier ayuda en esto sería muy apreciada!

2) Dado que tengo 7 terabytes (y creciente) de los medios de comunicación, serán mis copias de seguridad sea difícil de manejar debido a su tamaño? ¿Esto es algo que podría disuadirme de usar Filestream?

¡Cualquier sugerencia o ayuda sería muy apreciada!

Respuesta

5
  1. No se puede. Los datos de Afaik filestream se almacenan localmente y SQL rehusará leer/escribir desde/hacia un UNC.
  2. Sus copias de seguridad completas contendrán toda la información de filestream. Inmanejable? Definitivamente un desafío muy serio.

Mi pregunta sería ¿cuál es el beneficio que desea extraer de la extensión de archivos? Los beneficios habituales proceden de la integración de bases de datos BLOB con las operaciones mientras se mantiene la disponibilidad para las operaciones de base de identificador de archivo de Win32:

A pesar de que la tecnología de FILESTREAM tiene muchas características atractivas, puede que no ser la opción óptima en todas las situaciones . Como se mencionó anteriormente, el tamaño de los datos BLOB y los patrones de acceso son los factores más significativos cuando se decide si se almacenan los datos BLOB dentro de la base de datos o mediante FILESTREAM.

Tamaño afecta a los siguientes:

  • eficiencia con la que los datos BLOB se puede acceder utilizando almacenamiento mecanismo. Como se mencionó anteriormente, streaming de acceso a los datos BLOB grande es más eficiente el uso de FILESTREAM, pero actualizaciones parciales son (potencialmente mucho) más lento.
  • Eficiencia de la copia de seguridad de datos combinados estructurados y BLOB utilizando cualquiera de los mecanismos de almacenamiento. Una copia de seguridad que combina archivos de base de datos SQL Server y una gran cantidad de archivos FILESTREAM será más lenta que una copia de seguridad de archivos de base de datos SQL Server de un tamaño total equivalente. Esto se debe a la sobrecarga adicional de la copia de seguridad de cada archivo NTFS (uno por valor de datos FILESTREAM). Esta sobrecarga se vuelve más notable cuando los archivos FILESTREAM son más pequeños (como la sobrecarga de tiempo se convierte en un mayor porcentaje del tiempo total de copia de seguridad por MB de datos).

Desde el punto de vista de rendimiento puro, hay muchos pasos que se pueden hacer en un nivel de sistema de archivos para mejorar el rendimiento. ¿Cuál es su problema actual? ¿Por qué el rendimiento del sistema se ve afectado por el tamaño del medio? Significa que tiene un punto conflictivo en algún lugar, tal vez una enumeración de directorio, o alguna otra barrera que le hace escalar el tiempo de respuesta con el tamaño del medio. Su acceso a los medios debe ser O (1), quizás O (logn), pero definitivamente no O (n).

Te recomiendo que vayas al libro blanco SQL FILESTREAM Storage in SQL Server 2008, donde encontré mi cita sobre casos de uso.

+0

He leído a través de la página en blanco en numerosas ocasiones, pero, francamente, algunos de los que va por encima de mi cabeza porque se trata de zonas de las que no estoy familiarizado (por ejemplo, - las copias de seguridad). El uso de un controlador de filtro de sistema de archivos también permite el acceso remoto a los datos FILESTREAM a través de una ruta UNC *, lo que me indica que podría ser posible almacenar los datos de la ruta de archivos en una ubicación diferente a la del servidor de la base de datos real. . Además, vea mi edición en mi pregunta original; Espero que explique mejor por qué estoy buscando usar Filestream. – Jagd

+2

El controlador del sistema permite el acceso a través de UNC * a * la secuencia de archivos desde * otra * ubicación. En otras palabras, te permite compartir el filestream. No le permite almacenar la corriente en un UNC. Tenga en cuenta que a 7 TB, 'local' probablemente debería significar algún tipo de utilidad SAN. –

+1

Acerca de tu edición: me suena que un aspecto del problema es que usted no tiene metadatos en un formato relacional acerca de sus archivos, y hay que buscar en el sistema de archivos para ello. ¿Puede mantener los metadatos en tablas o se desviará rápidamente de la sincronización con el sistema de archivos? –

1

Voy a tener que estar en desacuerdo con @RemusRusanu en el tema de UNC. Aunque, @RemusRusanu hace algunos buenos puntos en por qué elegiría utilizar una extensión de archivos.

De todos modos, puede utilizar UNC para filestreams - de otro modo no sería de mucha utilidad. Actualmente, construyo un sitio que usa la función UNC para servidores en una granja de servidores web para leer archivos de una SQL Filestream.

Algunos puntos sobre el uso de UNC FileStreams ...

  • Acceso a la UNC está cerrada por el servidor SQL. WTF? El objetivo de la secuencia de archivos es fusionar los beneficios del sistema de archivos (buena transmisión) y los beneficios de SQL Server (buenos metadatos, transacciones y capacidad de consulta). ¿Cómo garantiza SQL que el acceso al archivo sea transaccional? Debe abrir la transacción y dentro de la transacción, solicite a SQL Server un identificador de archivo.

  • Dicho de otra manera, no puede simplemente navegar a Filestream UNC desde el explorador de Windows.

  • Si está almacenando su binario en el servidor SQL, generalmente ~ 1.2MB es el punto de ruptura donde debería favorecer FileStream sobre VarBinary. Here MS sugiere 1 MB, pero hay otro en el documento de investigación que no encuentro en el momento en que el 1.2 sugerido es el punto de equilibrio.

  • La habilitación del acceso UNC requiere una transacción distribuida, por lo que tanto el servidor SQL como el consumidor de la ruta UNC necesitan transacciones distribuidas habilitadas.

A continuación se muestra un fragmento de código que muestra cómo recuperar un identificador a una extensión de archivos. Hay una advertencia grande: la transacción no se cierra en este fragmento. Deberá leer el binario y luego cerrar la transacción. Dejar transacciones abiertas es claramente 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

Creo que es posible que haya malentendido mi pregunta con respecto a la UNC. simplemente me estaba preguntando por qué el [Libro Blanco Secuencia de archivo] (http://msdn.microsoft.com/en-us/library/cc949109.aspx) parecía indicar que una filestream podría ser almacenado en un servidor diferente de donde el La base de datos de SQL Server 2008 reside. El Libro Blanco dice: "El uso de un controlador de filtro de sistema de archivos también permite el acceso remoto a los datos FILESTREAM a través de una ruta UNC". Remus me aclaró esto explicando que esto simplemente significa que la secuencia de archivos se puede compartir (así se accede) en su red mediante una ruta UNC. – Jagd

+0

(cont.) - En otras palabras, nunca tuve problemas para acceder al filestream a través de Win 32 API. Aunque, creo que su ejemplo es algo poco convencional. Prefiero usar las bibliotecas SqlFileStream cuando leo o escribo en él. – Jagd

+0

Además, no te di el -1. No estoy seguro de quién lo hizo. No veo nada incorrecto con tu respuesta; Creo que entendiste mal las entrañas de lo que Remus y yo estábamos consiguiendo. – Jagd

Cuestiones relacionadas