GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Introducción al almacenamiento FILESTREAM en SQL Server


Una problemática típica en SQL Server (al igual que en otros motores de Base de Datos) es el almacenamiento de datos Binarios Grandes (BLOBs), es decir, de ficheros. A partir de SQL Server 2008, es posible habilitar la funcionalidad de almacenamiento FILESTREAM, que permite a SQL Server almacenar los datos grandes (BLOBs) directamente en un sistema de archivos NTFS, de forma transparente para las operaciones de Backup y resto de sentencias DML y DDL. El presente artículo describe la tecnología FILESTREAM en SQL Server, sus ventajas e inconvenientes.

El almacenamiento FILESTREAM es una de las novedades introducidas en SQL Server 2008, la cual permite almacenar los datos binarios grandes (BLOBs), es decir, ficheros o documentos, fuera de la Base de Datos, de forma transparente. De este modo, SQL Server podrá almacenar los datos BLOBs en un sistema de ficheros NTFS. Esto permite un acceso más rápido a dicha información, y adicionalmente, permite poder liberar de carga de memoria a SQL Server, ya que para el acceso a datos FILESTREAM podría no utilizarse el Buffer Pool.

Sin embargo, la magia del almacenamiento FILESTREAM es que todo esto es transparente, ya que podremos acceder a nuestra base de datos con total normalidad, como si estos datos se almacenasen en el interior de la base de datos. Podremos ejecutar nuestras sentencias DDL y DML sin problema, y podremos hacer Backup de nuestra Base de Datos, manteniendo sincronizada la información FILESTREAM y con el resto de información en el interior de la Base de Datos, o en su defecto, si lo deseamos podremos realizar PARTIAL BACKUPs si deseamos excluir la información de los BLOBs.

Aunque realmente todo esto tiene algo de truco, ya que la forma de obtener una verdadera ventaja de rendimiento es accediendo a los datos FILESTREAM utilizando la API de Win32, y no directamente a través de Transact-SQL.

Podemos utilizar el almacenamiento FILESTREAM en Alta Disponibilidad, es decir, si por ejemplo tenemos una instalación de SQL Server 2008 R2 en Cluster, podremos aprovechar la Alta Disponibilidad del Failover Cluster de Windows Server 2008 R2 junto con el almacenamiento FILESTREAM de SQL Server 2008, para ofrecer una solución de almacenamiento de BLOBs en HA.

También es cierto que el almacenamiento FILESTREAM tiene ciertas limitaciones que debemos tener en cuenta antes de decidir utilizarlo. Algunas de las más importantes son:

  • No se puede utilizar los datos FILESTREAM en un Database Snapshot. Podríamos hacer un SnapShot de nuestra base de datos sin incluir los Grupos de Ficheros de FILESTREAM, pero no podemos hacer un SnapShot de toda nuestra Base de Datos (incluyendo los datos almacenados como FILESTREAM).
  • No se puede utilizar el almacenamiento FILESTREAM en una Base de Datos que esté utilizando Database Mirroring. Si estamos utilizando la funcionalidad de Database Mirroring de SQL Server en una Base de Datos, no podremos configurar dicha Base de Datos para utilizar almacenamiento FILESTREAM. O tenemos una cosa, o tenemos la otra. Sin embargo, Log Shipping si soporta el almacenamiento FILESTREAM. Curioso, sobre todo cuando Database Mirroring es una evolución de Log Shipping (al menos, yo lo veo así).

También tiene algunas ventajas adicionales a las antes comentadas, como por ejemplo:

  • SQL Express soporta el almacenamiento FILESTREAM. Es más, sabemos que el tamaño máximo de una Base de Datos en SQL 2008 Express es de 4GB, o de 10GB en SQL 2008 R2 Express. Sin embargo, este tamaño máximo no incluye los datos almacenados como FILESTREAM.
  • Es posible crear índices de texto (Full-Text Indexes) sobre datos almacenados como FILESTREAM.
  • Es posible acceder a datos almacenados como FILESTREAM desde consultas distribuidas y/o servidores vinculados.

El almacenamiento FILESTREAM está deshabilitado por defecto, excepto que durante la instalación de SQL Server habilitásemos explícitamente el almacenamiento FILESTREAM. Si no lo activamos durante la instalación de SQL Server, entonces para poder utilizar el almacenamiento FILESTREAM deberemos habilitarlo en nuestra Instancia de SQL Server, lo cual lo realizaremos en dos pasos (con el SQL Server Configuration Manager y ejecutando una sentencia Transact-SQL, por ejemplo desde el SQL Server Management Studio).

Una vez que tenemos el almacenamiento FILESTREAM habilitado a nivel de nuestra Instancia de SQL Server, deberemos habilitar el almacenamiento FILESTREAM en las Bases de Datos en que lo deseemos utilizar, para lo cual, deberemos al menos crear un Grupo de Ficheros (FileGroup) para el almacenamiento FILESTREAM utilizando la cláusula CONTAINS FILESTREAM, para seguidamente crear al menos un Fichero Lógico para dicho Grupo de Ficheros, en el que especificaremos una carpeta del sistema de archivos para el almacenamiento FILESTREAM.

Ahora que ya tenemos habilitado el almacenamiento FILESTREAM en nuestra Instancia de SQL Server y en nuestra Base de Datos, tenemos que especificar en qué campos de qué tablas deseamos utilizar el almacenamiento FILESTREAM. Para ello utilizaremos el tipo de dato VARBINARY(MAX) con la opción FILESTREAM. Esto nos permite poder ser algo selectivos, básicamente poder decidir qué datos/campos almacenar como FILESTREAM y qué datos/campos no. Debemos tener en cuenta que una tabla que almacene datos FileStream como requisito debe tener un campo único no nulo de tipo ROWGUID.

Una peculiaridad es que si bien un dato VARBINARY(MAX) tiene que ser de un máximo de 2GB, si lo almacenamos como FILESTREAM este límite desaparece, de tal modo que ahora dependerá de los límites impuestos por el almacenamiento NTFS (en la práctica, que tengamos suficiente espacio libre).

Existe algún otro pequeño inconveniente al trabajar con el almacenamiento FILESTREAM en SQL Server. En particular, el problema es que nos podemos encontrar que al ejecutar una sentencia DELETE, el correspondiente fichero no sea eliminado del Sistema de Fichero. Susto. Parece ser que se trata de un comportamiento natural del producto: el fichero será eliminado del Sistema de Ficheros con la ejecución del siguiente CHECKPOINT. Lo he probado, y efectivamente, al ejecutar manualmente un CHECKPOINT, el fichero ha desaparecido. Visto en SQL Server 2008: Filestream Data & Delete Statement.

En resumen, el almacenamiento FILESTREAM es una interesante funcionalidad de SQL Server, que nos puede servir como una alternativa más para solucionar nuestros problemas de Almacenamiento, y que puede utilizarse tanto por las aplicaciones que desarrollemos nosotros como por aplicaciones de terceros, como es el propio caso de Microsoft SharePoint 2010.

Hasta aquí llega el presente artículo. Así que, ahora que hemos visto un poco la teoría del almacenamiento FILESTREAM en SQL Server, si quieres puedes ver un poco la práctica en el siguiente artículo, que describe cómo configurar el almacenamiento FILESTREAM en SQL Server. Para más información, es interesante leer Designing and Implementing FILESTREAM Storage.

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2019 (1)
Octubre de 2018 (1)
Julio de 2018 (1)
Junio de 2018 (4)
Mayo de 2018 (5)
Abril de 2018 (3)
Marzo de 2018 (2)
Febrero de 2018 (7)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.