Roberto Carrancio

Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
05
Feb
2025

Integración de FILESTREAM y FileTable con Always On Availability Groups

La combinación de FILESTREAM y FileTable con Always On Availability Groups en SQL Server permite gestionar datos no estructurados con integridad transaccional (FILESTREAM y FileTable) mientras se garantiza alta disponibilidad y recuperación ante desastres (Always On). Sin embargo, esta integración no está exenta de retos, lo que requiere un enfoque y mantenimiento planificados y precisos. En este artículo, quiero hacer una introducción a cómo configurar estas tecnologías y resolver los problemas más comunes que surgen en su implementación. No pretendo generar una guía paso a paso, simplemente introducir los conceptos clave que debéis tener en cuenta.

Introducción a FILESTREAM, FileTable y Always On Availability Groups

FILESTREAM es una funcionalidad de SQL Server que habilita el almacenamiento de datos binarios grandes (como imágenes, documentos o vídeos) directamente en el sistema de archivos. Esto permite a las aplicaciones interactuar con los datos mediante APIs de sistema de archivos estándar, mientras que SQL Server mantiene la consistencia transaccional.

FileTable extiende FILESTREAM al ofrecer una estructura predefinida que facilita la gestión de datos no estructurados. Proporciona una forma más sencilla de organizar los archivos almacenados, permitiendo su acceso directo a través de rutas de sistema de archivos además de la base de datos.

Por su parte, Always On Availability Groups ofrece un modelo avanzado de alta disponibilidad y recuperación ante desastres a nivel de base de datos. Su capacidad para replicar datos entre réplicas en distintas ubicaciones lo hace ideal para garantizar continuidad en el servicio.

Cuando se combinan FILESTREAM y FileTable con Always On, surgen retos relacionados con la sincronización de datos, el acceso mediante Nombres de Red Virtual (VNN) y la compatibilidad funcional tras un failover.

Requisitos previos y consideraciones iniciales

Para garantizar una integración exitosa, es fundamental cumplir con ciertos requisitos previos:

Habilitar de FILESTREAM en todas las instancias del grupo

Debemos asegurarnos de que FILESTREAM esté habilitado en cada instancia del grupo de disponibilidad. Esto incluye habilitar el acceso a través de Transact-SQL y APIs de sistema de archivos.

Configuración del clúster y actualizaciones

Si utilizamos Windows Server 2012 o versiones más recientes, deberemos asegurarnos también de aplicar cualquier hotfix recomendado para el acceso adecuado a recursos compartidos mediante VNN.

Validar la infraestructura de Always On

El clúster de conmutación por error debe estar configurado y operativo. 

Además, las bases de datos que contendrán FILESTREAM o FileTable deben cumplir con los requisitos para formar parte de un Availability Group.

Configuración de FILESTREAM y FileTable con Always On Availability Groups

Una vez que FILESTREAM está habilitado en todas las instancias, podremos añadir bases de datos que utilicen FILESTREAM a un grupo de disponibilidad. Para hacerlo, no tenemos que hacer nada fuera de lo normal. Simplemente crear un grupo de disponibilidad desde SSMS o mediante el asistente de Always On y asegurarnos de que las bases de datos estén en modo «FULL Recovery Model» y se haya realizado un backup full reciente. De esta manera podremos incluir las bases de datos con FILESTREAM al configurar el grupo de disponibilidad.

Configuración del acceso mediante Nombres de Red Virtual (VNN)

Always On utiliza un VNN para virtualizar el acceso al grupo de disponibilidad. Para acceder a los datos FILESTREAM o FileTable en este contexto.

Tendremos que validar que el recurso compartido de FILESTREAM se haya creado automáticamente para el VNN. Este recurso compartido tendrá la forma típica de un directorio de red pero con el nombre del grupo de disponibilidad en vez de el de uno de los nodos:

\\<NombreVirtualDelGrupo>\mssqlserver

Las aplicaciones que interactúan con FILESTREAM mediante APIs de sistema de archivos deben usar este recurso compartido en lugar del nombre del servidor físico.

Sincronización y replicación de datos

Aunque Always On replica los datos relacionales entre réplicas, los datos almacenados en el sistema de archivos a través de FILESTREAM no se replican automáticamente. Para garantizar consistencia podremos usar herramientas como Distributed File System Replication (DFS-R), que permite sincronizar las carpetas de FILESTREAM entre las réplicas.

Problemas comunes y tips para superarlos

La sincronización de datos no estructurados con FILESTREAM entre nodos puede ser compleja. Como ya hemos mencionado, DFS-R u otras soluciones de replicación similares nos ayudarán a mantener consistencia entre las réplicas. Es imprescindible asegurarse de que las carpetas FILESTREAM estén correctamente sincronizadas en todas las réplicas antes de habilitar un grupo de disponibilidad.

Ten en cuenta que, tras un failover, los datos de FILESTREAM son accesibles tanto en la nueva réplica primaria como en las réplicas secundarias legibles. Sin embargo, una limitación que debemos conocer es que los datos de FileTable solo son accesibles en la réplica primaria. 

Otra cosa importante, que ya habrás adivinado en puntos anteriores es que las aplicaciones que dependen de rutas de sistema de archivos deben actualizarse para usar las rutas basadas en VNN, evitando dependencias del servidor físico. De este modo, en caso de failover seguirán siendo accesibles

Buenas prácticas para FILESTREAM y FileTable en Always On

Es aconsejable usar DFS-R para sincronizar los datos FILESTREAM entre réplicas y para ello deberemos configurar correctamente las políticas de la aplicación.

Tampoco debemos olvidar adaptar nuestras herramientas para monitorizar el estado de las réplicas para tener bajo control también los recursos compartidos de FILESTREAM.

Y ahora dos cosas que nunca me cansaré de decir. Primero, realizad pruebas periódicas para garantizar que los failovers funcionan y, en este caso, que no interrumpen el acceso a los datos FILESTREAM o FileTable. Y segundo y muy importante, mantened siempre una documentación clara sobre la configuración y validad regularmente los cambios en la infraestructura.

Conclusión

Integrar FILESTREAM y FileTable con Always On Availability Groups es una solución potente para gestionar datos no estructurados con alta disponibilidad. Sin embargo, requiere una configuración cuidadosa y una planificación meticulosa para superar los desafíos inherentes.

Con una configuración adecuada y el uso de herramientas complementarias como DFS-R, las empresas pueden disfrutar de las ventajas de estas tecnologías mientras minimizan los riesgos y los problemas operativos. Para obtener más detalles sobre FILESTREAM, recomendamos consultar nuestro artículo previo sobre FILESTREAM en SQL Server y la documentación oficial de Microsoft.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
03
Feb
2025

Azure SQL Database: Comprendiendo las opciones de compra DTU y vCore

Azure SQL Database es la solución de acceso a SQL en Azure. Y, sin embargo, es una plataforma versátil y escalable que se adapta a distintas necesidades empresariales gracias a sus modelos de compra flexibles. Elegir entre DTU (Database Transaction Unit) y vCore (Virtual Core) puede parecer complicado, sobre todo al principio. Hay que entender que cada modelo está diseñado para escenarios específicos, lo que permite optimizar el rendimiento y los costes según los requerimientos de nuestro negocio.

En este artículo introduciremos ambos modelos, sus niveles de servicio, ventajas y desventajas, precios en España y los casos en los que es más recomendable optar por cada opción.

Introducción a los modelos de compra en Azure SQL Database

Como decía en la introducción, Microsoft ofrece dos principales modelos de compra para Azure SQL Database DTU y vCore.

El modelo de compra por DTU está diseñado para simplificar la elección de recursos al proporcionar paquetes preconfigurados que incluyen CPU, memoria y E/S.

El modelo basado en vCore (Virtual Core), por contra, nos da mayor flexibilidad al permitir configurar de forma independiente los recursos de proceso y almacenamiento, adaptándose mejor a las necesidades específicas de cada carga de trabajo. Sin embargo, por esto mismo, puede ser más complejo de configurar

Además, para hacer las cosas más flexibles (ejem complejas), ambos modelos están disponibles con distintos niveles de servicio que determinan las capacidades de rendimiento, alta disponibilidad y escalabilidad.

Azure SQL Database basado en DTU

El modelo de compra por DTU combina los recursos computacionales, la memoria y las operaciones de entrada/salida en un único paquete. Esto lo convierte en una opción intuitiva y fácil de implementar para quienes buscan simplicidad en la gestión de sus bases de datos.

Niveles de servicio en DTU

Este modelo de compra tiene varios niveles que vamos a poder seleccionar.

Un primer nivel básico, ideal para cargas de trabajo pequeñas con baja concurrencia. Nos ofrece hasta 2 GB de almacenamiento por lo que está diseñado, en principio, para aplicaciones de prueba o proyectos muy pequeños.

A continuación encontraremos un nivel estándar pensado para aplicaciones empresariales con requisitos de rendimiento moderado. Este nivel ya nos permite hasta 1 TB de almacenamiento por lo que es ideal para bases de datos transaccionales estándar.

Por último, encontramos un nivel premium más diseñado para cargas críticas con alta concurrencia y baja latencia. Este nivel nos ofrece además almacenamiento local SSD para un rendimiento superior y es escalable hasta 4 TB de almacenamiento.

Ventajas del modelo DTU

Si hay una ventaja a destacar de este modelo de compra por DTU es su simplicidad. Al agrupar los recursos en paquetes, elimina la necesidad de calcular CPU o memoria de manera independiente. Todo esto sin renunciar a la escalabilidad vertical, podremos aumentar o reducir el nivel de servicio según las necesidades prácticamente en tiempo real.

Desventajas del modelo DTU

Toda ventaja tiene una contraparte, y en este caso, la simplicidad del modelo DTU implica una excesiva rigidez en la configuración. Este modelo con una configuración tan simple no nos permite ajustar individualmente los recursos de CPU o memoria. Además, es muy susceptible a costes potencialmente elevados. Si nuestras necesidades de recursos no coinciden perfectamente con un paquete, deberemos ir a un nivel superior y pagar por recursos no utilizados. Porque no vamos a contratar algo infradimensionado, ¿verdad?

Azure SQL Database basado en vCore

El modelo vCore (Virtual Core), al contrario que el DTU, nos proporciona un control más granular sobre los recursos, lo que resulta ideal cuando trabajamos con aplicaciones con requisitos específicos o cargas de trabajo variables. Es una opción que se asemeja más al enfoque tradicional de bases de datos locales, facilitando la migración de estas a la nube.

Tipos de implementación en vCore

A la hora de contratar una Azure SQL Database basada en vCore debemos elegir uno de los dos tipos de implementación que tenemos disponibles, el aprovisionado y el sin servidor.

En el tipo aprovisionado los recursos se asignan permanentemente y están disponibles en todo momento.Esto es adecuado para cargas de trabajo constantes o predecibles. Esto no quiere decir que no se pueda escalar, pero no es un proceso dinámico.

Por otro lado, tenemos el tipo de implementación sin servidor (Serverless). En este nivel, los recursos se escalan automáticamente según la demanda, reduciendo costes durante los períodos de inactividad. Este tipo es ideal para cargas de trabajo esporádicas o impredecibles pero cuidado, una consulta mal optimizada puede arruinarnos.

Niveles de servicio en vCore

Igual que en modelo basado en DTU, en este modelo también tenemos niveles de servicio que marcarán el rendimiento y las limitaciones de escalado de nuestra base de datos

El primer nivel de acceso a este modelo es el de uso general (General Purpose). Este nivel, basado en almacenamiento remoto, proporciona un equilibrio entre coste y rendimiento ideal. Es el más recomendado para la mayoría de las aplicaciones empresariales.

Si tenemos unas necesidades mayores podemos optar por el nivel crítico (Business Critical). Este segundo nivel utiliza almacenamiento SSD local, lo que nos ofrece una menor latencia y alta velocidad. Está especialmente diseñado para aplicaciones críticas que requieren alta disponibilidad.

Por último, el nivel hiperescala (Hyperscale) nos permite almacenar y gestionar grandes volúmenes de datos de más de 100 TB. Además es escalable dinámicamente, lo que lo hace ideal para aplicaciones con crecimiento masivo de datos.

Ventajas del modelo vCore

Como este modelo de contratación es más configurable lo primero que debemos destacar como ventaja es su mayor flexibilidad. Ya hemos visto que nos permite personalizar los recursos de CPU, memoria y almacenamiento según nuestras necesidades. Por otro lado, la transparencia en costes también es fundamental, al final pagamos solo por lo que utilizamos.Por último, gracias a su similitud con configuraciones tradicionales tiene una mayor compatibilidad y nos facilita la migración de cargas de trabajo locales.

Desventajas del modelo vCore

Como nada es perfecto, también nos vamos a encontrar con una desventaja y no es otra que la mayor complejidad que ya hemos comentado antes. Este modelo requiere más conocimiento técnico para optimizar la configuración.

Además debemos tener mucho cuidado con los costes en Serverless. Aunque sea el tipo de implementación más eficiente para cargas variables, puede ser más costoso si las pausas no se configuran adecuadamente o si no controlamos las consultas pesadas y costosas.Requiere de mucho trabajo de optimización de desarrollo para no llevarnos sustos en las facturas.

Comparativa de costes (Precios en España)

Como todo en Azure, y en casi todo en esta vida, los precios dependen de la región. En este caso además entran en juego variables como el modelo de compra y el nivel de servicio elegido. A continuación, os pongo unas estimaciones aproximadas con los precios en España al momento de escribir este artículo:

  • DTU Basic (5 DTU): Desde 4,70 € al mes.
  • DTU Standard (10 DTU): Desde 14,12 € al mes.
  • DTU Premium (125 DTU): Desde 437,75 € al mes.
  • vCore General Purpose (2 vCore): Desde 234,55 € al mes*.
  • vCore Business Critical (2 vCore): Desde 469,10 € al mes*.
  • vCore Business Critical (2 vCore): Desde 281,46 € al mes*.
  • vCore Serverless: Desde 0,055 €/hora*. 

* A los modelos de compra vCore hay que sumarle los costes de almacenamiento que son de 0,131 € por GB al mes.

Ten en cuenta que existen descuentos por reservas de uno o tres años y, en algunos casos, te puedes acoger a la Ventaja híbrida de Azure o a los Derechos de conmutación por error. Por último, como sobrecostes, tienes que contar con replicaciones y opciones de redundancia o retención a largo plazo de los backups.

Si necesitas precios más específicos, te recomiendo usar la calculadora de precios de Azure.

¿Cuándo usar Azure SQL Database DTU o vCore?

Ahora que ya hemos visto toda la parte más de descripción del “comercial” llega el momento de mojarme, si habéis venido a leer esto es porque queréis saber mi opinión. En este caso, y como estarás imaginando, no hay una respuesta universal. 

Yo personalmente recomiendo elegir DTU si la simplicidad es prioritaria para ti y no requieres un control granular de los recursos. También es aconsejable para las aplicaciones tienen cargas de trabajo predecibles y de baja a mediana intensidad o si prefieres pagos fijos y predecibles.

Por el contrario, te recomendaría elegir vCore si necesitas esa flexibilidad extra para configurar CPU, memoria y almacenamiento de forma independiente siempre y cuando seas o tengas a alguien especialista para esta administración más especializada. Sobre todo, si gestionas aplicaciones críticas con requisitos específicos de rendimiento y alta disponibilidad o tu carga de trabajo es variable y prefieres la opción sin servidor para ahorrar costes en periodos de inactividad.

Conclusión

Tanto DTU como vCore son modelos viables para Azure SQL Database, cada uno con sus ventajas y limitaciones. La elección depende de las necesidades específicas de tu aplicación, el nivel de control requerido y el presupuesto disponible. Mientras DTU destaca por su simplicidad, vCore se adapta mejor a configuraciones avanzadas y escenarios críticos.

Os recomiendo evaluar las características de cada modelo y utilizar herramientas como la calculadora de precios de Azure para tomar decisiones informadas. Azure SQL Database ofrece una plataforma potente y flexible que, bien configurada, puede convertirse en un aliado clave para el crecimiento de cualquier negocio.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!  

Publicado por Roberto Carrancio en Cloud, 1 comentario
31
Ene
2025

¿Cuándo y por qué usar un servidor SSAS intermedio entre SQL Server y Power BI?

Una de las decisiones clave a la hora de diseñar arquitecturas BI robustas es determinar cómo gestionar y procesar de manera eficiente la ingente cantidad datos que vamos a manejar. Aquí es donde la pregunta de si incluir un servidor SQL Server Analysis Services (SSAS) como capa intermedia entre SQL Server y Power BI cobra especial relevancia, sobre todo cuando buscamos soluciones escalables, de alto rendimiento y con un control centralizado. Aunque Power BI, al igual que SSAS, utiliza el motor VertiPaq, los objetivos y capacidades de cada herramienta pueden llegar a justificar el coste extra (recursos y tiempo) de la integración de SSAS en no pocas situaciones.

A lo largo de este artículo trataré de explicar los casos en los que SSAS aporta valor añadido a las arquitecturas BI y analizaremos su utilidad tanto en combinación con Power BI como, en escenarios mucho más específicos como Power BI Report Server (PBIRS). Además, abordaremos cómo estas soluciones contribuyen a la consistencia de los datos, el rendimiento de las consultas y la gobernanza empresarial.

¿Qué es SQL Server Analysis Services (SSAS)?

Empecemos por el principio, ¿qué es SSAS? SQL Server Analysis Services (SSAS) es un componente de Microsoft SQL Server diseñado para proporcionar capacidades analíticas avanzadas mediante la creación de modelos de datos optimizados. SSAS es esencialmente un motor analítico que permite construir modelos tabulares o multidimensionales que los usuarios pueden consultar para obtener insights clave de negocio.

Existen dos variantes principales de SSAS: modelos tabulares y modelos multidimensionales. Aunque ambos ofrecen capacidades de análisis, aunque, los modelos tabulares, introducidos en 2012, se han impuesto como la opción preferida por la mayoría de las organizaciones debido a su simplicidad y rendimiento. Los modelos tabulares utilizan el motor VertiPaq, que permite almacenar datos en memoria de forma comprimida y procesarlos rápidamente. Esto lo hace ideal para escenarios que requieren análisis en tiempo real o procesamiento rápido de grandes volúmenes de datos.

Además de ser un motor analítico, SSAS actúa como un servidor centralizado donde los modelos de datos pueden ser compartidos y consumidos por múltiples herramientas, como Power BI, Excel o cualquier cliente que soporte DAX o MDX. Esta capacidad de centralizar la lógica analítica y permitir el acceso desde diferentes aplicaciones lo convierte en una pieza clave en la gobernanza de datos empresariales.

En términos de seguridad, SSAS permite implementar configuraciones avanzadas como Row-Level Security (RLS), que garantiza que los usuarios solo accedan a la información que les corresponde según sus roles. Esto, junto con su capacidad para manejar grandes volúmenes de datos y consultas complejas, posiciona a SSAS como una solución ideal para arquitecturas de BI empresariales.

SSAS y Power BI: una combinación estratégica para el análisis de datos

Ya hemos visto que el motor VertiPaq es núcleo de las capacidades de análisis en memoria tanto de Power BI como de SSAS Tabular. Este motor está diseñado para gestionar grandes volúmenes de datos y optimizar consultas analíticas complejas. Aunque tanto SSAS como PowerBI comparten esta tecnología, las diferencias entre Power BI y SSAS Tabular son notables. Mientras que Power BI está orientado a usuarios finales que necesitan autonomía en la creación de modelos y reportes, SSAS está diseñado para ser un motor analítico centralizado, ideal para entornos empresariales con necesidades avanzadas de escalabilidad, rendimiento y control.

Esta diferencia de enfoques posiciona a SSAS como un intermediario estratégico en arquitecturas BI. Al encargarse del procesamiento analítico, SSAS permite que Power BI se concentre en la visualización e interacción con los datos, podríamos decir que lo libera de la carga computacional asociada a cálculos pesados y transformaciones complejas.

Beneficios de incluir SSAS en la arquitectura BI

Lo sé, aún no te he dicho que ventajas tiene montar SSAS. Pues bien, cuando integras SSAS, el impacto en términos de rendimiento, centralización y escalabilidad es significativo. Su capacidad para manejar grandes volúmenes de datos, centralizar la lógica analítica y gestionar la seguridad de forma avanzada lo convierte en una solución potente para escenarios empresariales complejos.

Uno de los principales beneficios de SSAS es su capacidad para optimizar consultas analíticas a través del motor VertiPaq, que procesa los datos en memoria de manera comprimida. Esto se traduce en tiempos de respuesta significativamente más rápidos en consultas que involucran relaciones complejas, medidas calculadas o grandes cantidades de datos. Este enfoque mejora la experiencia del usuario final y alivia la carga sobre el servidor SQL subyacente frente a por ejemplo unas consultas direct query pero tampoco es ninguna ventaja frente a un Power BI en modo import, en el fondo es lo mismo.

Entonces, lo que sí es una ventaja de SSAS es que permite centralizar los modelos analíticos, asegurando que todas las herramientas y usuarios consuman el mismo conjunto de datos y cálculos. Esta centralización elimina inconsistencias entre departamentos y garantiza que los análisis se basen en las mismas definiciones métricas, lo que es esencial en entornos empresariales con múltiples equipos trabajando en paralelo. Con esta configuración, Power BI actúa como un consumidor de estos modelos, lo que simplifica la gobernanza de los datos y la gestión de los cambios.

Otro aspecto clave es la seguridad. SSAS ofrece un control robusto a través de la seguridad a nivel de fila (Row-Level Security, RLS), que permite definir permisos detallados para los datos. Esto asegura que cada usuario solo tenga acceso a los datos relevantes para su función, garantizando el cumplimiento de las políticas de privacidad y seguridad de la organización.

Casos prácticos de uso de SSAS con Power BI

La integración de SSAS con Power BI se justifica especialmente en entornos donde se manejan grandes volúmenes de datos, múltiples usuarios concurrentes o modelos analíticos complejos. En estos escenarios, SSAS actúa como un motor analítico dedicado que libera a Power BI de la carga computacional, permitiendo que esta última herramienta se concentre en la presentación de los datos.

Por ejemplo, en organizaciones donde los reportes son consultados por decenas o cientos de usuarios simultáneamente, SSAS distribuye eficientemente el procesamiento de las consultas. Esto no solo mejora los tiempos de respuesta, sino que también evita la saturación del servidor SQL transaccional, que puede centrarse en otras tareas críticas del negocio.

Asimismo, en escenarios donde los modelos de datos contienen cálculos avanzados, relaciones de muchos a muchos (no hagáis eso) o jerarquías complejas, SSAS es la herramienta ideal. Su capacidad para procesar y almacenar en memoria estos modelos garantiza que las consultas sean rápidas y precisas, incluso cuando los volúmenes de datos son masivos.

La utilidad de SSAS con Power BI Report Server (PBIRS)

Hay otro caso especial donde SSAS cobra especial relevancia y es en esas organizaciones que necesitan soluciones on-premises. En estos escenarios, SSAS se convierte en un complemento esencial para Power BI Report Server (PBIRS). PBIRS está diseñado para gestionar y publicar reportes de forma local, pero no permite que varios informes accedan al mismo modelo por lo que un SSAS común como fuente de datos se hace imprescindible.

Además, cuando SSAS se combina con PBIRS, se crea una arquitectura en la que el procesamiento analítico es gestionado por SSAS, mientras que PBIRS se encarga de la presentación y administración de los reportes. Esto asegura tiempos de respuesta rápidos incluso en escenarios con alta concurrencia, ya que las consultas complejas se resuelven en el servidor SSAS antes de ser entregadas al usuario.

Por último, el uso de SSAS con PBIRS permite aprovechar sus capacidades de seguridad centralizada. Los permisos configurados en el modelo de SSAS se aplican automáticamente a los reportes alojados en PBIRS, simplificando la administración de la seguridad y asegurando que los datos sensibles estén protegidos.

Azure Analysis Services: la evolución hacia la nube

Y ahora que hemos hablado de entornos 100% on-premises no podemos no hablar de los 100% cloud. Esos entornos donde la escalabilidad y flexibilidad son prioritaria. Para estos casos Microsoft tiene una herramienta llamada Azure Analysis Services (AAS) y no es más que una evolución natural de SSAS a la nube de Azure. AAS ofrece las mismas capacidades avanzadas que SSAS Tabular, pero con las ventajas de estar alojado en la infraestructura de Azure. Esto permite a las organizaciones implementar modelos analíticos centralizados sin preocuparse por la gestión del hardware o el mantenimiento de los servidores.

Azure Analysis Services resulta especialmente útil en arquitecturas híbridas, donde los datos se encuentran tanto en la nube como on-premises. Su integración con servicios cloud como Azure Synapse Analytics además de con servicios locales como SQL Server, facilita la construcción de soluciones escalables que pueden crecer dinámicamente según las necesidades del negocio. Además, AAS hereda la seguridad y gobernanza avanzadas de SSAS, lo que garantiza que las organizaciones puedan mantener el control sobre sus datos mientras aprovechan la elasticidad de la nube.

La elección entre SSAS on-premises y AAS dependerá de los requisitos específicos de cada organización. Sin embargo, AAS ofrece una opción atractiva para aquellas que buscan combinar la potencia analítica de SSAS con la flexibilidad y capacidad de expansión de Azure.

Conclusión

El uso de un servidor SSAS como capa intermedia entre SQL Server y Power BI aporta múltiples beneficios en términos de rendimiento, escalabilidad y gobernanza. Su capacidad para procesar grandes volúmenes de datos, centralizar modelos analíticos y gestionar la seguridad lo convierte en una pieza clave en arquitecturas empresariales complejas. Aunque Power BI puede manejar muchos casos de forma autónoma, la inclusión de SSAS garantiza un nivel de eficiencia y control que es difícil de igualar.

Cuando se utiliza con Power BI Report Server (PBIRS), SSAS se convierte en un motor analítico esencial, capaz de manejar consultas complejas y soportar escenarios de alta concurrencia en entornos on-premises. Esto asegura una solución integral para organizaciones que buscan combinar el poder del análisis en memoria con la flexibilidad y seguridad de un entorno local.

En definitiva, la combinación de SSAS, Power BI y PBIRS representa una solución robusta para cualquier organización que busque maximizar el valor de sus datos. 

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, 0 comentarios
29
Ene
2025

FileTable en Filestream

La característica FileTable en SQL Server es una extensión que tenemos a nuestro alcance para dar superpoderes a la funcionalidad FILESTREAM. Está diseñada para simplificar el almacenamiento, la administración y el acceso a datos no estructurados en nuestras bases de datos relacionales. Suena bien, ¿verdad? En este artículo, veremos en detalle cómo funciona, sus beneficios, casos de uso y consideraciones para implementarla.

Introducción a FileTable

En resumidas cuentas FileTable combina las capacidades de FILESTREAM con una estructura de tabla especial que permite gestionar datos no estructurados, como documentos o imágenes, directamente desde el sistema de archivos. Lo interesante de esta funcionalidad es que los archivos y carpetas almacenados en una FileTable son accesibles desde aplicaciones tradicionales que usan operaciones de entrada/salida (E/S) en el sistema de archivos, mientras que también se pueden consultar y administrar desde SQL Server.

Esta dualidad ofrece lo mejor de ambos mundos: el rendimiento y las características del sistema de archivos junto con la robustez de SQL Server para consultas y transacciones.

Cómo funciona FileTable

Lo principal que debemos saber es que FileTable está estrechamente relacionado con FILESTREAM. Es más, FileTable se basa en FILESTREAM que, como ya vimos, es una funcionalidad que habilita el almacenamiento de datos binarios en el sistema de archivos en lugar de dentro de las páginas de datos de la base de datos. Cuando habilitamos FileTable el comportamiento cambia y mientras que FILESTREAM por sí solo requiere que las aplicaciones interactúen directamente con SQL Server para leer y escribir los datos binarios, FileTable da un paso más al exponer los datos a través del sistema de archivos, como si fueran carpetas y archivos normales.

Estructura de FileTable

Cuando se crea una FileTable, SQL Server configura una tabla especial que incluye las siguientes columnas adicionales, entre otras:

  • stream_id: un identificador único para cada archivo o carpeta.
  • file_stream: una columna tipo VARBINARY(MAX) que almacena los datos binarios del archivo.
  • name: el nombre del archivo o carpeta.
  • file_type: la extensión del archivo.
  • path_locator: una jerarquía que representa la ubicación del archivo o carpeta dentro de la estructura de directorios.
  • is_directory: indica si el registro representa un archivo o una carpeta.

Estas columnas permiten que FileTable se integre perfectamente tanto en el sistema de archivos como en las operaciones SQL.

Carpetas raíz y Namespace

Cada FileTable tiene una carpeta raíz en el sistema de archivos. Los archivos y carpetas dentro de esta raíz se gestionan automáticamente en sincronización con los registros correspondientes en la base de datos. Esto significa que cualquier cambio realizado en el sistema de archivos, como mover, renombrar o eliminar un archivo, se refleja automáticamente en SQL Server.

Casos de uso de FileTable

Esta característica, como veis, eleva la funcionalidad de FILESTREAM y lo hace ideal para aplicaciones de gestión documental, por ejemplo. En concreto, en sistemas de gestión documental donde es necesario almacenar archivos, como PDFs, imágenes o documentos de Word, FileTable nos habilita acceder a los ficheros tanto desde aplicaciones que utilizan SQL Server como desde exploradores de archivos estándar.

También podemos recurrir a esta característica para una migración de aplicaciones legacy. Es decir, aplicaciones heredadas que gestionan archivos directamente en las carpetas del sistema. En estos casos FileTable permite una transición gradual hacia una solución basada en bases de datos sin necesidad de reescribir el acceso a los archivos.

Podría seguir, por ejemplo es muy interesante  para archivos adjuntos en aplicaciones web o móviles. En estas aplicaciones, los archivos adjuntos cargados por los usuarios pueden almacenarse en una FileTable, ofreciendo una gestión más sencilla de los datos no estructurados con capacidades avanzadas de consulta y seguridad.

Configuración de FileTable en SQL Server

Para utilizar FileTable, es necesario habilitar y configurar varias opciones tanto a nivel de instancia como de base de datos. Veamos los pasos principales.

Antes de crear una FileTable, es necesario habilitar FILESTREAM en el servidor. Esto puede hacerse desde SQL Server Configuration Manager. Después debemos configurar la base de datos para habilitar FILESTREAM. No me detengo más en estos pasos porque ya los vimos cuando hablamos de FILESTREAM. Una vez configurado FILESTREAM, podemos crear una FileTable usando un comando SQL. Os pongo un ejemplo:

CREATE TABLE MiFileTable AS FileTable
WITH (
    FileTable_Directory = ‘Documentos’,
    FileTable_Collate_Filename = DATABASE_DEFAULT
);
GO

En este caso, FileTable_Directory define la carpeta raíz donde se almacenarán los archivos.

Beneficios de FileTable

Como vengo mencionando, el principal beneficio de FileTable es el acceso híbrido a los ficheros. FileTable nos permite trabajar con los archivos desde aplicaciones que usan el sistema de archivos o mediante consultas SQL. Derivado de esto, podemos resaltar también la capacidad de tener soporte transaccional. Me refiero a que los cambios en los archivos se pueden incluir en transacciones SQL, garantizando consistencia.

Al ser parte de SQL Server, los archivos se pueden indexar y buscar utilizando capacidades de texto completo lo que también es un gran punto a su favor. 

Por último siempre me gusta destacar el tema de la seguridad integrada. FileTable aprovecha la autenticación y autorización de SQL Server para controlar el acceso a los datos y no solo los permisos sobre la estructura de carpetas.

Limitaciones y consideraciones

Aunque la característica FileTable ofrece muchas ventajas, no está exenta de limitaciones. Por ejemplo, no admite replicación, las FileTables no son compatibles con las tecnologías de replicación tradicionales de SQL Server. Además tiene una gran dependencia del sistema de archivos y ya sabemos que las operaciones intensivas en archivos pueden verse limitadas por el rendimiento del hardware subyacente. 

Otra de las cosas que debemos vigilar muy de cerca es el uso de espacio en disco. Dado que los datos se almacenan en el sistema de archivos, es necesario dimensionar rigurosamente el almacenamiento para evitar problemas de espacio.

Conclusión

FileTable es una funcionalidad poderosa y única de SQL Server que simplifica la gestión de datos no estructurados, al permitir un acceso integrado tanto desde el sistema de archivos como desde consultas SQL. Es especialmente útil en escenarios donde las aplicaciones deben trabajar con archivos directamente, pero también se requiere la capacidad de consulta y gestión avanzada que ofrece SQL Server.

Como siempre, antes de implementar FileTable en un entorno de producción, es fundamental evaluar cuidadosamente los requisitos de la aplicación, las capacidades del sistema y las posibles limitaciones. Si se utiliza correctamente, puede transformar la forma en que gestionamos los datos no estructurados en nuestras bases de datos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
27
Ene
2025

Reduce el tiempo de tus BACKUPS a la mitad o más

La semana pasada publiqué un post sobre las configuraciones avanzadas de backups BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT y cómo impactan en el rendimiento de nuestras copias de seguridad. A raíz de este artículo, muchos comentasteis una optimización mucho más sencilla y que mejora sustancialmente los tiempos de backup, separar las copias en varios ficheros. Y es cierto, incluso cuando no estás escribiendo estos múltiples ficheros en discos separados puedes ganar tiempo con esta configuración. Pero, ¿por qué? Veámoslo en profundidad. Además veremos otro truco que nos puede ahorrar gran cantidad de tiempo en estos procesos.

¿Por qué optimizar los backups?

A menudo no pensamos en que la optimización de rendimiento sea algo que afecte a las copias de seguridad y sin embargo es un campo donde podemos ganar mucho. 

A ver, un momento, si trabajas con una base de datos pequeña o mediana (hasta 300Gb aprox) y tu empresa solo tiene necesidad de acceso a la base de datos en horas de oficina esto no es un problema, no te compliques más. Seguramente tengas tiempo durante la noche y los fines de semana para hacer todas las tareas de mantenimiento completas sin mucho más miramiento. Pero, a medida que los datos crecen o crecen la demanda de los datos acercándose al tan temido 24×7 te va a tocar hacer malabares con los tiempos de los planes de mantenimiento y ajustarlo todo de manera que impacte lo menos posible en el resto de actividad. 

Vale, en estos casos lo mejor sería una aplicación externa de backup por snapshot para reducir el tiempo a casi 0 pero no seamos tan extremos, veamos qué podemos hacer con herramientas nativas.

Separar los backups en varios ficheros

Incluso cuando escribimos los distintos ficheros de copias de seguridad en el mismo disco duro físico o por la misma interfaz de red suele ser más rápido separar las copias de seguridad en varios ficheros. Esto pasa porque SQL Server tiene “cuellos de botella internos” (limitaciones) en la escritura a ficheros de copias de seguridad y al generar varios vamos a poder salvar en gran medida esas limitaciones. 

Es cierto que a cambio vamos a tener que complicar un poco tanto el script de recuperación de la copia de seguridad como el de la restauración pero, ¿de verdad eso es importante? ¿Sigues escribiendo a mano los scripts de backup y restore en 2025? Amigo para eso existen soluciones como los script de Ola Hallengren o el maravilloso sp_DatabaseRestore de Brent Ozar.

Demostración práctica BACKUPS

Veamos cómo impacta en los tiempos el hecho de dividir las copias de seguridad. Para la prueba estoy usando la base de datos StackOverflow2013 de demo de 52 Gb que tiene 4 ficheros de datos y uno de log. Sobre el hardware de mi máquina de pruebas es una máquina con 8 cores (16 vCores), 32Gb de RAM y un disco SSD M2.Tanto los ficheros de datos como el de log y el backup están en la misma unidad, no es lo ideal pero es lo que tengo para esto.

En un primer intento he hecho un backup full sencillo, a un solo fichero y ha tardado 1:52 minutos, la misma prueba de backup pero con 2 ficheros ha tardado 0:49 minutos y sin embargo, en cuanto he puesto 4 ficheros la prueba se ha ido a 3:42 minutos. ¿Por qué estos resultados? En teoría os había dicho que SQL Server limita la cantidad de datos que escribe a un único fichero por lo que podríamos entender que a más ficheros menos tiempo y sin embargo aunque con 2 ficheros hemos bajado los tiempos con 4 se han disparado.

Esto es porque también tenemos que tener en cuenta las limitaciones de velocidad del disco, en mi caso donde además todos los ficheros de datos y log están en la misma unidad esto cobra más sentido. Durante la prueba con un fichero el uso de disco ha rondado el 30%, durante la segunda prueba entre el 65 y 70% y, en la prueba con 4 ficheros el consumo ha sido del 100% del disco. Por tanto, con 4 ficheros mi hardware ha sobrepasado su límite generando tiempos de espera por cuellos de botella en la E/S de disco.

Demostración práctica RESTORE

Ahora os comparto los resultados que he tenido en la restauración de estas copias que acabo de hacer. Para esta prueba todos los backups siguen en la misma unidad que los datos y los logs y la base de datos existente va a ser sobrescrita, es decir no hay que generar de nuevo los ficheros. ¿Qué pasará?

Aquí los tiempos se disparan, la restauración de la copia con un solo fichero ha tardado 7:18 minutos. La restauración de la copia con dos ficheros, por su parte, ha demorado 11:07. Por último la copia de 4 ficheros ha tomado 10:19 minutos para restaurarse.

Cabe destacar que todas las pruebas de restauración han tenido el uso de disco al 100% en todo momento por lo que no puedo dar por 100% fiables los datos al haber encontrado tán pronto el límite del hardware. Ya os había dicho que la configuración de todo en el mismo disco no es una buena idea.

Bonus extra: Verificar los backups

Otra de las cosas que seguro que estás haciendo es verificar los backups a la hora de hacerlos. Verificar los backups no es que sea una buena práctica es que es imprescindible si queremos estar seguros y cumplir con la normativa vigente para muchas empresas. Como se suele decir, un backup sin probar no es un backup, es como el gato de Schrödinger (claro que he tenido que buscar en google como se escribe). 

Sin embargo, que tengamos que comprobar nuestras copias de seguridad no significa que debamos hacerlo al momento de hacer la copia, ni siquiera significa que debamos hacerlo en el mismo servidor. 

Si nuestros backups están en una unidad de red vamos a poder probarlas de manera independiente y en una máquina distinta al servidor de producción (por ejemplo el servidor de DR o el de pruebas) vamos a poder ganar un 30% o más del total de tiempo de la tarea de copias de seguridad. Incluso, podemos hacer uso del procedimiento sp_DatabaseRestore que he mencionado antes y hacer un CheckDB a la base de datos en este proceso separado de verificación. ¿Te das cuenta de lo que te estoy diciendo, verdad? Más seguridad y mejor rendimiento sin apenas complicarte.

Conclusión

Optimizar los procesos de backups no es solo cuestión de ahorrar tiempo, sino también de garantizar que nuestro entorno sea resiliente, eficiente y cumpla con los estándares de seguridad. A través de ajustes relativamente simples, como dividir los backups en múltiples ficheros o separar la verificación en un proceso independiente, podemos obtener grandes beneficios sin necesidad de recurrir a herramientas externas costosas.

Sin embargo, como hemos visto en las pruebas, no existe una configuración única que funcione para todos los escenarios. Cada entorno tiene sus propias limitaciones, ya sea por el hardware, la arquitectura de los datos o los requisitos operativos. Por eso, es fundamental medir, analizar y ajustar las configuraciones basándonos en pruebas reales. La clave está en encontrar el equilibrio entre el rendimiento y la fiabilidad, adaptando las estrategias a las características de nuestros sistemas.

En resumen, la optimización no siempre implica complejidad, y pequeños cambios pueden marcar una gran diferencia. Ahora te toca a ti: ¿qué ajustes has probado en tus backups? ¿Qué resultados has obtenido? Como siempre, la mejor forma de aprender es compartiendo experiencias.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
24
Ene
2025

SQL Server Big Data Clusters

Hoy vamos a hablar de una funcionalidad no tan conocida de SQL Server. Esta funcionalidad se estrenó con SQL Server 2019 y realmente no ha tenido la adopción del mercado deseada. Quizá porque al poco tiempo le surgió un enemigo dentro de su propia casa, Microsoft Fabric. Pero bueno, no es mi objetivo hacer análisis de mercado, simplemente vamos a descubrir hoy SQL Server Big Data Clusters (BDC). 

SQL Server Big Data Clusters es una solución avanzada para gestionar, analizar y transformar grandes volúmenes de datos integrando el potencial de SQL Server con tecnologías de Big Data como Apache Spark y Hadoop Distributed File System (HDFS). Como os decía, en este artículo, profundizaremos en qué consiste esta tecnología, sus componentes clave y cómo se implementa en entornos empresariales modernos.

¿Qué es SQL Server Big Data Clusters?

Empecemos por el principio, SQL Server Big Data Clusters es una implementación de contenedores que permite desplegar un clúster escalable de SQL Server, Spark y HDFS utilizando Kubernetes como orquestador. La solución está diseñada para trabajar con datos estructurados, no estructurados y semiestructurados, facilitando tanto la consulta como el procesamiento distribuido.

Esta plataforma no solo facilita la consulta sobre grandes volúmenes de datos, sino que también permite integrar fuentes de datos externas y realizar análisis avanzados directamente desde SQL Server.

Componentes Clave de SQL Server Big Data Clusters

Ahora que ya sabemos lo que es, veamos de qué se compone y que debemos tener en cuenta. 

  • Control Plane: El componente principal que debemos conocer es el Control Plane. Es el núcleo del clúster que administra la infraestructura y orquesta las operaciones entre los diferentes servicios. Kubernetes actúa como el motor principal para gestionar el despliegue de los recursos.
  • SQL Server Master Instance: SQL Server Master Instance es la instancia principal de SQL Server en el clúster que actúa como punto de entrada para las consultas y la administración de datos. Desde aquí se pueden realizar operaciones T-SQL estándar, así como consultas externas.
  • Data Pool: El Data Pool es el componente que almacena y gestiona los datos estructurados que se cargan directamente en el clúster para procesamiento intensivo. Es ideal para cargas de trabajo analíticas donde los datos se distribuyen y procesan en paralelo.
  • Storage Pool: El Storage Pool es la integración de Hadoop Distributed File System (HDFS) y se usa para manejar datos no estructurados. Este almacenamiento es distribuido y permite el escalado horizontal para manejar grandes volúmenes de datos.
  • Compute Pool: El componente Compute Pool es el grupo diseñado para manejar consultas distribuídas sobre grandes datasets. A grandes rasgos, lo que hace es ejecutar SQL Server en contenedores con funcionalidades de consulta paralela.
  • Spark Pool: El Spark Pool, como su propio nombre indica es el componente de Apache Spark que proporciona capacidades de procesamiento de datos. Nos sirve para optimizar tareas de Machine Learning, ETL y análisis en tiempo real.Application Services: Por último, los Application Services nos facilitan el desarrollo y despliegue de aplicaciones personalizadas dentro del clúster, incluyendo APIs, paneles analíticos y aplicaciones de Machine Learning.

Beneficios Principales de SQL Server Big Data Clusters

Lo más destacable de esta solución es su escalabilidad y flexibilidad. Al estar basado en Kubernetes, se pueden escalar los recursos del clúster según las necesidades de la carga de trabajo, optimizando tanto el costo como el rendimiento.

Además, el procesamiento de datos distribuido es otra de sus grandes ventajas. Gracias a HDFS y Spark, los BDC permiten procesar grandes volúmenes de datos de manera distribuida, reduciendo significativamente los tiempos de procesamiento.

Por si esto fuese poco, tenemos también su gran capacidad de integración de fuentes de datos externas. SQL Server BDC soporta PolyBase, permitiendo la consulta y análisis de datos almacenados en plataformas como Azure Data Lake, Amazon S3, y otros sistemas externos, directamente desde SQL Server.

Como veis, tenemos a nuestro alcance todo un ecosistema analítico completo que incluye capacidades analíticas avanzadas, como análisis en tiempo real, integración con herramientas de Machine Learning y capacidades ETL robustas.

Casos de Uso

SQL Server Big Data Clusters, gracias a sus capacidades para el análisis de datos masivos, es ideal para organizaciones que manejan grandes cantidades de datos estructurados y no estructurados. Estas organizaciones pueden beneficiarse de la capacidad de consulta distribuida y almacenamiento escalable de los BDC.

Además su integración multifuente hace que empresas con datos distribuidos en múltiples plataformas pueden usar BDC para consolidar y analizar datos sin necesidad de migrarlos.

Otro de los casos de uso de rabiosa actualidad es para escenarios de Machine Learning e Inteligencia Artificial. Con Spark integrado, los BDC son ideales para implementar modelos de Machine Learning en entornos de Big Data. Pero no hace falta apuntar tan alto, la combinación de Spark y SQL Server facilita la transformación de datos y su preparación para análisis haciendo accesibles los procesos ETL más complejos.

Implementación de SQL Server Big Data Clusters

Como hemos visto, la instalación de SQL Server BDC requiere un entorno Kubernetes configurado. A continuación, os resumo los pasos básicos:

  1. Preparar el Entorno Kubernetes: Lo primero que deberemos hacer es configurar un clúster de Kubernetes compatible con SQL Server BDC, como AKS, OpenShift o cualquier distribución Kubernetes certificada.
  2. Configurar el Almacenamiento: Una vez el entorno de Kubernetes está configurado deberemos seleccionar el almacenamiento persistente para HDFS y otros componentes del clúster.
  3. Desplegar el Clúster: En este punto ya estamos en disposición de usar herramientas como Azure Data CLI (azdata) para desplegar los contenedores de SQL Server BDC en el clúster Kubernetes.
  4. Configurar el Acceso: Por último, no debemos olvidarnos de implementar reglas de acceso seguro y configurar el acceso a las fuentes de datos externas.

¿Qué pasa ahora que ha llegado Fabric?

SQL Server BDC fue concebido como una solución para gestionar datos estructurados y no estructurados en entornos híbridos y locales, utilizando Kubernetes como orquestador. Sin embargo, Fabric ha superado a BDC en varias áreas críticas.

Mientras que BDC ofrece escalabilidad mediante Kubernetes, Fabric utiliza una arquitectura nativa en la nube, permitiendo una expansión horizontal más ágil y transparente. Esto simplifica la gestión de recursos y permite un enfoque más integral hacia el análisis en tiempo real. Fabric también centraliza las herramientas de análisis, desde la ingestión de datos hasta su visualización, lo que elimina la necesidad de múltiples tecnologías y reduce la complejidad operativa. Por el contrario, BDC requiere una integración manual de componentes como PolyBase y HDFS, aumentando la carga administrativa. A todo esto hay que sumar que, en Fabric, al incorporar servicios completamente gestionados, se reduce drásticamente la necesidad de conocimientos especializados para administrar clústeres, facilitando la adopción incluso para equipos con menos experiencia en Kubernetes.

Mientras que Fabric brilla en escenarios modernos como análisis avanzado, gobernanza centralizada y machine learning, BDC sigue siendo relevante únicamente para organizaciones con fuertes inversiones en infraestructura híbrida local que requieren una compatibilidad estrecha con SQL Server. 

Debemos tener en cuenta que aunque Microsoft no ha declarado explícitamente el final del soporte para BDC, su desarrollo está estancado en favor de Fabric. Esto posiciona a BDC como una tecnología de nicho, útil en entornos muy específicos o en organizaciones que todavía no pueden migrar completamente a la nube.

Conclusión

SQL Server Big Data Clusters representó un avance significativo en su tiempo, combinando SQL Server con tecnologías de Big Data para abordar desafíos complejos de gestión de datos. Sin embargo, la llegada de Microsoft Fabric ha redefinido este espacio, ofreciendo una solución más moderna, integrada y eficiente para la mayoría de los casos de uso actuales.

Si bien BDC sigue siendo útil en ciertos contextos específicos, Microsoft Fabric es claramente el futuro de la analítica de datos en el ecosistema de Microsoft. Para maximizar el valor y mantenerse alineados con el roadmap tecnológico, las organizaciones deben considerar una transición estratégica hacia Fabric. Este cambio no solo optimiza la infraestructura, sino que también abre nuevas oportunidades para aprovechar al máximo los datos en un entorno dinámico y escalable. Fabric no es simplemente una evolución; es una revolución en la forma en que entendemos y utilizamos los datos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en SQL Server, 1 comentario
22
Ene
2025

FILESTREAM en SQL Server

Aunque aquí somos de bases de datos relacionales y de datos estructurados, en ocasiones vamos a tener que lidiar con el manejo de datos no estructurados, como imágenes, videos y documentos. Desde el punto de vista relacional esto representa un desafío significativo en nuestras bases de datos. SQL Server aborda este problema con FILESTREAM, una característica que permite almacenar grandes objetos binarios (BLOBs) en el sistema de archivos NTFS mientras se mantienen gestionados a través de la base de datos. FILESTREAM combina la eficiencia del acceso directo al sistema de archivos con las capacidades transaccionales y de gestión de datos de SQL Server, proporcionando una solución perfecta (teóricamente) para escenarios que involucran datos no estructurados.

Arquitectura de FILESTREAM

Como os decía en la introducción, FILESTREAM integra el almacenamiento de datos binarios con la gestión relacional de SQL Server. Para conseguir esto, en lugar de guardar los datos binarios directamente en las páginas de datos de la base de datos, estos se almacenan en archivos físicos dentro de un directorio gestionado por SQL Server. Cada fila en la tabla que contiene datos FILESTREAM tiene un puntero que referencia el archivo correspondiente en el sistema de archivos. Este diseño garantiza que los datos binarios y relacionales estén sincronizados, respetando las propiedades ACID de las transacciones.

Internamente, el almacenamiento de FILESTREAM se organiza mediante filegroups especiales que se configuran para contener datos FILESTREAM. Estos filegroups actúan como un vínculo lógico entre la base de datos y el sistema de archivos, permitiendo a SQL Server gestionar la ubicación física de los datos binarios de forma transparente para el usuario.

Configuración de FILESTREAM

Habilitar FILESTREAM requiere configuraciones específicas tanto en el sistema como en SQL Server. En primer lugar, FILESTREAM debe activarse a nivel de instancia mediante SQL Server Configuration Manager. Para ello iremos a SQLServer Configuration Manager, abriremos las oropiedades de la instancia y en la pestaña FILESTREAM marcaremos el check “Activar FILESTREAM”. En esta configuración, es necesario habilitar el acceso desde Transact-SQL y, opcionalmente, el acceso de entrada/salida directa mediante la API de Win32 para escenarios que requieran un rendimiento optimizado.

Tras habilitar FILESTREAM en la instancia, se debe configurar un filegroup en la base de datos para almacenar los datos binarios. Este filegroup se asocia a un directorio del sistema de archivos que actuará como el almacenamiento físico de los archivos. Por ejemplo, mediante T-SQL se puede crear un filegroup FILESTREAM y asignarle una ruta específica:

ALTER DATABASE MiBaseDeDatos
ADD FILEGROUP FG_FileStream CONTAINS FILESTREAM;

ALTER DATABASE MiBaseDeDatos
ADD FILE (
    NAME = 'FSData',
    FILENAME = 'C:\SQLData\FileStream'
) TO FILEGROUP FG_FileStream;

Con el filegroup configurado, se pueden definir tablas con soporte FILESTREAM. Las tablas deben incluir una columna VARBINARY(MAX) declarada con el atributo FILESTREAM, lo que habilita el almacenamiento de datos binarios en el sistema de archivos. Un ejemplo de definición de tabla es el siguiente:

CREATE TABLE Documentos (Ç
    ID INT IDENTITY PRIMARY KEY,
    Nombre NVARCHAR(100),
    Archivo VARBINARY(MAX) FILESTREAM,
    FechaCreacion DATETIME DEFAULT GETDATE()
);

Acceso y Manipulación de Datos

SQL Server proporciona dos métodos principales para acceder y manipular datos FILESTREAM. El primero utiliza Transact-SQL, lo que permite realizar operaciones de inserción, actualización y recuperación de datos binarios como se haría con cualquier columna relacional. Por ejemplo, para insertar un archivo en una tabla FILESTREAM, se puede utilizar el siguiente comando:

INSERT INTO Documentos (Nombre, Archivo)
VALUES ('Archivo1', CAST('Contenido del archivo' AS VARBINARY(MAX)));

Para recuperar el archivo, se emplea una consulta estándar:

SELECT Nombre, Archivo FROM Documentos;

El segundo método de acceso emplea la API de Win32 que he mencionado antes. Esta API está diseñada para acceder directamente a los archivos almacenados en el sistema de archivos. Esta forma de trabajar es más compleja pero, particularmente útil en escenarios de alto rendimiento, ya que permite operaciones de lectura y escritura secuenciales más eficientes. Para usar este método, SQL Server proporciona la función GET_FILESTREAM_TRANSACTION_CONTEXT(), que genera un identificador de contexto transaccional necesario para acceder a los archivos.

Ventajas de FILESTREAM

Ya hemos visto la principal ventaja y es que FILESTREAM combina el rendimiento del sistema de archivos con la gestión transaccional de SQL Server. Al mover los datos binarios al sistema de archivos, reducimos la presión sobre el almacenamiento de páginas de datos y mejoramos la escalabilidad. Además, se mantiene la integridad transaccional, lo que garantiza que las operaciones de datos relacionales y binarios sean consistentes. Otro beneficio clave es la compatibilidad de FILESTREAM con las herramientas de copias de seguridad y recuperación de SQL Server, lo que simplifica la protección de datos en soluciones empresariales.

Limitaciones de FILESTREAM

A pesar de sus ventajas, FILESTREAM tiene limitaciones que deben considerarse antes de su implementación. Una de las principales restricciones es su dependencia del sistema de archivos NTFS, lo que limita su uso en otros sistemas operativos o configuraciones de almacenamiento. Es decir, olvídate de usarlo en SQL Server en linux o en docker. Además, no es compatible con todas las características avanzadas de SQL Server, como la replicación transaccional. Con Always On si que es compatible pero, requiere un cuidado especial y, en mi experiencia, es fuente de problemas de integridad de las bases de datos. Si lo activas, asegúrate de tener chequeos frecuentes de la base de datos y prepárate para reparar errores a menudo. La administración de permisos y seguridad también es más compleja, ya que los archivos están físicamente accesibles desde el sistema operativo.

Por último, la integración de FILESTREAM con las estrategias de copias de seguridad puede requerir configuraciones adicionales, ya que los datos relacionales y binarios deben mantenerse sincronizados. Esto puede aumentar la complejidad operativa, especialmente en entornos con grandes volúmenes de datos binarios.

Conclusión

FILESTREAM es una solución técnica avanzada para gestionar datos no estructurados en SQL Server. Su capacidad para combinar la eficiencia del acceso directo al sistema de archivos con la integridad transaccional lo convierte en una herramienta valiosa en escenarios donde el rendimiento y la consistencia son críticos. Sin embargo, su implementación requiere un conocimiento técnico sólido y una planificación cuidadosa para maximizar sus beneficios y evitar problemas operativos. Con una configuración adecuada y un enfoque técnico riguroso, FILESTREAM puede ser una solución escalable y robusta para aplicaciones que manejan grandes volúmenes de datos binarios.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 2 comentarios