Infra

Nov

2024

Replicar datos de SQL a Fabric

Mucho hemos hablado en el blog de como pasar datos de SQL Server en local a la nube, o de la nube a local. Sin embargo, siempre nos hemos centrado en el ecosistema de SQL Server y Azure SQL que, con pequeñas diferencias, cubren las mismas necesidades. Pero, ¿qué pasa si lo que necesitamos es pasar nuestros datos de SQL recurrentemente a un servicio SaaS en la nube para ciencia y análisis de datos?. Eso es lo que vamos a ver hoy, cómo pasar nuestros datos de SQL Server a Fabric ya sea a un Lakehouse o a un Datawarehouse.

Fabric lakehouse vs Datawarehouse ¿qué son?

Al hablar de Fabric, uno de los primeros pasos cruciales es entender sus componentes principales para el almacenamiento de los datos, el Lakehouse y el DataWarehouse. Aunque realmente todo lo que almacenemos en Lakehouse o en Datawarehouse va a estar almacenado en el mismo sitio, nuestro Onelake, por encima de esa capa pura de almacenamiento tendremos que decidirnos por una de las dos estrategias anteriores de gestión de los datos. Puede parecer trivial, incluso en muchas ocasiones se confunden o se utilizan indistintamente pero, la realidad es que cada uno tiene características y funciones específicas dentro de un entorno de ciencia de datos y análisis en la nube. Estas particularidades van a ser claves a la hora de trabajar con ellos por lo que es importante que tengamos claro cuál va a ser nuestro destino antes de plantear el método de envío de datos.

Fabric Datawarehouse

Fabric Datawarehouse es una solución de almacenamiento de datos que integra las capacidades de un data warehouse tradicional con la flexibilidad de un data lake. Gracias a esta arquitectura podremos almacenar, procesar y analizar grandes volúmenes de datos estructurados y semiestructurados en un entorno unificado, lo que nos facilitará la gestión y el análisis de la información.

Una característica distintiva de Fabric Datawarehouse es su almacenamiento centrado en el lago de datos (One Lake), basado en el formato abierto Delta Lake. Este enfoque nos permite hacer uso de transacciones ACID y una interoperabilidad fluida con otras cargas de trabajo de Fabric, eliminando la necesidad de múltiples copias de datos y garantizando la consistencia y confiabilidad de la información. Además su punto de conexión SQL nos va a permitir consultar y manipular datos con código T-SQL

Fabric Lakehouse

Fabric Lakehouse es una arquitectura de datos integrada en Microsoft Fabric que combina las funcionalidades de un data lake con las capacidades de un data warehouse. Esta estructura nos permite almacenar, procesar y analizar grandes volúmenes de datos no estructurados, semiestructurados y estructurados en un solo entorno, simplificandonos la gestión y el análisis de los datos.

El concepto de lakehouse en Fabric fusiona la escalabilidad y flexibilidad de un datalake, donde se puede almacenar información en su formato nativo, con el rendimiento y las capacidades analíticas de un data warehouse, facilitando la ejecución de consultas SQL de lectura directamente sobre los datos sin necesidad de moverlos. Fabric Lakehouse soporta el uso de diversos lenguajes de consulta y herramientas de análisis, como SQL, Spark y Power BI, proporcionando un entorno colaborativo y unificado.

Además, Fabric Lakehouse utiliza Delta Lake, que añade un nivel de transaccionalidad y consistencia a los datos almacenados, algo crucial en entornos de análisis donde la integridad de los datos es prioritaria. Delta Lake permite realizar lecturas y escrituras simultáneas y asegura la disponibilidad de datos limpios y consistentes para el análisis.

Enviar datos de SQL a Fabric

Bien, ahora que ya hemos decidido cual de los sistemas tenemos en destino vamos a ver las posibilidades de sincronización que tenemos para los datos de SQL. Vamos a centrarnos principalmente en dos herramientas, los Dataflows gen 2 y los pipelines.

Dataflows Gen2

Los Dataflows Gen2 son una opción no-code que nos permite llevar a Fabric datos de casi cualquier origen. Son una evolución de los Dataflows de Power BI, con un aspecto similar pero, con una gran diferencia, permiten seleccionar el destino. Gracias a esta funcionalidad vamos a poder usarlos para llevar nuestros datos de SQL o Azure SQL a Fabric, ya usemos Lakehouse o Datawarehouse, sin problema.

Para crearlo, simplemente accederemos a la interfaz de Dataflows Gen2 dentro del menú de Data Factory y, a través de la interfaz gráfica seleccionaremos nuestro origen, ya sea Azure SQL o una puerta de enlace previamente configurada con la conexión a SQL Server. A partir de aquí, podremos seleccionar las tablas o vistas que replicar y aplicar transformaciones, siempre cuidando de no romper el plegado de consultas o lo notaremos en el rendimiento.

Pipelines

Los pipelines son otra alternativa sencilla y no-code para la copia de datos, aunque tienen un inconveniente. Si bien es teóricamente posible usarlo para transferir nuestros datos desde SQL Server hacia Fabrik Lakehouse o Datawarehouse, lo cierto es que hacia este último destino va a requerir de una serie de pasos adicionales que complican el proceso hasta hacer que no sea recomendable, al menos en mi opinión.

Entonces, si vas a trabajar con Fabric Lakehouse la cosa es simple, abres Pipelines desde la misma ventana de Data Factory que hemos comentado antes y practicamente sigues el asistente. Te va a pedir el origen (tu Azure SQL o tu puerta de enlace con la conexión a SQL Server, igual que antes), la tabla o consulta que se va a replicar y el destino con su tipo de datos para cada columna.

Bonus track: Fabric Mirroring, Shortcuts y Notebooks

Los que conocéis el ecosistema de Fabric sabéis que además de Dataflows Gen2 y Pipelines tenemos disponibles otras herramientas como son los mirroring shortcuts y Notebooks. Veamos qué podemos hacer con ellas.

Shorcuts: Igual que los accesos directos a los que estamos acostumbrados en nuestros sistemas operativos de Windows, los shortcuts en Fabric nos permiten leer información de otras fuentes sin tener que copiarlas a nuestro One Lake. Suena bien, ¿verdad? Pues es muy bonito pero, lamentablemente no están implementados ni para SQL Server ni para ninguna solución de SQL en la nube.
Notebooks: Los cuadernos (notebooks) son la principal herramienta de integración y manipulación de datos en Fabric. Sin embargo, no son compatibles con orígenes de una puerta de enlace por lo que solo podremos usarlos para copiar datos desde orígenes Azure SQL ya sean Managed Instance o bases de datos sin servidor.
Mirroring: He dejado lo mejor para el final. Mirroring es una nueva funcionalidad que promete replicar nuestras bases de datos SQL a Fabric. Sin embargo, aún está en Public Preview y solo para orígenes Azure SQL Database (bbdd sin servidor). Esperemos en un futuro cercano verlo en GA para todos los orígenes SQL Server.

Conclusión

Migrar datos de SQL Server a Microsoft Fabric abre un mundo de posibilidades para el análisis avanzado en la nube. Con herramientas como Dataflows Gen2 y Pipelines, podemos transferir datos de manera eficiente y sin código hacia entornos unificados de Fabric, eligiendo entre el Lakehouse, ideal para datos en formatos variados, y el Data Warehouse, optimizado para consultas estructuradas. Fabric facilita la gestión y transformación de datos en un entorno SaaS seguro, apoyado en OneLake y Delta Lake, que garantizan consistencia y escalabilidad. Así, centralizamos el análisis y optimizamos el rendimiento, aprovechando todo el potencial de nuestros datos en la nube.

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!

Nov

2024

Puertas de Enlace Power BI y Fabric

En el análisis de datos con Power BI o Fabric, las puertas de enlace juegan un papel fundamental. Son el puente que nos permite conectar de forma segura y eficiente los servicios en la nube de Microsoft con los datos locales de nuestra organización. Estas herramientas facilitan la comunicación entre los sistemas internos y Power BI, garantizando que los datos estén siempre actualizados y disponibles para análisis en tiempo real. Sin embargo, las puertas de enlace no solo son esenciales para Power BI; también pueden integrarse con Microsoft Fabric, potenciando los flujos de trabajo avanzados y las capacidades de procesamiento en paralelo. Este artículo se inspira en los artículos de Toni Jurado en explorandodatos.com, quien ha profundizado en las características esenciales y las mejores prácticas de las puertas de enlace en Power BI, y busca añadir una perspectiva integral sobre su uso y consideraciones técnicas.

¿Qué es una puerta de enlace de Power BI y Microsoft Fabric?

Las puertas de enlace de Power BI y Fabric son un componente de software (programa) que se instala en nuestros servidores locales y que permiten a los servicios en la nube de Microsoft conectarse de manera segura a los datos almacenados en nuestras instalaciones on-premises. Esto es especialmente valioso para las empresas que, por razones de seguridad o privacidad, no desean o no pueden migrar sus datos sensibles a la nube. La puerta de enlace actúa como un intermediario, procesando solicitudes de datos y cifrando la comunicación entre la fuente local y el servicio en la nube, asegurando así la privacidad y protección de la información.

En la práctica, la puerta de enlace permite realizar transformaciones y filtrados de datos en el entorno local, reduciendo el volumen de datos que se envía a la nube. Esto optimiza el uso del ancho de banda de la red y mejora el rendimiento de las consultas en Power BI o Fabric. Sin embargo, este procesamiento requiere recursos en el servidor donde está instalada la puerta de enlace, lo que implica ciertas consideraciones técnicas a la hora de configurarla y mantenerla.

Tipos de puertas de enlace: Personal y Estándar

Existen dos tipos de puertas de enlace y, aunque las dos opciones sirven para enviar nuestros datos de los servidores locales a la nube de Power BI o de Fabric, tienen sus diferencias significativas. Tendremos que elegir una u otra en función de nuestras necesidades.

Puerta de enlace personal

Esta versión está diseñada para un único usuario y es ideal para casos de uso individual o pruebas rápidas. Permite conectar Power BI con fuentes de datos locales, pero está limitada a un solo usuario y no es adecuada para entornos de producción. No es compatible con los servicios de Microsoft Fabric.

Puerta de enlace estándar

Pensada para su uso en entornos de producción, esta puerta de enlace puede ser utilizada por múltiples usuarios y soporta una configuración avanzada para integrarse, además de con Power BI, con otros servicios, como Power Automate, Power Apps y Microsoft Fabric. Es ideal para empresas que manejan grandes volúmenes de datos y requieren análisis en tiempo real.

Es importante tener en cuenta que, aunque las puertas de enlace personales son útiles para usuarios individuales, en entornos de producción o con Microsoft Fabric se recomienda siempre utilizar las puertas de enlace estándar. Esto garantiza el soporte multiusuario, configuraciones avanzadas de balanceo de carga y alta disponibilidad, que son esenciales para entornos de análisis de datos complejos.

Uso de las puertas de enlace: Orígenes de datos compatibles

Una de las grandes ventajas de las puertas de enlace en Power BI y Fabric es su compatibilidad con una amplia variedad de orígenes de datos locales. Esto permite a las organizaciones integrar en sus análisis en la nube prácticamente cualquier sistema interno sin necesidad de migrar los datos a la nube, y manteniendo el control y la seguridad de la información. A continuación, os nombro algunos de los principales orígenes de datos locales que pueden conectarse a través de las puertas de enlace estándar:

Bases de datos relacionales

Entre los sistemas compatibles podemos encontrar SQL Server, Oracle Database, MySQL, PostgreSQL, DB2 y Teradata. Estos sistemas tienen la capacidad de plegar las consultas y nos permiten la conexión en modo DirectQuery, que consulta los datos en tiempo real, o en modo de importación, ideal para escenarios de carga periódica. Ambos modos facilitan el análisis sin necesidad de replicar todos los datos en la nube.

Fuentes de datos de archivos

Las puertas de enlace permiten el acceso a archivos de Excel, CSV, archivos de texto, XML y carpetas compartidas en red. Los datos de estos archivos pueden ser actualizados automáticamente para reflejar la última versión sin intervención manual. Esto es especialmente útil en entornos donde los datos se almacenan en archivos distribuidos en múltiples ubicaciones.

Sistemas de almacenamiento en la nube privada

Las puertas de enlace pueden conectar servicios de almacenamiento en la nube privada alojados dentro del entorno corporativo, incluyendo SAP HANA y SAP BW. Estos sistemas se encuentran en muchas grandes empresas, y la puerta de enlace asegura que los datos permanezcan en la red local mientras están disponibles para análisis en Power BI y Fabric.

Sistemas de información y aplicaciones empresariales

Power BI y Fabric permiten conectarse a sistemas como Microsoft Dynamics 365 on-premises y servicios OData, incluyendo SharePoint on-premises y otros servicios web empresariales. Estas integraciones son clave para empresas que utilizan sistemas empresariales complejos y desean incorporar datos de múltiples fuentes sin comprometer la seguridad.

Sistemas de mensajería y API REST

Las puertas de enlace también son compatibles con servicios que utilizan API REST, lo que permite integrarse con aplicaciones internas que exponen datos mediante servicios web. Esta opción ofrece flexibilidad para conectar sistemas personalizados de la organización.

Configuración de puertas de enlace en entornos de producción

La instalación y configuración de una puerta de enlace requiere ciertos conocimientos técnicos, especialmente en entornos de producción. Para instalar una puerta de enlace, debemos contar con un equipo (idealmente un servidor) que cumpla con los requisitos técnicos de Microsoft y que esté optimizado para manejar el flujo de datos y la carga de procesamiento.

Una vez instalada, la configuración de la puerta de enlace se gestiona desde el portal de administración de Power BI, donde podemos definir permisos de acceso a las fuentes de datos, configurar la autenticación de usuarios y programar las actualizaciones de datos. Las opciones de administración permiten a sus responsables controlar el acceso de los usuarios y gestionar los permisos para asegurar que solo personas autorizadas puedan acceder a los datos a través de la puerta de enlace.

Buenas prácticas para la instalación de puertas de enlace

Existen ciertas buenas prácticas recomendadas para optimizar el rendimiento y la seguridad de las puertas de enlace en entornos corporativos. A continuación, os comparto algunas consideraciones clave a tener en cuenta al instalar una puerta de enlace:

Separación de la puerta de enlace y el servidor de bases de datos

Aunque pueda parecer tentador, no es recomendable instalar la puerta de enlace en el mismo servidor donde reside la base de datos, ya que ambos servicios requieren recursos significativos. Si comparten el mismo servidor, podrían surgir conflictos de recursos en momentos de alta demanda, afectando la estabilidad y el rendimiento de ambos servicios. En su lugar, se recomienda instalar la puerta de enlace en un servidor dedicado que cuente con recursos suficientes para manejar la carga de trabajo de la puerta de enlace.

Ubicación en la misma subred

Para minimizar la latencia y optimizar el rendimiento de las transferencias de datos, es ideal que la puerta de enlace y el servidor de origen de los datos se encuentren en la misma subred. Esto permite una comunicación más rápida y reduce el riesgo de pérdida de paquetes de datos. Cuando la puerta de enlace y la base de datos están en diferentes subredes o ubicaciones, se puede experimentar una mayor latencia, lo cual afecta la eficiencia en el análisis de datos.

Ahora una recomendación personal. El tráfico de datos generado entre la puerta de enlace y un servidor de base de datos puede ser considerable lo que puede afectar al rendimiento de la red y verse afectado por otros usuarios de la red. Para estos casos la solución ideal es una subred aislada entre el servidor de bases de datos y la puerta de enlace. De este modo, nuestro servidor de bases de datos tendrá dos tarjetas de red, cada una en una red, una para el tráfico de los usuarios y otra exclusiva de comunicación con la puerta de enlace. Tampoco es raro encontrarnos en escenarios empresariales con una subred entre servidores aislada de los usuarios. En estos casos, deberéis valorar con los técnicos de redes si la puerta de enlace debe ir en esta red o en una dedicada.

Además, en entornos corporativos complejos, se recomienda aislar el tráfico de la puerta de enlace y la base de datos mediante VLANs independientes. Esta práctica no solo permite gestionar mejor el ancho de banda como acabamos de comentar sino que mejora la seguridad. La segmentación es particularmente importante cuando se trabaja con datos sensibles, ya que ayuda a cumplir con las normativas de privacidad y seguridad.

Balanceo de carga y alta disponibilidad

En organizaciones con grandes volúmenes de datos o con una alta frecuencia de actualizaciones, es recomendable implementar un clúster de puertas de enlace. Esto permite distribuir la carga de trabajo entre varias instancias, garantizando alta disponibilidad. En caso de que una puerta de enlace falle, otra puede asumir su carga, evitando interrupciones. El balanceo de carga es esencial cuando se trabaja con Microsoft Fabric, especialmente cuando usamos procesamiento de datos en tiempo real que requiere una infraestructura robusta y estable. Estos cluster de puertas de enlace solo los podremos hacer con puertas de enlace estándar, las personales no lo permiten.

Monitorización de recursos

Como la puerta de enlace realiza procesamiento de datos local, es importante monitorizar regularmente los recursos del servidor, como CPU, memoria y uso de red. Si detectamos un uso elevado de recursos, podríamos necesitar escalar la capacidad del servidor o migrar la puerta de enlace a un servidor con mayor capacidad para evitar problemas de rendimiento.

Consideraciones especiales para Microsoft Fabric

Con la integración de Microsoft Fabric, las puertas de enlace han ampliado su funcionalidad, permitiendo manejar flujos de datos más complejos y ejecutar análisis en tiempo real. En entornos de Fabric, es fundamental que la puerta de enlace tenga acceso a suficiente capacidad de procesamiento para soportar las demandas adicionales. Esto incluye configuraciones avanzadas para equilibrar la carga de procesamiento y distribuir las solicitudes de datos de forma eficiente. Además, como ya os he mencionado solo las puertas de enlace estándar son compatibles con Fabric, no vamos a poder usar una puerta de enlace personal.

Conclusión

Las puertas de enlace de Power BI y Microsoft Fabric son herramientas indispensables para las organizaciones que necesitan conectar sus datos locales con el servicio en la nube de forma segura y eficiente. Al permitir el procesamiento local de datos, las puertas de enlace optimizan el uso del ancho de banda y aseguran que solo los datos necesarios se transmiten a la nube, reduciendo la carga en la red y mejorando el rendimiento.

Este artículo y las ideas expuestas han sido inspirados en los artículos de Toni Jurado en explorandodatos.com, quien ha compartido valiosos conocimientos sobre el uso de puertas de enlace en Power BI. También os recomiendo el video sobre este tema del Power Quiz presentado por Ricardo Rincón y Diego jurado con Toni Jurado como quiz maker.

Espero que esta guía contribuya a un entendimiento más profundo de estas herramientas y a su implementación eficaz en entornos empresariales. 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!

Nov

2024

Migrar datos de Azure a local

En ocasiones nos vamos a encontrar con que necesitamos migrar una base de datos que tenemos alojada en Azure hacia un entorno local, ya sea porque nuestras necesidades han cambiado y preferimos una solución on-premise o para pruebas. Sea cual sea el motivo lo cierto es que existen diferentes enfoques y herramientas disponibles y no todas las podremos usar en todos los casos. Vamos a verlo.

Análisis previo

Lo primero que tenemos que tener en cuenta es nuestra versión de SQL Server on-premise. Para esta tarea, un SQL Server 2022 actualizado con los últimos parches nos va a facilitar enormemente la tarea, no es un aspecto bloqueante pero sí que nos va a limitar las opciones que tenemos disponibles para el proceso.

Lo siguiente que debemos tener en cuenta es el tipo de solución en Azure de la que vamos a sacar los datos, como vamos a ver, las bases de datos sin servidor (Azure Database) nos van a limitar mucho las opciones. Si tenemos una Azure Managed Instance también tendremos que mirar qué configuración tenemos. Por defecto las managed instance tienen las bases de datos en modo de compatibilidad SQL Server 2022 pero esta configuración se puede cambiar por una configuración Always-up-to-date que, es una de las ventajas de la nube, pero que a la hora de pasar los datos a local también nos va a suponer una complicación.

Migrar con Archivos BACPAC

La exportación e importación de bases de datos a través de archivos BACPAC es uno de los métodos más utilizados para mover bases de datos entre Azure SQL Database, Azure Managed Instance y un servidor SQL local. Este archivo incluye tanto los esquemas como los datos de la base de datos, lo que permite una transferencia completa.

Para Azure SQL Database, esta opción es completamente compatible y el proceso es relativamente sencillo. En el caso de Azure Managed Instance, aunque también es posible, su uso es menos común ya que Managed Instance permite la creación de backups nativos (.bak), que son más rápidos y efectivos para bases de datos más grandes o complejas.

La configuración Always-up-to-date de Managed Instance no afecta al uso de BACPAC, ya que este formato es compatible con múltiples versiones de SQL Server. Sin embargo, si se importa un archivo BACPAC en un entorno SQL local con una versión más antigua de SQL Server, podría haber problemas de compatibilidad debido a nuevas características que no son soportadas en versiones anteriores.

Migrar con Archivos de Backup (.bak)

Uno de los métodos más directos para copiar bases de datos desde Azure Managed Instance a un servidor local es la restauración desde archivos de backup nativo (.bak). Esta opción no está disponible para Azure SQL Database, pero en Managed Instance es completamente compatible y el proceso es similar al que se realizaría con cualquier otra instancia de SQL Server.

No obstante, la configuración Always-up-to-date de Managed Instance puede afectar este método si el servidor local tiene una versión más antigua de SQL Server. Los archivos de backup generados en Managed Instance con la versión más reciente podrían incluir características o formatos de almacenamiento que no son compatibles con versiones antiguas.

Para usar este método de migración deberemos hacer una copia de seguridad de las bases de datos de Azure Managed Instance en un almacenamiento de Azure, descargaremos los archivos de copia y ya en local los podremos restaurar en nuestro SQL Server.

Generación de Scripts con Datos

La generación de scripts SQL es otra forma flexible de migrar bases de datos desde Azure SQL Database o Azure Managed Instance a un servidor local. Este método permite exportar tanto el esquema como los datos en un formato SQL ejecutable, que puede ser personalizado según las necesidades del entorno local.

Esta opción es completamente compatible tanto con Azure SQL Database como con Managed Instance, y no se ve afectada por la configuración Always-up-to-date ni por la versión de SQL Server. Sin embargo, si el script contiene características avanzadas introducidas en versiones más recientes de SQL Server, puede que no se ejecute correctamente en versiones más antiguas del servidor SQL local, lo que obligaría a realizar ajustes manuales en el script.

Para este tipo de migración, desde SSMS, seleccionamos la base de datos en Azure que queremos migrar. Utilizamos la opción «Generar scripts» desde el menú contextual (clic derecho sobre la base de datos). Se nos abrirá un asistente que nos permitirá elegir qué objetos queremos incluir en el script. Podemos optar por seleccionar todas las tablas, vistas, procedimientos almacenados y otros objetos de la base de datos, o solo algunos de ellos, según sea necesario. Para incluir los datos, debemos ir a las opciones avanzadas y seleccionar «Esquema y Datos» en la sección de scripts.
Esto generará un script que incluirá tanto las definiciones de las tablas como los comandos INSERT para poblarlas con los datos existentes. Una vez que el script está generado, podemos guardarlo en un archivo o abrirlo en una nueva pestaña de SSMS para ejecutarlo en el servidor de SQL Server local.
Este script creará la base de datos y restaurará tanto la estructura como los datos aunque es posible que debamos editar un poco las opciones de creación de la base de datos.

Migrar con el asistente de Importación/Exportación

El Asistente de Importación/Exportación de SQL Server, que utiliza paquetes SSIS, es una herramienta versátil para mover datos entre bases de datos en la nube y servidores SQL locales. Este método permite seleccionar qué tablas transferir, realizar transformaciones de datos durante el proceso y manejar grandes volúmenes de información.

Este método es compatible tanto con Azure SQL Database como con Azure Managed Instance, y no se ve afectado por la configuración Always-up-to-date. Sin embargo, la base de datos debe existir previamente en el entorno local. También os recomiendo usar el método anterior, aunque sin datos, previamente para crear los objetos ya que este asistente solo sirve para la copia de datos y si la tabla no existe la creará pero sin índices, restricciones, etc… El resto de objetos tampoco los va a crear este asistente.

Replicación de Datos con Azure SQL Data Sync

Azure SQL Data Sync es una herramienta diseñada específicamente para sincronizar datos entre bases de datos de Azure SQL Database y servidores locales de SQL Server. Esta opción es útil para entornos híbridos en los que se necesita mantener la sincronización de datos entre múltiples bases de datos.

Data Sync es compatible con Azure SQL Database, pero no puede utilizarse con Azure Managed Instance. Además, la configuración Always-up-to-date no influye en este método, ya que esta es una configuración exclusiva de Managed Instance. Sin embargo, la versión del servidor SQL local puede influir, especialmente si es necesario utilizar características de sincronización que no están disponibles en versiones más antiguas.

Migrar con Azure Managed Instance Link: Migraciones Online

Azure Managed Instance Link es una solución avanzada para realizar migraciones online entre Azure Managed Instance y servidores locales mediante Distributed Availability Groups que ha salido en GA el pasado octubre. Permite replicar datos en tiempo real, facilitando migraciones sin interrupciones significativas en el servicio.

Esta funcionalidad solo está disponible para Azure Managed Instance, por lo que no es compatible con Azure SQL Database. La configuración Always-up-to-date puede influir, ya que es necesario que la versión de SQL Server local sea compatible con las características de replicación de Managed Instance. La documentación dice que para que esta funcionalidad funcione correctamente, el servidor SQL local debe tener al menos SQL Server 2016 o una versión superior que soporte Distributed Availability Groups pero eso es para la replicación desde local a la nube, para una replicación bidireccional o de la nube a local vas a necesitar que el servidor local sea SQL Server 2022 CU 10 o superior y que la configuración Up-to-Date de Azure MI no esté activada.

Comparativa de opciones para migrar

Como lo que acabamos de ver tiene muchas variables y hay muchas opciones disponibles creo que la mejor manera de verlo todo claro es con esta tabla comparativa

Método	Compatibilidad con Azure SQL Database	Compatibilidad con Managed Instance	Impacto de la Configuración Always-up-to-date	Requisitos de Versión en SQL Server Local
BACPAC	Compatible	Compatible	No afecta	Puede fallar en versiones antiguas
Backup Nativo (.bak)	No compatible	Compatible	Puede afectar	Requiere misma versión o superior
Generación de Scripts	Compatible	Compatible	No afecta	Puede requerir ajustes en versiones antiguas
Asistente Import/Export	Compatible	Compatible	No afecta	No afecta
Azure SQL Data Sync	Compatible	No compatible	No afecta	Puede requerir versión reciente
Azure MI Link	No compatible	Compatible	No compatible	Requiere SQL Server 2022 CU 10 o superior

Conclusión

El proceso de copiar o migrar bases de datos desde Azure SQL a entornos locales de SQL Server varía en función del método elegido y de las características específicas del entorno en la nube y el servidor local. Las opciones como BACPAC y la generación de scripts son flexibles y ampliamente compatibles con ambas soluciones en la nube. Sin embargo, los backups nativos (.bak) y Azure Managed Instance Link son exclusivos de Azure Managed Instance, y su efectividad puede verse afectada por la configuración Always-up-to-date y la versión de SQL Server en el entorno local. Es fundamental tener en cuenta la compatibilidad de versiones y las características avanzadas en cada entorno antes de realizar una migración para asegurar un proceso fluido y sin interrupciones.

Nov

2024

Impacto en el rendimiento de Query Store

Cuando hablamos de Query Store en SQL Server, lo hacemos refiriéndonos a una de las herramientas más útiles para controlar y mejorar el rendimiento de nuestras consultas. No es ningún secreto que es una herramienta que personalmente me encanta y, no es para menos, nos permite capturar el historial de ejecución, los planes utilizados y, lo más importante, las métricas asociadas. Sin embargo, el otro día, un seguidor me trasladó una inquietud en un comentario de YouTube y no es otra que si la activación de Query Store puede tener un impacto negativo en el rendimiento. Ciertamente, Query Store conlleva una carga adicional que, en ciertos entornos, debemos saber gestionar con cuidado.

En este artículo, vamos a profundizar en el impacto real que tiene el Query Store en términos de CPU, memoria y disco, y cómo podemos configurarlo para obtener el máximo beneficio sin comprometer el rendimiento de nuestros sistemas.

¿Qué hace Query Store y por qué es tan útil?

En resumidas cuentas, Query Store se encarga de registrar el historial de todas las consultas que se ejecutan en nuestra base de datos, junto con los planes de ejecución y sus métricas de rendimiento. Es como tener un «registro médico» de nuestras consultas, donde podemos ver qué ha ido mal (o bien) y cuándo. Esto nos permite identificar rápidamente problemas de rendimiento y aplicar soluciones, como forzar el uso de un plan de ejecución específico. Es decir, cuando una consulta empieza a tardar más de lo habitual, Query Store nos permite ver qué ha cambiado, ya sea el plan de ejecución o las estadísticas.

Antes de seguir, si quieres saber más sobre el funcionamiento de Query Store, te recomiendo leer el artículo que le dedicamos.

¿Cuánto impacto tiene realmente Query Store en el rendimiento?

Aunque tener todo ese control suena genial, también hay que ser conscientes de que capturar tanta información tiene un coste. Y eso es justo lo que venimos a analizar hoy. Veamos cómo afecta a los distintos recursos del sistema.

Consumo de CPU y memoria

Lo primero que debemos tener claro es que Query Store no afecta a la ejecución directa de las consultas, ya que guarda la información de manera asíncrona. Pero eso no significa que no utilice recursos. El impacto más notable en CPU y memoria ocurre cuando se agregan los datos de las consultas para almacenarlos. Dependiendo de la cantidad de consultas y el tipo de carga (ad-hoc o batch, por ejemplo), este proceso puede requerir más recursos.

Por lo general, el impacto en CPU suele ser pequeño, pero no inexistente. El procesamiento de los datos para agregarlos y almacenarlos puede generar una pequeña sobrecarga, especialmente si el servidor ya está bajo presión por una alta carga de trabajo.

Hablando sobre la memoria RAM, Query Store usa su propia caché en memoria para almacenar temporalmente los datos antes de volcar (flush) al disco. En entornos con mucha actividad, puede necesitar más memoria de lo esperado si los intervalos de flush son largos o si el servidor está cerca de su límite de uso de memoria.

Espacio en disco

Aquí es donde más suele preocuparnos el impacto de Query Store. Todos los datos capturados tienen que almacenarse en disco, y si no tenemos cuidado, la cantidad de espacio utilizado puede crecer rápidamente. En Azure SQL Database, por ejemplo, el tamaño máximo que podemos asignar a Query Store es de 10 GB. En SQL Server on-premise, no hay un límite y, aunque el espacio propuesto por defecto es de 1 Gb podemos configurar manualmente el espacio que necesitemos y podamos asumir.

Si trabajamos en un entorno de producción con una base de datos que recibe muchas consultas por segundo, podríamos empezar a ver cómo el espacio en disco se reduce rápidamente si no gestionamos bien la configuración. En muchos casos, el crecimiento de los datos es gradual, pero en sistemas con grandes volúmenes de consultas, los datos pueden acumularse más rápido de lo esperado.

¿Cómo minimizar el impacto de Query Store?

Como hemos visto, es cierto que Query Store añade cierta carga al sistema, sin embargo, hay varias formas de mitigar su impacto y asegurarnos de que siga siendo beneficioso sin comprometer el rendimiento. Aquí os dejo algunas estrategias prácticas.

Ajustar el intervalo de flush

El flush es el proceso por el cual los datos que Query Store guarda en memoria en un primer momento se escriben en disco para persistirse. De manera predeterminada, este proceso ocurre cada 15 minutos, pero puedes ajustar este intervalo para reducir la carga en momentos críticos. Si trabajas con una base de datos muy activa, podrías reducir el intervalo para evitar que se acumule demasiada información en memoria y así dispersar la carga de escritura.

Una buena práctica es empezar con el valor por defecto y observar el comportamiento del servidor. Si notas que el servidor tiene picos de uso de disco en momentos específicos, reducir el intervalo de flush puede ayudar a que la escritura de datos sea más constante y menos impactante. Como ves, esta configuración afecta tanto a la cantidad de RAM que demanda Query Store como al consumo de CPU necesario para mover los datos de la memoria al disco.

Limitar el uso de espacio en disco

No todas las consultas tienen que ser almacenadas indefinidamente. SQL Server te permite configurar límites de espacio para Query Store y también establecer políticas de retención que eliminen los datos antiguos. Esto es especialmente útil para evitar que la información histórica crezca sin control.

Recomendación: Establece un límite de espacio en disco que sea acorde al tamaño y volumen de consultas de tu base de datos. Por ejemplo, para bases de datos medianas, un límite de 500 MB podría ser suficiente. En bases de datos más grandes, este valor puede aumentar, pero es esencial realizar una monitorización constante.

Configurar la retención de datos

Muy ligado al punto anterior. No tiene sentido almacenar datos de consultas por años si solo los vamos a analizar durante las últimas semanas. Configura un período de retención que se ajuste a tus necesidades de análisis. En la mayoría de los casos, mantener entre 30 y 60 días de historial es suficiente para identificar patrones y resolver problemas de rendimiento.

Usar el modo CUSTOM de captura

De forma predeterminada Query Store está configurado con un modo de captura automático que no captura todas las consultas sino solo aquellas que el motor de base de datos considera relevantes para el rendimiento. Esto, se puede cambiar para capturar todas las consultas lo que claramente incrementará el consumo de recursos.

Sin embargo, con SQL Server 2019, se introdujo un modo CUSTOM que nos permite capturar solo aquellas consultas que nos interesan, según criterios específicos que podemos definir. Esto es extremadamente útil en entornos donde se ejecutan miles de consultas ad-hoc o de bajo valor, que realmente no necesitamos monitorizar en detalle. Al usar este modo, reducimos el volumen de datos capturados, lo que disminuye la carga en disco y memoria.

Monitorizar el impacto de Query Store

Como siempre, es clave monitorizar cualquier herramienta que utilicemos en nuestros servidores. SQL Server Management Studio (SSMS) nos ofrece varias vistas que nos permiten ver el impacto que Query Store tiene en términos de uso de CPU, memoria y disco. Estas vistas nos ayudarán a realizar ajustes si detectamos que la carga es mayor de lo esperado. Otra opción sería usar el monitor de recursos de windows y comparar el consumo con la herramienta activada y sin ella

Conclusión

Habilitar Query Store puede ser un gran aliado para mejorar el rendimiento de nuestras bases de datos, pero requiere un enfoque cuidadoso para no generar sobrecarga en el servidor. Al ajustar el intervalo de flush, limitar el uso de espacio en disco, y capturar solo los datos necesarios, podemos beneficiarnos de su potencial sin afectar negativamente el rendimiento general.

La clave está en configurar y ajustar Query Store según las necesidades específicas de nuestro entorno. En la mayoría de los casos, unos pequeños ajustes pueden marcar una gran diferencia en términos de rendimiento y eficiencia. Como siempre, no olvides monitorizar y realizar pruebas periódicas para asegurarte de que todo funcione de manera óptima.

Nov

2024

Vuelve SQL (DATA) Saturday a Madrid

¡SQL Saturday Madrid está de vuelta, y lo hace con un nuevo nombre y una energía renovada! Después de la gran acogida de su edición anterior, y tras unos años de parón, SQL Saturday Madrid ahora se transforma en Data Saturday Madrid 2024, prometiendo ser el evento más destacado para todos los apasionados de los datos en España.

Este evento, que se celebrará el próximo 30 de noviembre de 2024 en la Universidad Politécnica de Madrid, Campus Sur, no solo retoma la esencia de las pasadas ediciones, sino que amplía su enfoque para cubrir las últimas tendencias y tecnologías del universo de los datos. Con el objetivo de reunir a profesionales y entusiastas del mundo de SQL, Big Data, la Inteligencia Artificial, la Ingeniería de Datos y todo lo relacionado con la plataforma de datos de Microsoft, Data Saturday Madrid viene cargado de novedades y sorpresas para todos los asistentes.

Un evento global para la comunidad de datos

Data Saturday Madrid 2024 es mucho más que un evento local; es parte de la iniciativa internacional Data Saturdays, que surge como una evolución del clásico SQL Saturday. Esta serie de eventos globales tiene como propósito reunir a la comunidad de profesionales de datos en distintos puntos del mundo, brindándoles la oportunidad de aprender, compartir y conectar en torno a las últimas tecnologías y tendencias en el mundo de la gestión de datos.

El evento de Madrid, al igual que otros Data Saturdays en ciudades de todo el mundo, se centra en temas como la ingeniería de datos, Big Data, inteligencia artificial y soluciones en la nube de Microsoft, como Azure y Power BI. Es un espacio que busca impulsar el crecimiento profesional de los asistentes a través de sesiones formativas de alto nivel y talleres prácticos que permiten una inmersión profunda en los conceptos más actuales

Un evento para todos los niveles y en dos idiomas

Una de las grandes fortalezas de Data Saturday Madrid 2024 es su compromiso con la accesibilidad y la diversidad. Las sesiones y talleres, que se impartirán inglés o en español, están diseñadas para todos los niveles de experiencia, desde aquellos que recién comienzan en el mundo de los datos hasta los expertos que buscan profundizar en temas avanzados. La agenda del evento incluye 33 sesiones en distintos tracks, permitiendo que cada participante personalice su experiencia según sus intereses y necesidades.

Innovación y conocimiento de la mano de expertos

La jornada del sábado promete ser intensa y emocionante, con ponencias de reconocidos MVPs, MCMs, mentores, ingenieros de Microsoft y especialistas técnicos de renombre. Entre los temas que se abordarán, destacan el ecosistema completo de Power BI, la Inteligencia Artificial Generativa (como Copilot y modelos de lenguaje), SQL Server, Azure SQL, Microsoft Fabric, y muchas más tecnologías que integran el ecosistema de datos de Microsoft, como Snowflake y Power Platform.

Pero eso no es todo. En los días previos, el 28 y 29 de noviembre, se realizarán talleres especializados de cuatro horas, diseñados para profundizar en temas específicos. Estas sesiones prácticas brindan una oportunidad única de aprender de la mano de expertos y explorar a fondo las herramientas y técnicas que están transformando la manera en que gestionamos y analizamos los datos.

Networking, premios y la tradición de #sqlbeers

Más allá del conocimiento técnico, Data Saturday Madrid 2024 también es un punto de encuentro para la comunidad. Después de una intensa jornada de charlas y aprendizaje, los asistentes podrán disfrutar de momentos de networking, incluyendo el clásico DataBeers, donde la comunidad se reúne para compartir experiencias de forma más relajada. Y, como en ediciones anteriores, no faltarán los sorteos de premios, entre los que destaca la codiciada Xbox Series.

Un evento de la comunidad para la comunidad

Este evento, organizado por y para la comunidad, es una oportunidad excepcional para conectar, aprender y compartir con otros profesionales del sector. La pasión y el entusiasmo de los organizadores se refleja en cada detalle, desde la selección de los ponentes hasta la planificación de las actividades paralelas. No importa si eres un veterano de SQL Saturday o si es tu primera vez asistiendo a un evento de este tipo, Data Saturday Madrid 2024 promete ser una experiencia inolvidable.

En resumen, si te apasiona el mundo de los datos y quieres estar al día con las últimas novedades y tendencias, no puedes perderte Data Saturday Madrid 2024. ¡Nos vemos el 30 de noviembre para celebrar el regreso de la comunidad de datos más grande de España, ahora con un nombre renovado, pero con el mismo espíritu de siempre!

PREGUNTAS FRECUENTES

¿Qué es el Data Saturday?

Es un evento para profesionales y futuros profesionales relacionados con Big Data, Business Intelligence y Artificial Intelligence.

¿Dónde y cuando?

El evento se celebrará los días 28, 29 y 30 de Noviembre en la Escuela Técnica Superior de Ingeniería de Sistemas Informáticos UPM ETSI de Madrid (Calla de Alan Turing s/n , 28031 Madrid).
Los días 28 y 29 están destinados a talleres prácticos con una duración de 4 horas y el sábado 30 a las 33 charlas.

¿Cuánto cuesta?

El evento es gratuito. A la hora de reservar la entrada se pedirá una donación mínima de 1€ que irá íntegramente destinada a una ONG de la zona.
Los workshop (talleres de 4 horas) tienen un coste de 49€.

¿De qué temas se hablarán?

Podremos encontrar sesiones relativas a :
– Power BI (todo el ecosistema, todos los niveles)
– Microsoft Fabric
– Generative AI (Copilot, LLM, RAG, OpenAI)
– Motor relacional (cloud, optimización, bloqueos, índices)
– Azure Data Platform
– Azure Databricks
– Integracion con Snowflake
– Integration Services, Analysis Services, Paginated Reports, Data Warehousing
– Big Data, Python, PySpark
– Artificial Intelligence
– Streaming de datos y arquitecturas Lambda
– Machine Learning
– IoT
– Datos en la nube
– Y muchos más!

¿Cómo puedo participar?

Si quieres es asistir y disfrutar aprendiendo, puedes adquirir tu entrada aquí:
https://www.eventbrite.com/e/registro-data-saturday-madrid-2024-sqlsaturdaymadrid-1037072881907

Oct

2024

¿Es recomendable usar caracteríticas en Public Preview?

El uso de características en Public Preview en productos de Microsoft genera un debate interesante dentro de la comunidad. Aunque no estamos acostumbrados a ver el uso de versiones Public Preview en producción en soluciones como SQL Server o la mayoría de servicios de Microsoft Fabric, en otros productos como Power BI sí que es más común que los usuarios adopten las nuevas funcionalidades de una manera más temprana. Lo mismo podríamos decir del SSMS, que muchos usuarios trabajan diariamente con versiones Beta.

Lo cierto es que existen ventajas y desventajas asociadas con el uso de estas funcionalidades antes de que lleguen a su fase de General Availability (GA). En este artículo vamos a ver si realmente es recomendable adoptar estas características en entornos productivos o si es preferible esperar a que se estabilicen con la liberación oficial.

Fases de Desarrollo: Hay más opciones que Public Preview o General Available

Antes de que una funcionalidad llegue a liberarse, existen varias etapas o fases en el ciclo de vida de desarrollo de un producto en las que los usuarios pueden participar. Estas fases permiten a las organizaciones y profesionales evaluar y probar características en distintos niveles de madurez.

Beta Interna

En esta fase, las funcionalidades son probadas internamente dentro de los equipos de Microsoft. Es una etapa completamente cerrada para el público externo y su principal objetivo es corregir los errores iniciales críticos.

Private Preview

Un grupo seleccionado de usuarios avanzados, generalmente MVPs, socios estratégicos o expertos en la materia, tienen acceso a esta etapa temprana del desarrollo. En esta fase el producto no está terminado aunque se presupone que ya tiene toda la funcionalidad necesaria (por eso la disponibilidad para probar) y, en ocasiones, podemos nosotros mismos solicitar el acceso. Durante esta etapa el feedback recibido por los usuarios es crucial para afinar la funcionalidad, pero se sabe que aún puede haber cambios significativos.

Public Preview

Esta fase abre la funcionalidad a un público más amplio y permite que cualquier usuario la pruebe bajo su propio riesgo. Las características aún pueden cambiar, pero es común que las funcionalidades ya sean bastante robustas. No obstante, Microsoft advierte explícitamente sobre posibles fallos y la falta de un Acuerdo de Nivel de Servicio (SLA) para esta etapa. Esta etapa tiene una doble función, por un lado, los usuarios prueban los productos y, en caso de detectar algún problema, pueden notificarlo a Microsoft. Por otro lado, esta prueba temprana puede ayudar a las empresas a asegurar la compatibilidad de sus soluciones nada más la versión definitiva sea liberada habiendo hecho previamente los cambios necesarios.

Release Candidate (RC)

Esta fase es el último paso antes del lanzamiento oficial. El producto está casi completamente terminado, y aunque puede haber pequeñas correcciones de errores, la funcionalidad ya está prácticamente estable. Es una fase clave para los usuarios avanzados que quieran probar en escenarios reales y asegurarse de que están preparados para la versión final.

General Availability (GA)

Por último tenemos la fase GA, esta es la fase en la que la característica se considera completamente lista para producción, respaldada por SLA y con soporte completo. A partir de aquí, la funcionalidad es considerada apta para cualquier entorno de trabajo, ya sea de misión crítica o no.

Estas fases permiten a los usuarios involucrarse en el desarrollo de las funcionalidades, influyendo en su evolución, pero también exigen un manejo cuidadoso del riesgo, especialmente en entornos productivos.

Ventajas de Usar Funcionalidades en Public Preview

Una de las principales razones por las que algunas organizaciones deciden implementar características en Public Preview es obtener una ventaja competitiva. La adopción temprana de nuevas capacidades en SQL Server, Power BI o Fabric puede permitir a las empresas explorar nuevas oportunidades o mejorar procesos antes que sus competidores.

Por ejemplo, cuando se lanzaron funcionalidades como Columnstore Index en SQL Server o avances en DirectQuery y Dataflows en Power BI, las organizaciones que adoptaron estas características en fases tempranas pudieron optimizar sus procesos de análisis y gestión de datos más rápidamente que aquellos que esperaron hasta la fase de GA.

Además, la fase de Public Preview ofrece a los usuarios la oportunidad de influir en el desarrollo del producto. Los comentarios proporcionados por los usuarios son fundamentales para corregir errores y ajustar las funcionalidades a los escenarios reales de uso.

Inconvenientes de Usar Funcionalidades en Public Preview

A pesar de las ventajas, las características en Public Preview también presentan inconvenientes. La principal preocupación es la estabilidad. Dado que las funcionalidades están en constante desarrollo, es posible que no sean completamente fiables o que presenten errores importantes, lo que puede tener un impacto negativo en entornos productivos.

Un ejemplo de este riesgo ocurrió con la implementación temprana de Columnstore Indexes en SQL Server. Aunque la funcionalidad prometía mejoras de rendimiento significativas, las primeras versiones presentaban limitaciones importantes que reducían su eficacia. Los usuarios que implementaron esta tecnología tuvieron que realizar modificaciones considerables en sus consultas para aprovecharla plenamente.

Además, las funcionalidades en Public Preview no suelen estar cubiertas por acuerdos de nivel de servicio (SLA), lo que significa que no hay garantía de resolución rápida de problemas. En entornos productivos , especialmente de misión crítica, este es un riesgo que muchas organizaciones no están dispuestas a asumir.

¿Cuándo actualizar?

Uno de los dilemas más comunes en la adopción de tecnología es decidir cuándo es el momento adecuado para actualizar a una nueva versión una vez que ha alcanzado la fase de General Availability (GA). Aunque las versiones GA son estables y están listas para producción, la decisión de actualizar inmediatamente puede variar según el entorno y las necesidades del negocio.

En entornos productivos críticos, como bases de datos o aplicaciones de análisis de datos, puede ser prudente esperar entre 3 y 6 meses tras el lanzamiento de GA antes de actualizar. Este margen de tiempo permite que se identifiquen y solucionen posibles problemas que no fueron detectados en las fases de prueba y permite beneficiarse de actualizaciones menores y parches que mejoran la estabilidad.

Sin embargo, en productos como Power BI, donde las actualizaciones suelen ser menos arriesgadas, algunas organizaciones optan por actualizar inmediatamente para aprovechar las nuevas funcionalidades y mejoras de rendimiento. Aunque no están libres de riesgo y en más de una ocasión he visto problemas graves. En resumen, la decisión debe basarse en el entorno específico y el nivel de riesgo que la organización esté dispuesta a asumir. Personalmente, para este producto con actualizaciones mensuales mi recomendación es tener los entornos productivos siempre una versión por debajo de la última, es decir, esperar un mes.

Para cerrar este apartado es importante destacar que no siempre es posible esperar para actualizar. En ocasiones, nos vemos obligados a actualizar nada más una versión es liberada para solucionar un incidente de la anterior. Por ejemplo la actualización acumulativa 15 de SQL Server 2022 soluciona una incidencia con CDC causada por la anterior actualización.

Estrategia de Pruebas con Public Preview

Si decidimos adoptar características en Public Preview o Release Candidate, es crucial tener un plan de pruebas bien estructurado. Implementar nuevas funcionalidades en entornos de pruebas antes de migrarlas a producción es una práctica esencial para mitigar riesgos.

Es imprescindible que las funcionalidades en Public Preview o RC se prueben en un entorno de desarrollo o pruebas separado de la producción. Esto evita que los problemas afecten al entorno productivo. Sin embargo, aunque separado, debería ser idéntico al entorno productivo. En este sentido, también es recomendable probar la funcionalidad bajo condiciones de carga similares a las de producción ayuda a identificar problemas de rendimiento que podrían no ser evidentes en pruebas ligeras.

Además deberemos implementar herramientas de monitorización y proporcionar retroalimentación a Microsoft sobre los problemas encontrados ya que esto permite un ajuste continuo de las funcionalidades y contribuye al desarrollo del producto.

Por último, siempre debemos tener un plan B, debe existir un plan para revertir los cambios si la nueva funcionalidad no funciona como se esperaba. Este es un paso crítico, especialmente en entornos de misión crítica.

Excepciones: SSMS Public Preview

Una excepción personal que sigo es con SQL Server Management Studio (SSMS). En este caso, Microsoft permite instalar las versiones en Public Preview junto con versiones estables anteriores sin desinstalar las mismas. Esto me permite probar nuevas características sin el riesgo de perder acceso a las herramientas que uso diariamente.

Mi estrategia es instalar SSMS en Public Preview en mi equipo de trabajo, pero no en los servidores de producción, obviamente. De esta forma, puedo probar las funcionalidades sin comprometer la estabilidad de los entornos críticos. Si las nuevas características funcionan correctamente, sigo usándolas; de lo contrario, siempre puedo volver a la versión estable. Además, reporto cualquier problema que detecte a Microsoft, lo que contribuye al desarrollo del producto.

Conclusión

La adopción de características en Public Preview o esperar a la fase de General Availability depende del nivel de riesgo que estemos dispuestos a asumir. Aquellos que buscan mantenerse a la vanguardia tecnológica y participar en el desarrollo del producto pueden beneficiarse de la adopción temprana, pero para entornos productivos críticos, es más seguro esperar hasta que la funcionalidad esté completamente probada y respaldada por un SLA. En algunos casos, como con SSMS, es posible adoptar un enfoque más flexible, probando las nuevas características sin comprometer la estabilidad operativa. Sin embargo, en general, la decisión de actualizar debe basarse en una evaluación cuidadosa del entorno, los riesgos y los beneficios esperados.

Y ahora os invito a debatir: ¿Cuál ha sido vuestra experiencia usando características en Public Preview? ¿Esperáis a la fase de GA para actualizar o adoptáis nuevas tecnologías en cuanto están disponibles? ¿Qué estrategias de pruebas habéis implementado para mitigar los riesgos?

Oct

2024

¿Es la nube una solución competitiva?

Para hacer una solución SaaS (Software as a Service) e IaaS (Infrastructure as a Service) basada en Azure SQL y SQL Server realmente competitiva a nivel empresarial, debemos ser críticos y realistas. Aunque la nube ha sido abrazada por la mayoría de las empresas, siguen existiendo debates sobre los costes, el rendimiento y si realmente es la mejor opción en todos los casos. La cuestión de si las soluciones en la nube son superiores a las on-premise sigue siendo un tema caliente, y en este artículo vamos a tratar de abordar esta comparativa con argumentos sólidos, analizando tanto las ventajas como las desventajas de cada enfoque.

¿Es la nube realmente más barata que on-premise?

Uno de los argumentos más comunes a favor de las soluciones en la nube, como Azure SQL Database y SQL Server en IaaS (Azure VM), es que son más baratas que las soluciones on-premise. Pero, ¿es esto siempre cierto? La respuesta corta es: depende. La realidad es que en muchos casos, las empresas descubren que los costes a largo plazo de la nube pueden exceder a los de las soluciones tradicionales on-premise, especialmente si no se gestionan adecuadamente. De hecho, he visto cómo algunas empresas han comenzado a reconsiderar su migración a la nube debido a las crecientes facturas de servicios como Azure.

Comparativa de costes: Nube vs. On-Premise

Azure ofrece una estructura de precios que parece atractiva a primera vista, con pagos por uso (pay-as-you-go) que prometen flexibilidad y ahorro. Sin embargo, en la práctica, la realidad de los costes en la nube es muy diferente. Cuando migras a la nube, hay varios factores que rápidamente pueden inflar la factura:

Costes ocultos

Aunque Azure permite escalar hacia arriba y hacia abajo según la demanda, las empresas a menudo subestiman las horas que sus máquinas virtuales (VMs) y bases de datos están en funcionamiento. Servicios como Azure SQL Database, Managed Instance y SQL Server en máquinas virtuales (IaaS) pueden escalar en función de la demanda, pero esto puede resultar en facturas inesperadas si no se implementan estrategias adecuadas de monitoreo y escalado automático. Además, para aprovechar estas ventajas, normalmente no basta con subir el código ya desarrollado (lift and shift) sino que hay que hacer adaptaciones para sacar partido a las ventajas de este nuevo paradigma.

Licenciamiento

Mientras que SQL Server on-premise requiere un pago inicial considerable por licencias, las soluciones en la nube suelen requerir un pago constante y por suscripción. Azure Hybrid Benefit promete ayudar a reducir estos costes reutilizando licencias de SQL Server existentes, pero la realidad es que muchas empresas no pueden aprovechar este beneficio de manera efectiva, o descubren que las economías de escala no son tan favorables como se prometía. Por otro lado, estamos asistiendo lentamente a la adopción del modelo de suscripción en SQL Server on-premise como el modelo de facturación Software Assurance que, a costa de un pago anual, nos proporciona características extra a nuestra licencia.

Costes de salida de datos

Un aspecto frecuentemente pasado por alto es el coste de descarga de datos desde la nube. En algunas plataformas en la nube, los costes de mover datos fuera de la nube, ya sea para hacer backups, migraciones o simplemente para integraciones con sistemas locales, pueden ser significativos. Este es un coste que las soluciones on-premise no tienen.

Rendimiento La batalla entre la nube y on-premise

Ahora bien, el tema del rendimiento es otro punto de fricción importante entre las soluciones en la nube y las soluciones tradicionales. Aquí, la historia no siempre favorece a la nube. Aunque Azure SQL Database y las soluciones SQL Server en IaaS prometen escalabilidad casi infinita, la realidad es que on-premise sigue ofreciendo mejor rendimiento en ciertas cargas de trabajo intensivas.

Escalabilidad y latencia

La capacidad de escalar automáticamente en Azure es una ventaja indiscutible cuando hablamos de escenarios variables, como el comercio electrónico o los servicios de streaming, donde las cargas fluctúan enormemente. Sin embargo, este beneficio tiene un precio en términos de latencia y rendimiento constante. En entornos on-premise, con infraestructura dedicada, la latencia y el rendimiento son más predecibles. Las aplicaciones que requieren baja latencia y un rendimiento constante, como las transacciones financieras o sistemas de bases de datos de alta concurrencia, pueden seguir funcionando mejor en infraestructura on-premise.

Por ejemplo, en una base de datos SQL Server alojada en Azure Virtual Machines, aunque puedas optar por discos premium y múltiples núcleos de CPU, la realidad es que la latencia de red entre las capas de aplicación y base de datos sigue siendo un factor limitante. Incluso con las opciones de red más optimizadas en Azure, una base de datos en un entorno on-premise configurada correctamente sigue siendo significativamente más rápida.

La trampa de la escalabilidad «ilimitada»

Uno de los mayores argumentos de venta de Azure es la escalabilidad ilimitada. Pero aquí es donde surge un gran problema: la escalabilidad tiene límites prácticos en cuanto a la optimización de la infraestructura y el coste que estás dispuesto a asumir. A medida que tu base de datos crece y requieres más recursos, los costes también se disparan, y en algunos casos, escalar en on-premise puede ser una mejor solución a largo plazo. Si tu carga de trabajo es predecible y estable, invertir en un sistema robusto on-premise puede ser significativamente más rentable que pagar por la escalabilidad en la nube de manera indefinida.

Además, muchos desconocen que algunas de las estrategias de escalado más avanzadas, como el uso de Elastic Pools en Azure SQL o la implementación de sharded databases, requieren una cantidad considerable de desarrollo adicional para optimizar. Esto significa que la promesa de una escalabilidad sencilla y sin fricciones en Azure no siempre se cumple sin costes adicionales de desarrollo y mantenimiento. Volvemos a lo que comentábamos antes, subir a la nube implica adaptaciones en el código y, muchas veces, solo nos será rentable para nuevos desarrollos.

Seguridad: ¿Es la nube realmente más segura?

Otro mito popular es que la nube es intrínsecamente más segura que las soluciones on-premise. Si bien Azure ofrece una gama de herramientas de seguridad impresionantes como Azure Security Center, en muchos casos, la seguridad en la nube depende de cómo la configures. Por ejemplo, la gestión de claves de cifrado, la configuración de firewalls y la implementación de políticas de acceso son tareas que, si no se configuran correctamente, pueden dejar a una empresa vulnerable a ataques o fugas de datos. Es tan compleja esta gestión que, en los últimos años, estamos viendo como crece la demanda de arquitectos cloud en las empresas.

Además, las empresas con grandes cantidades de datos sensibles o que operan en sectores altamente regulados, como el financiero o sanitario, a menudo prefieren seguir manteniendo sus datos on-premise por un mejor control sobre el acceso físico y la localización de los datos. De hecho, muchas empresas todavía desconfían de la nube para manejar datos confidenciales, y optan por mantener una infraestructura híbrida u on-premise para cumplir con las normativas locales de protección de datos.

Por último, a esto habría que añadir las limitaciones en cuanto a cumplimiento normativo. En determinados sectores regulados alojar datos fuera de la infraestructura de la empresa o no está permitido o requiere de una carga burocrática elevada. Y aún siendo posible, hay que extremar las precauciones y elegir bien las zonas geográficas donde se van a alojar los datos para no incurrir en problemas legales.

¿Hacia dónde vamos?

Para mi está claro, el futuro es híbrido. A pesar de las ventajas que ofrece la nube, está claro que no es la panacea para todas las situaciones. Es aquí donde el modelo híbrido se convierte en una solución inteligente para muchas empresas. El uso de bases de datos SQL Server en Azure, combinado con una infraestructura on-premise bien gestionada, permite aprovechar lo mejor de ambos mundos. Puedes tener la flexibilidad de la nube para cargas de trabajo variables, al mismo tiempo que mantienes un rendimiento consistente y control total sobre los datos más sensibles en entornos locales.

El debate no se trata de «nube vs. on-premise», sino de cuándo y cómo aprovechar cada tecnología de manera efectiva. Por ejemplo, Azure Arc permite extender las capacidades de administración de Azure a entornos on-premise y otros entornos en la nube, facilitando una verdadera experiencia híbrida. Esto permite a las empresas beneficiarse de las herramientas de administración avanzada de Azure, mientras siguen utilizando su infraestructura local para cargas críticas.

Conclusión

La nube tiene ventajas indiscutibles en términos de flexibilidad, facilidad de escalado y disponibilidad global, pero eso no significa que sea la mejor opción para todas las empresas o todas las cargas de trabajo. Los costes y el rendimiento de las soluciones en la nube no siempre superan a las soluciones on-premise, especialmente cuando hablamos de cargas de trabajo predecibles o sensibles a la latencia. Como profesionales de bases de datos, debemos ser críticos y cuidadosos al considerar qué opción es la mejor para nuestros clientes o nuestras empresas.

La clave está en evaluar las necesidades específicas y no dejarse llevar por el bombo publicitario de la nube ni por la comodidad que nos dan años de experiencia on-premise. La mejor solución sigue siendo aquella que esté alineada con los objetivos de negocio, y esto podría implicar el uso de la nube, de soluciones on-premise, o de un enfoque híbrido.

Infra

¿Es recomendable usar caracteríticas en Public Preview?

Fases de Desarrollo: Hay más opciones que Public Preview o General Available

Beta Interna

Private Preview

Public Preview

Release Candidate (RC)

General Availability (GA)

Ventajas de Usar Funcionalidades en Public Preview

Inconvenientes de Usar Funcionalidades en Public Preview

¿Cuándo actualizar?

Estrategia de Pruebas con Public Preview

Excepciones: SSMS Public Preview

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes