La digitalización está generando un volumen de datos sin precedentes en las empresas. Muchos ven la ejecución de bases de datos de SQL Server desde Microsoft Azure o Amazon Web Services (AWS) como la mejor manera de garantizar el rendimiento de TI frente a los crecientes volúmenes de datos y los requisitos de análisis más complejos. Sin embargo, la esperanza inicial de poder trabajar de manera más rentable al cambiar a la nube no se está cumpliendo para algunos. Una razón importante para esto podría ser que los activos de datos no se han optimizado de antemano para el nuevo entorno de la nube. Por lo tanto, la migración solo debe completarse después de una preparación exhaustiva.

Migrar a la nube es similar a mudarse a un nuevo hogar: mientras limpia los estantes y mira sus pertenencias, aparecen objetos que ni siquiera sabía que tenía. La pregunta que inevitablemente surge es: ¿todos los artículos de toda la casa siguen siendo relevantes para la nueva casa? ¿O ha llegado el momento de limpiar y eliminar el desorden?

Esta realización también se puede aplicar a la migración de bases de datos de SQL Server a la nube. Dado que el nuevo entorno tiene reglas diferentes que las locales, un movimiento suave debe ir precedido de un trabajo de limpieza adecuado en la base de datos. Para hacer esto, los administradores de bases de datos (DBA) deben primero obtener una visión general de cómo interactúan todas las bases de datos con las aplicaciones conectadas. Esto les permite limpiar el desorden innecesario en sus conjuntos de datos y revisar los códigos si es necesario. Por lo tanto, la migración debe ir precedida de un proceso de dos pasos que consta de fases de evaluación y examen.

Fase de evaluación: selección de datos para la migración

Una de las razones más comunes para el fracaso de las migraciones en la nube es el costo excesivo. En muchos casos, esto puede atribuirse al hecho de que el nuevo modelo de tarifa en la nube no se ha tenido suficientemente en cuenta. Los datos no utilizados, cuya cantidad es en gran medida insignificante en la operación local, pueden ejercer una presión significativa sobre el presupuesto en la nube, donde la tarifa está determinada por la CPU, el almacenamiento y los IOP. Por el contrario, completar una evaluación exhaustiva por adelantado ayuda a garantizar que el nuevo entorno se utilice de la manera más eficiente posible. Para hacer esto, determine todos los registros de datos de inventario y asígnelos a tres categorías: limpieza, archivo, migración, uno tras otro.

Limpieza

Grandes cantidades de datos basura o conjuntos de datos que simplemente ya no son útiles son adecuados para la limpieza antes de la migración a la nube. Esta categoría incluye datos que se crearon en el pasado pero que pueden ser de baja calidad y solo necesitan ser almacenados por razones legales. Si ha transcurrido el período de tiempo legalmente requerido, ahora se pueden eliminar. Si se trata de datos personales, el stock de datos también debe considerarse a la luz de GDPR y cualquier otra normativa de protección de datos.

Archivado

Durante sus investigaciones, los DBA también pueden encontrar el caso opuesto: algunos conjuntos de datos que, aunque obsoletos, son de calidad adecuada para los análisis de tendencias actuales y futuros. Aquí es aconsejable continuar utilizando los datos en modo de solo lectura. Por ejemplo, si se planea la migración a Microsoft Azure, los datos simplemente se pueden mover a un nivel de almacenamiento comparativamente menos costoso utilizando una base de datos SQL Stretch. Allí, los datos todavía están disponibles en modo de solo lectura y se pueden recuperar según sea necesario para las operaciones de inteligencia empresarial, para la aplicación de funciones de inteligencia artificial o aprendizaje automático y para la creación de análisis predictivos.

Migración

Una vez identificados los datos que deben limpiarse y archivarse, se forma automáticamente la cantidad de datos adecuados para la migración. Aunque estos datos provienen de sistemas de producción locales, esto no significa que puedan transferirse directamente a un sistema de producción basado en la nube. Para evitar posibles quejas de los usuarios de que sus informes ya no tienen sentido desde la migración, el siguiente paso es someter estos datos a un control de calidad exhaustivo.

Fase de examen: control de calidad para bases de datos

Dado que no se deben realizar cambios en las aplicaciones y bases de datos durante un proceso de migración, es importante eliminar cualquier característica que impida un rendimiento sólido. Se necesitan controles de calidad adicionales para garantizar una interacción fluida entre la aplicación y los niveles de la base de datos. Por lo tanto, deben garantizarse los siguientes puntos:

• Estándares de nomenclatura consistentes para objetos como tablas, vistas, disparadores, procedimientos almacenados y funciones definidas por el usuario (UDF).
• No utilizar columnas de gran tamaño, por ejemplo CHAR (500), si ninguno de los valores contenidos excede los 32 caracteres.
• Los GUID (identificadores únicos globales) no se utilizan como índices agrupados. Esto solo está permitido para tablas pequeñas que no están extendidas. También debe verificar si los GUID se usan como claves primarias del clúster, ya que esto puede causar numerosos problemas de rendimiento.
• No hay tipos de datos definidos como tamaño MAX, como NVARCHAR (MAX).
• No hay conversiones implícitas, ya que pueden causar serios problemas de código. En particular, cuando se usan las herramientas de Mapeo Relacional de Objetos (ORM), es más probable que ocurran problemas de conversión porque los ORM usualmente usan GUID como índices de clúster por defecto.

Además, la codificación de los tiempos de espera de consulta debe examinarse una vez más. Si los tiempos de espera del servidor ya ocurren en el entorno local para ciertas consultas, estos aumentarán en la nube. Para evitar esto, el código debe revisarse para que sea más resistente en la nube en comparación con los tiempos de espera de las consultas y las consultas asociadas se optimicen en consecuencia.

Otra tarea necesaria, pero en algunos casos posiblemente dolorosa, es la evaluación y prueba de funciones populares, como la creación de tablas temporales. Si bien estas características se utilizan a menudo para mejorar la lógica de la codificación, solo unas pocas tienen un efecto positivo en el rendimiento. Para evitar sorpresas desagradables en la nube, es mejor programar una prueba para las funciones de base de datos más utilizadas.

La documentación confiable facilita el cambio a la nube

En general, el paso a la nube requiere nada menos que crear una documentación completa basada en un catálogo de datos. Para evitar descubrir después de la migración que las aplicaciones y los usuarios literalmente han sacado la alfombra de debajo de sus pies, se debe agregar un paso más: registrar qué aplicaciones acceden a los datos registrados en el catálogo.

Esto puede parecer tan desagradable para los DBA como tener que lidiar con posesiones olvidadas durante la mudanza, pero es tan esencial en esta situación. Para simplificar el proceso de documentación, vale la pena usar las herramientas de administración apropiadas que pueden, entre otras cosas, crear automáticamente una descripción detallada del origen de los datos. De esta manera, se pueden crear condiciones adecuadas para una migración sin problemas y un uso eficiente de la nube.

Por Kevin Kline, Gerente principal del programa en SentryOne