Desde el pasado 1 de junio tenemos disponible la RTM de SQL Server 2016, la nueva versión de esta suite. Y la pregunta obligatoria en estos casos es ¿realmente merece la pena? ¿mi negocio se va a ver beneficiado si migro mi plataforma de datos? Desde nuestro punto de vista, la respuesta es un rotundo SÍ, y a lo largo de este artículo vamos a tratar de justificarlo.
Figura 1. Historia reciente de SQL Server
El gráfico anterior muestra las fechas de salida de las últimas versiones de SQL Server, así como alguna de las principales novedades que introdujeron cada una de ellas. El espacio ocupado es directamente proporcional al tiempo que tardó en salir respecto a la anterior release, de modo que es fácil observar que la versión 2005 fue la que más se demoró (casi 5 años). En este caso esa demora estuvo más que justificada porque el número de las funcionalidades introducidas fueron tantas y de tal envergadura que podemos decir que fue una revolución para esa época. En la actualidad también estamos viviendo una revolución, la relacionada con el brutal incremento del volumen de datos y los análisis que se han empezado a aplicar sobre ellos, que nos están permitiendo encontrar no sólo nuevas respuestas sino también descubrir nuevas preguntas… que volvemos a hacerles a los datos.
En un escenario como el descrito, ¿está SQL Server 2016 preparado para ser la herramienta que necesitamos? Comencemos a descubrirlo…
Cuando se habla de cómo trabajar con esta gran cantidad de datos, lo primero en lo que se piensa es en Hadoop: datos no estructurados o semiestructurados, schema on-read, sistemas distribuidos… no es precisamente lo que mejor define a SQL Server. Sin embargo ahora podemos empezar a usar Polybase, una funcionalidad que permite trabajar con un clúster de Hadoop (tanto con la implementación de Cloudera como con la de Hortonworks) directamente con T-SQL en SSMS, sin necesidad de aprender Java o procesos MapReduce. El componente decidirá cuándo ejecutar la instrucción en Hadoop y cuándo directamente en SQL Server, pero también podemos forzar un comportamiento u otro incluso a nivel de instrucción mediante un HINT. Al final, lo que nos permite este componente es hacer JOIN de tablas locales y externas o importar/exportar datos desde/hacia Hadoop para aplicarlo en escenarios como limpieza de datos (proceso costoso sobre grandes cantidades de datos, perfecto para ser ejecutado en paralelo) o consultas sobre cold-data (datos históricos que son consultados en muy pocas ocasiones y que pueden residir en HDFS sin necesidad de ocupar espacio en mi base de datos).
Figura 2. Polybase guide (msdn.com)
Aunque para mantener históricos sin que eso nos suponga invertir en costoso almacenamiento local, también tenemos a nuestra disposición Stretch Database. Esta funcionalidad nos permite usar una base de datos de Azure SQL Database como repositorio de aquellos datos que hacen que nuestra tabla tenga un tamaño bastante considerable, pero que sabemos se consultan en contadas ocasiones. Hasta ahora, para solucionar este escenario teníamos que hacer tareas que implicaban bastante trabajo (ETL) y/o tenían impacto en la tabla afectada (particionamiento); ahora es cuestión de unos pocos clics para reducir carga sobre nuestra instancia y traspasársela a un recurso externo como es Azure (recurso que, recordemos, podemos escalar fácilmente para adaptarlo a nuestras necesidades), pudiendo seleccionar toda la tabla o sólo los registros que cumplan una condición. Y aunque tenemos ciertas limitaciones, nada nos impide deshacer la operación para volver a tener todos nuestros datos en on-premise con la misma sencillez con la que anteriormente los habíamos subido.
Otra opción que integra mundos diferentes dentro de SQL Server es R Services, ya que incluye el motor optimizado de R desarrollado por Revolution Analytics (empresa que fue comprada por Microsoft recientemente) dentro de la propia base de datos. ¿Y qué conseguimos con esto? Pues que algoritmos de Machine Learning que nuestros científicos de datos tienen implementados en scripts en RStudio (o en R Tools for Visual Studio) pueden ser tratados en nuestra aplicación como una llamada más a un procedimiento almacenado, con la (gran) ventaja adicional de que los datos no tienen que viajar por la red ya que todo se ejecuta dentro del contexto de nuestro SQL Server. Pero no sólo datos, también es posible que esos procedimientos almacenados devuelvan informes generados por esos paquetes tan potentes como ggplot2 o lattice.
Puede ser sin embargo que ninguna de estas tres funcionalidades tenga una aplicación práctica en nuestro entorno, que nos queden aún muy lejos. En escenarios más típicos donde tenemos un rol más tradicional de DBA, sólo por el hecho de disponer de Query Store ya merece la pena el esfuerzo de migrar a SQL Server 2016. Al habilitar esta funcionalidad a nivel de base de datos, el sistema captura el plan y los valores de ejecución de las instrucciones, persistiéndolos a intervalos regulares (que se pueden configurar) en un almacenamiento propio de dicha base de datos. A partir de esta información es posible conocer cosas como el número de ejecuciones de una consulta o su tiempo medio de duración en el intervalo temporal que definamos, identificando aquellas cuyo rendimiento ha empeorado y forzando a que usen un plan de ejecución concreto si vemos que esa es la solución que debemos aplicar, todo ello desde el interfaz gráfico de SQL Server Management Studio. Los gráficos predefinidos construidos sobre el conjunto de DMV que ofrece la funcionalidad nos permiten análisis muy detallados de qué consultas son las que suponen la mayor carga (uso de CPU, duración, IO y memoria) de nuestro sistema, qué planes de ejecución están usando, cuál ha sido su evolución (si han empeorado o mejorado) a lo largo del tiempo o centrarnos en el detalle de una consulta en concreto porque sabemos que es crítica aunque su rendimiento sea aceptable. Y la mejor noticia no es sólo las grandes posibilidades que nos ofrece la funcionalidad para optimizar nuestra instancia con muy poco trabajo de monitorización por nuestra parte, es que además está disponible en todas las ediciones de SQL Server, incluida la Express.
Figura 3. Query database – Top resources report (azure.com)
Desde el punto de vista de seguridad, hay dos funcionalidades que nos van a permitir solucionar escenarios muy comunes pero que hasta ahora requerían bastante trabajo extra por nuestra parte para solucionarlos. Por una parte, Always Encripted nos ofrece la opción de cifrar columnas con contenido sensible (número de la seguridad social, de cuentas corrientes o de tarjetas, etc.), quedando no sólo almacenadas en ese estado, sino que también viajan cifradas por la red. El trabajo de cifrado/descifrado corre por parte de la aplicación cliente a nivel del driver de ADO.NET activando la propiedad Column Encription Setting en la cadena de conexión. Es decir, estamos consiguiendo diferenciar entre el rol del propietario de los datos (aquellos que pueden verlos) y el rol de administrador de los datos (aquellos que no pueden verlos), un detalle muy importante que hasta ahora no era posible conseguirlo directamente. Por cierto, esta funcionalidad también está disponible en Azure SQL Database, de modo que si una de las preocupaciones de nuestra empresa es el recelo a almacenar datos sensibles fuera de sus CPD, tal vez esta opción permita abrir el uso de PaaS para nuestros repositorios de datos.
El otro escenario a nivel de seguridad que suele ser muy común en todas las organizaciones es la de filtrar los datos a nivel de registro. Esta necesidad, cubierta desde hace tiempo en productos como SQL Server Analysis Services, no la teníamos disponible de forma nativa en el motor de base de datos relacional, de forma que su implementación suponía mucho trabajo tanto de desarrollo como de administración (normalmente la creación de múltiples vistas era la solución que se ofrecía). Sin embargo, gracias a Row Level Security es posible asegurarnos que los registros que maneja un usuario concreto son con los que realmente puede trabajar. Y, muy importante, todo ello de forma transparente para la aplicación cliente, sin necesidad de tocar una línea de código.
Figura 4. Row Level Security sample (blogs.microsoft.com)
Seguramente también resulte familiar la necesidad de almacenar un histórico de los cambios en una tabla concreta, donde el problema no es tanto implementarlo sino el coste y el impacto que tiene hacerlo. En este caso, SQL Server 2016 nos ofrece Temporal Tables, de forma que simplemente indicándolo a nivel de diseño de la tabla, podemos conseguir que el sistema se encargue de auditar y almacenar cada uno de los cambios por los que han pasado los registros de dicha tabla, para luego poderlos consultar mediante instrucciones específicas TSQL. Todo, de nuevo, sin necesidad de costosos desarrollos hechos a medida.
Siete son las funcionalidades que se han comentado hasta ahora, algunas de ellas revolucionarias en su concepto, otras que resuelven sin prácticamente impacto en nuestros sistemas escenarios que seguramente nos resulten muy familiares. Cualquiera de ellas bien podría justificar una migración a SQL Server 2016, pero lo que es más sorprendente es el hecho de que apenas se ha comentado un pequeño porcentaje de todo lo que tenemos a nuestra disposición: mejoras de rendimiento de hasta un 25% con la nueva versión en el mismo hardware sin tocar ningún parámetro (anunciadas por el equipo del producto, algo que no había sucedido hasta ahora), mejoras tanto en el rendimiento como en funcionalidades de componentes tan prometedores como InMemory OLTP o los índices columnares, soporte para JSON y UTF-8, mejoras para mejorar el rendimiento en partes tan críticas como tempdb, o Availability Groups para la edición Standard y soporte para DTC, nuevas instrucciones TSQL (DROP IF… sin duda va a ser una de las favoritas), etc., etc., etc.
Y no, no es que el resto de los productos de la suite no hayan cambiado, es que en algún momento hay que empezar a finalizar el artículo. Pero sí, también tienen mejoras significativas: tanto Integration Services como Analysis Services en su modalidad multidimensional como tabular, Master Data Services… y por supuesto no es posible dejar de mencionar el completo rediseño que tenemos en Reporting Services.
No quisiera acabar sin comentar otro aspecto que me parece tanto o más importante que lo tratado hasta ahora, algo que tiene que ver con cómo se ha gestionado esta nueva versión internamente en Microsoft. Estoy hablando de que SQL Server 2016 es la primera release “cloud first”, un concepto que no es un mero juego de palabras publicitario. Es un cambio en la forma en la que se desarrolla el producto, en cómo se incorporan los cambios y en quién es el responsable de corregirlos en caso de que surja algún problema. Es algo que estamos pudiendo ver en Azure SQL Database, donde primero se despliegan los cambios que van a ir después en la versión on-premise, un entorno que se compone de… ¿cuántas bases de datos en total? ¿cuántos usuarios concurrentes? ¿cuántos escenarios diferentes que pueden sacar a la luz algún bug en el código?. Y en una situación como esa, no vale la respuesta de “vamos a mirarlo y ya te mandamos un hotfix”. No, ahí es necesario corregirlo inmediatamente porque no sólo afecta a un cliente más o menos importante, es algo que repercute de forma directa a las arcas de Microsoft, y con eso no se juega. Sin embargo, lo que esto implica es que lo que a nosotros nos llega es un producto final muy depurado, muy seguro (no infalible, obviamente) y de muy alta calidad.
¿No son razones suficientes para, al menos, plantearse muy seriamente la migración a SQL Server 2016 en el corto plazo?
Si quereis comentarnos lo que sea podeis hacerlo en info@kabel.es
