Las historias siempre son interesantes y ésta podría serlo o no. Lo que es seguro es que te servirá para hacerte una idea del escenario en el que diariamente nos peleamos los y las del equipo de base de datos (BD) de RETAbet porque, queramos o no, siempre existen deudas tecnológicas y hay cosas que llevamos mucho tiempo arrastrando por cómo había que hacer las cosas antes y que, poco a poco, la tecnología nos ha permitido mejorar. Y sin más, arrancamos con nuestra pequeña historia.

Corría el año 2008 y en el mes de agosto de ese año, en concreto el día 26, se hacía la primera apuesta deportiva en una de nuestras máquinas de Bilbao. Pero, ¿qué había detrás de todo eso?

A nivel técnico podríamos hablar de muchas cosas pero me voy a centrar en la parte de los datos, soportada por una base de datos Microsoft SQL Server 2005.

Para obtener la licencia para operar en Euskadi (la primera de las muchas que tenemos) nos exigían que garantizásemos que el servicio no se cayese más de 4 horas seguidas. Para lograrlo, creamos una infraestructura de alta disponibilidad basada en dos Centros de Procesos de Datos (CPDs), uno principal y otro secundario. En el principal teníamos dos servidores de BD en un clúster de conmutación por error activo/pasivo y en el secundario había un tercer servidor de BD con mirroring asíncrono.

Durante los primeros años nos enfrentamos a problemas puntuales de rendimiento. Algunos de ellos ocurrían a finales de mes cuando, al tener una conexión compartida entre ambos CPDs, el tráfico de red aumentaba y se retrasaba la sincronización entre ellos. Y otros, como la presión de memoria, estaban más relacionados con los primeros síntomas de que la plataforma necesitaba una serie de mejoras.

La primera evolución ocurrió a finales del 2010, cuando ampliamos la memoria de nuestros servidores de BD. Esto nos permitió “sobrevivir” unos cuantos años más, mientras en el Departamento Técnico comenzábamos a especializarnos en distintas áreas y a recibir formación más específica; en mi caso, de BBDD. Mientras tanto, el motor de SQL Server también iba evolucionando, con las versiones 2008, 2008 R2 y 2012. No obstante, nosotros no hicimos ningún cambio sustancial del motor de SQL Server más allá de actualizaciones de Service Packs y parches varios.

En 2012 estuvimos valorando si migrarlo todo a Oracle, pero lo acabamos descartando porque suponía un gran esfuerzo técnico y humano y no veíamos que mereciera la pena tras comenzar a informarnos sobre las mejoras que se estaban cocinando en las nuevas versiones de SQL Server.

Al estudiar estas mejoras detectamos algunas que necesitábamos desesperadamente, siendo algunas de ellas:

  • Los parámetros de tipo tabla: hasta entonces usábamos XML o máscaras de bits cuando era posible
  • Compresión de las copias de seguridad
  • Algunas de las nuevas funciones que habían introducido en T-SQL como la cláusula OVER y las nuevas funciones de agregado

Así que nos empezamos a preparar para actualizar el motor de SQL Server desde 2005 a una versión más reciente y, a finales de 2014, hicimos nuestra primera gran migración a SQL Server 2014.

Con la transición a SQL Server 2014, decidimos dejar de utilizar mirroring y sustituirlo por Always On, una tecnología nueva de replicación de datos que apareció en el SQL Server 2012, con lo que el planteamiento de alta disponibilidad cambiaba y nuestro servidor del CPD secundario pasaba a formar parte del clúster y del grupo de alta disponibilidad, funcionando como réplica secundaria.

Tras superar los problemas típicos de cualquier migración, o más específicos de la migración a 2014 como el cambio del Cardinality Estimator, se nos abrió un mundo de posibilidades como desarrolladores, y ganamos una mejora considerable en el rendimiento ya que aprovechamos para mejorar no sólo el motor, sino también el equipamiento.

Pero RETAbet seguía creciendo y, aunque esta vez no teníamos la necesidad de una migración urgente, llegó el SQL Server 2016 con:

  • Mejoras en tempDB
  • QueryStore
  • Json
  • Nuevas características de seguridad

Y como le habíamos cogido “gusto” a esto de las migraciones de BD, nos lanzamos a la piscina y, a finales del 2017, migramos a SQL Server 2016 (aún no existía una versión estable de SQL Server 2017)

Y ya llegamos al final de nuestra historia (al menos por ahora). Nuestro escenario actual es que trabajamos con un motor SQL Server 2016, ya en el SP2, con servidores en clúster de conmutación por error y grupos de alta disponibilidad de Always On.

Una pena que la versión de SQL Server 2017 nos pillara recién actualizados a 2016 pero, ¿a la 2019 nos animaremos a migrar? ...¡Quién sabe! Seguid leyéndonos, que si lo hacemos, seguro que os lo contaremos en este Blog.

¡Hasta la próxima!