En marzo pasado, Microsoft introdujo SQL Server 2014, un lanzamiento importante con dos temas principales: la nube y la velocidad -o, para ser específicos, integraciones Azure y OLTP en memoria (procesamiento de transacciones en línea).
Para todos los usuarios de SQL Server, no creo que hayamos visto un lanzamiento de esta importancia desde SQL Server 2008 RTM. Mirando hacia atrás, es posible que recuerde que SQL Server 2008 trajo Change Data Capture, compresión de datos y, lo más importante, PowerShell. Luego, SQL Server 2008 R2 trajo los plug-ins de PowerPivot para autoservicio de BI, junto con StreamInsight y Master Data Services. SQL Server 2012 trajo grupos de disponibilidad, índices de almacén de columnas, y varias mejoras de T-SQL. Es posible clasificar a SQL Server 2008 como un lanzamiento de almacenamiento de datos, SQL Server 2008 R2 como un lanzamiento de BI y SQL Server 2012 como un lanzamiento de HA.
SQL Server 2014 ofrece mejoras en varias de estas áreas, incluyendo los grupos de disponibilidad y los índices de almacén de columnas, y otras tales como la seguridad (copias de seguridad cifradas). La mayor parte de esta revisión se centrará en las características de nube y en el rendimiento.
Su base de datos en Azure
SQL Server 2014 tiene dos formas de trabajar con el almacenamiento Azure. En primer lugar, puede hacer copias de seguridad de una base de datos para almacenarla en Azure. Si bien esta característica (llamada oficialmente copia de seguridad de SQL Server para URL) fue introducida en el año 2012, recibe un impulso en SQL Server 2014 con SQL Server Managed Backup para Windows Azure -o simplemente Managed Backup, ya que solo funciona con Azure en este punto. Managed Backup es un nombre adecuado porque administra las copias de seguridad por usted, literalmente. SQL Server se fija en su periodo de retención y la carga de trabajo de transacciones, se da cuenta de cuándo es el mejor momento para hacer las copias de seguridad, y se encarga de hacerlo por usted. Usted puede configurarlo a nivel de instancia o el nivel de base de datos, por lo que obtiene un control decente sobre qué bases de datos quiere que sea copiada a la nube.
En segundo lugar, necesita mantener la vista en su uso. Si las bases de datos son demasiado grandes o si alguien deja caer una gran base de datos en el servidor y se copia en la nube, podría destruir su contrato de servicio y terminaría pagando mucho más de lo previsto por el almacenamiento. Dicho esto, para bases de datos más pequeñas, el Managed Backup es un hermoso reemplazo para el envío de las cintas fuera del sitio.
Las copias de seguridad no son la única función de Azure en SQL Server. También puede definir una máquina virtual de Windows Azure como una réplica secundaria a un grupo de disponibilidad. Esto puede ser una gran opción para los departamentos de TI que necesitan una solución de HA confiable, pero que no tienen un segundo centro de datos al cual recurrir. SQL Server incluso le proporciona un asistente para ayudar en la instalación. Esta característica viene con algunos pre requisitos fijos, como una VPN de sitio a sitio entre la subred en las instalaciones y Azure, así que asegúrese de que su equipo de infraestructura puede hacer que esto suceda antes de apostar por ello.
Otra característica de Azure que vale la pena conocer son los archivos de datos de SQL Server en Windows Azure. Los nombres se alargan, ¿no es así? Estoy mucho menos entusiasmado con esta característica, que le permite crear una base de datos ‘on-premise‘ y almacenar sus archivos en el almacenamiento blob Azure, porque es muy abierta a los abusos (por departamentos de TI que serán tentados a correr enormes bases de datos con pesadas cargas de trabajo de la nube), pero puedo ver algunos beneficios en ciertas situaciones.
Por ejemplo, cuando se crea una base de datos en un servidor local, normalmente se guardan los archivos de base de datos en su almacenamiento local o en una red SAN. Los archivos de datos en Windows Azure le permiten poner los archivos en una ubicación accesible URL en el almacenamiento Azure. Esto podría ser beneficioso si termina haciendo una migración de un servidor a otro, ya que simplemente tiene que adjuntar los archivos de base de datos al nuevo servidor -no hay movimiento de datos en cuestión. Eso significa que no tiene que preocuparse acerca de la restauración de una base de datos después de una falla, o copiar archivos en la red, o esperar durante cuatro horas para que le devuelvan sus cintas. El almacenamiento blob siempre está ahí.
Para algunos departamentos de TI, los archivos de datos en Windows Azure podrían ser una pieza fundamental en su estrategia de recuperación ante desastres. Es un escenario híbrido verdadero cuando gestiona cada aspecto de su SQL Server local, pero los datos reales residen en la nube. También le proporciona una alta disponibilidad que no tiene que manejar. Por desgracia, también pone a su base de datos a la merced de los flujos y reflujos de la Internet. La solución de problemas de rendimiento de base de datos es más complicada porque no se sabe si hay un problema con el servidor local, los índices, las consultas, o en Internet. Hemos tenido la posibilidad de adjuntar archivos de base de datos a través de redes locales desde hace años, y ha sido desalentador por razones de rendimiento. Creo que la adición de la Internet abierta a la ecuación es quizá una buena idea.
Alimenta la necesidad de velocidad
En estos días, incluso la más pequeña de las nuevas empresas en línea se lanza instantáneamente a un mercado global y podría verse inundada de peticiones al servidor. Cuando se trata de rendimiento, Microsoft ha aceptado el reto con algunas características agradables para esta versión.
Vamos a empezar con lo que considero que es la característica insignia de SQL Server 2014, Hekaton. Es lo que para Microsoft son las tablas de memoria optimizada: Todo lo que tiene que hacer es definir una tabla como memoria optimizada, y el motor se hará cargo del resto. Y a diferencia de otras soluciones de bases de datos en memoria, Hekaton le permite llevar las tablas individuales en la memoria, en lugar de toda la base de datos. Esto va de la mano con un escenario de negocios más realista, porque normalmente tiene solo un puñado de mesas que necesitan este tipo de impulso, y obligar a que toda la base de datos entre en la memoria por el bien de algunas tablas no es un buen uso de los recursos.
Hekaton logra su impulso gracias a una combinación de algoritmos optimizados, simultaneidad optimista, eliminación de bloqueos físicos y cerrojos, y oh sí, el almacenamiento de la tabla en la memoria. Si ha almacenado procedimientos que afectaron solo la tabla de memoria optimizada, puede convertirlos en procedimientos Hekaton para obtener aún más velocidad. Esto los compila en código nativo C, lo que optimiza su eficiencia.
Existen limitaciones en los tipos de objetos que se pueden convertir, por lo que debe leer y probar su código antes de adoptar esta solución. Como un ejemplo rápido, los procedimientos optimizados de almacenamiento no pueden contener cursores, subconsultas, o incluso las CTE (expresiones comunes de tabla). Esos son algunos ejemplos de una larga lista, por lo que necesita hacer su tarea; espere a que los requisitos de datos y tablas también lo hagan. Teniendo en cuenta que esta es una característica nueva, yo esperaría que estas restricciones disminuyan con el tiempo.
¿De qué tipo de velocidades estamos hablando aquí? ¿Será suficiente para hacer una conversión que valga la pena? He visto algunos demos bastante impresionantes, y el sitio de Microsoft cuenta con un aumento de rendimiento de 10 a 30 veces. Las velocidades exactas dependen de muchos factores, por supuesto, pero por lo que he visto en las demostraciones y en mi propia prueba, estos son números reales. La verdad sobre el terreno es que si tiene un escenario OLTP altamente transaccional y que cuente con los requisitos Hekaton, se va a enamorar.
SQL Server 2012 introduce los índices de almacén de columnas para que tengan un rendimiento espectacular. He visto personalmente las consultas que tomaron varios minutos con un índice tradicional reducido a veces por debajo del segundo, con la adición de un índice de almacén de columnas. El problema estuvo en que los índices de almacén de columnas no eran actualizables. Para cargar datos en la tabla, había que eliminar los índices primero y volver a crearlos después. SQL Server 2014 ha resuelto ese problema haciendo que los índices de almacén de columnas sean actualizables -buen trabajo, Microsoft.
Siempre les digo a mis DBA subalternos que solo hay dos formas de resolver un cuello de botella: Reducir la carga de trabajo o aumentar el rendimiento. Si bien las características anteriores abordan el rendimiento, estas próximas dos características se refieren a la carga de trabajo.
El regulador de recursos finalmente ha ganado el control físico de I/O. El disco a menudo es el cuello de botella en un sistema dado, porque es el único componente con partes mecánicas en movimiento. Muy a menudo, los discos reciben exceso de trabajo debido a alguna consulta maliciosas que absorben toneladas de capacidad de I/O de los discos. De hecho, he visto almacenes derribados por las consultas que tiran miles de millones de IOPS. Ahora puede finalmente poner las preguntas en su propio fondo de recursos y limitar la cantidad de I/O por el volumen que se les permita. Esto significa que no habrá más consultas ridículas que se lleven todos los preciosos recursos de disco. Reducir la cantidad de I/O en un sistema de disco puede tener un tremendo impacto en el rendimiento general.
Tome un atajo
La siguiente función, denominada Delayed Durability, en realidad no acelera la base de datos, pero hace que parezca más rápida desde el punto de vista del usuario final. Vamos a caminar a través de una transacción típica (simplificada) para ilustrar esto.
Digamos que el usuario final actualiza un registro. La primera actualización se escribe en la memoria del registro, y la entrada del registro se escribe en el disco. Después de que la entrada del registro se escribe en el disco, la aplicación informa que la transacción se ha completado y el usuario puede seguir trabajando. La actualización real a la base de datos sucede detrás de las escenas en un momento posterior. Ahora, con el retraso en la durabilidad, se le informa a la aplicación que la transacción se completa antes de que el registro se escriba en el disco. Esto significa que el usuario final no tiene que esperar a que la transacción sea reforzada en el disco más lento antes de que pueda continuar trabajando. He visto muchos sistemas en los que el registro era el cuello de botella, y Delay Durability sin duda puede ayudar a resolver eso.
Pero como he dicho, Durability no reduce la carga de trabajo en absoluto. Todo lo que se hacía aún se sigue haciendo. El motor de base de datos solo libera el control de vuelta al cliente tiempo antes de lo que solía hacer, por lo que el usuario final pueda volver a trabajar más rápido. Esta característica es configurable -se puede controlar en el nivel de base de datos, el nivel de transacción, o incluso a nivel de bloque atómico (para un procedimiento almacenado entero). Sin embargo, tenga cuidado al considerar esta característica. Si el sistema falla antes de que estas transacciones queden grabadas en el disco, las perderá. Esto es lo que significa durabilidad: La transacción es recuperable. Si demora la durabilidad de sus transacciones para obtener mejores tiempos de respuesta del cliente, tenga en cuenta que es posible que se pierdan algunos datos.
Y, por último, SQL Server 2014 trae un par de mejoras de seguridad. Por supuesto, ahora tenemos el cifrado de copia de seguridad, que es un clavo más en el ataúd de los productos de copia de seguridad de terceros. El clavo final será la recuperación a nivel de objeto. También hay un par de nuevos permisos de nivel de servidor –Conectar cualquier base de datos de usuario y Seleccionar todos los elementos a proteger del usuario– que le permiten gestionar la seguridad con más facilidad que nunca. La razón es que se puede asignar estos permisos una vez para todas las bases de datos actuales y futuras. Ya no tiene que mantener la asignación de estos permisos a medida que las bases de daros van y vienen.
SQL Server 2014 es una versión sólida con una buena mezcla de nuevas características y mejoras a las ya existentes. Aunque yo personalmente no me siento atraído por las funciones de nube, estoy absolutamente encantado con el trabajo que ha hecho Microsoft en OLTP, y esta historia es seguro que mejorará. Hekaton es nuevo en esta versión, por lo que se puede esperar que algunas de las restricciones comenzarán a desaparecer en las versiones posteriores.
Ni siquiera me he acercado a mencionar todas las nuevas características. Para una buena lectura práctica, le sugiero buscar la extensión buffer pool, estadísticas incrementales, y la gestión de prioridad de bloqueo de las operaciones en línea. Todo esto puede tener un impacto significativo en el rendimiento del sistema. Sin embargo, es también digno de mencionar que Integration Services, Reporting Services y la replicación no recibieron mejoras en esta versión en absoluto, y si bien hay algunas mejoras menores de T-SQL, nada va a cambiar la forma en que los administradores de bases o los desarrolladores hacen su trabajo.
Sin embargo, SQL Server 2014 le ofrece muchas maneras de mejorar el rendimiento, y algunas formas de aprovechar la nube Azure para copias de seguridad y alta disponibilidad. Los departamentos de TI de SQL Server que luchan con estas cuestiones deberían darle una mirada más cercana a esta versión.
-Sean McCown, InfoWorld (EE.UU.)
