Introducción

Una de las primeras preguntas que nos hacemos cuando planteamos una migración es si la nueva plataforma nos proporciona las mismas posibilidades que la actual. Microsoft ha hecho un enorme esfuerzo para facilitar el cambio de bases de datos IaaS a entornos PaaS, haciendo compatibles muchas de las características básicas que nos podemos encontrar en SQL Server excepto una de ellas que nos puede hacer replantearnos la migración.

Las bases de datos PaaS están preparadas para ser entornos aislado, esto impide que se puedan realizar consultas que utilicen otras bases de datos diferentes a la que las está lanzando. Para sortear esta problemática, tenemos dos opciones, la primera y más tediosa sería restructurar las bases de datos en una única base de datos con el fin de que las consultas que se lancen no impliquen otras bases de datos. La segunda opción es utilizar Elastic Queries lo cual solo implica realizar cambios menores en el código SQL subyacente de nuestras aplicaciones.

Elastic Query es una característica de las Azure SQL Databases que permite realizar consultas que abarquen múltiples bases de datos, está disponible a partir del tier Standard sin coste añadido. Elastic Query se encuentra en preview y estas son algunas de sus limitaciones que caben destacar:

  • Son incompatibles en proyectos de bases de datos de Visual Studio.
  • Solo proporciona modo lectura, el modo escritura todavía no está soportado.
  • Solo se soportan queries entre Azure SQL Databases

Escenario

Vamos a plantear un escenario donde tenemos un cliente que tiene una instancia SQL Server con varias bases de datos.

La compañía tiene sedes tanto en Alemania como en España y tiene una base de datos por sede, además de una base de datos central donde podemos encontrar vistas que unifican los datos entre sedes. El cliente utiliza esta base de datos central para unificar los datos de las sedes y poder explotarlos mediante herramientas de reporting.

Elastic query database

Un ejemplo de vista sería WorldWideCustomer, la cual unifica las tablas Customer de las bases de datos de Alemania y España. A este tipo de escenario se le conoce como particionado horizontal o sharding.

PaaSando datos: External data source y Elastic query

También encontramos uniones de tablas que se encuentran en diferentes bases de datos. Por ejemplo, el procedimiento almacenado ListSpanishEmployees une la tabla Employees de la base de datos CompanySpain con la tabla Office de la base de datos Company. A este escenario se le conoce como particionamiento vertical.

Elastic query procedure

Como podemos apreciar, en la lógica de nuestras consultas se utilizan nombres de tablas con 3 partes, esta sintaxis de SQL es incompatible en las Azure SQL Database.

PaaSando datos: External data source y Elastic query

Migrando el Escenario

Lo primero que tenemos que hacer es recrear las bases de datos y tablas que teníamos en IaaS en PaaS.

elastic query data server

Y ahora vamos a trabajar sobre nuestra base de datos Company como maestro y las otras dos bases de datos como esclavos.

Lo primero que vamos a hacer es crear una Master Key en la base de datos Company.

CREATE MASTER KEY;

GO

A continuación, debemos crear las credenciales que utilizará nuestra base de datos para conectarse al servidor donde se encuentran las otras bases de datos.

CREATE DATABASE SCOPED CREDENTIAL DbCredentials

WITH IDENTITY = ‘erodriguez’,                  

SECRET = ‘P@SSw0rd’;                  

GO

Una vez creadas las credenciales, procedemos a añadir las fuentes externas, en nuestro caso serán las bases de datos CompanyGermany y CompanySpain que se encuentran en el mismo servidor.

CREATE EXTERNAL DATA SOURCE SlaveCompanyGermany

WITH

(

    TYPE=RDBMS,                          

    LOCATION=’elasticqueryserver.database.windows.net’,

    DATABASE_NAME=’CompanyGermany’,       

    CREDENTIAL=DbCredentials               

);

GO

Repetiríamos el mismo proceso para CompanySpain, alterando el valor de la variable DATABASE_NAME.

Ahora añadimos las tablas que necesitamos utilizar desde la base de datos Company. Por ejemplo, la tabla Customer:

CREATE EXTERNAL TABLE [dbo].[Customer_CompanyGermany]

(

    [Id] int,

   [Name] [nvarchar](100)

)

WITH (DATA_SOURCE = [SlaveCompanyGermany], 

      SCHEMA_NAME = ‘dbo’,          

      OBJECT_NAME = ‘Customer’     

    );

GO

Una vez añadidas nuestras tablas externas a la base de datos principal, necesitamos modificar la lógica de nuestras vistas y procedimientos almacenados para que utilicen las nuevas tablas externas. Por ejemplo, la vista WorldWideCustomers quedaría así:

PaaSando datos: External data source y Elastic query

Y nuestro procedimiento almacenado ListSpanishEmployees así:

elastic query create procedure

Cabe destacar que la primera vez que lancemos estas consultas, el rendimiento será bajo, pero este mejorará en las siguientes ejecuciones.

Otra posibilidad que podríamos haber contemplado para esta migración y que habría sido totalmente posible consistiría en desplegar las bases de datos en otras zonas que ofrezcan menos latencia para las diferentes sedes. De esta forma habríamos mejorado el tiempo de respuesta para las sedes a costa de aumentar el tiempo de respuesta para utilizar las bases de datos desde la base de datos central, pero teniendo en cuenta que dicha base de datos solo se utiliza para reporting, habría sido una opción interesante.

Una vez adaptado nuestro código SQL, podemos dar por finalizada la migración.

Conclusiones

Con esta nueva funcionalidad, Microsoft nos ofrece una valiosa posibilidad de sortear uno de los problemas de Azure SQL Database de cara a migrar una base de datos IaaS a un entorno PaaS. Sin dicha herramienta, habría sido necesario reestructurar y unificar las bases de datos, lo cual habría ampliado considerablemente el coste de la migración, aumentando las posibilidades de que no se realizará. En su lugar, solo hemos requerido de una pequeña adaptación de la lógica de nuestras consultas para mantener el funcionamiento original de nuestras aplicaciones.

Finalmente, debemos destacar que esta herramienta se encuentra todavía en preview. De haber requerido escritura a partir de nuestra base de datos maestra, esta opción no nos habría sido valida.

Más Información Relacionada

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

¿Qué es Business Intelligence? datos únicos integrados (02)

En esta entrega buscamos profundizar en las definiciones de Business Intelligence, haciendo hincapié en la importancia de tener una versión única de la verdad, es decir, un solo almacén de datos consolidados capaz de responder a las preguntas de negocio. Por otro lado se busca establecer una diferencia entre el tipo de preguntas de negocio que podrá responder un sistema ERP contra las que podrá responder un sistema de BI.