Ir al contenido

Una estrategia para gestionar tablas SQL grandes

·420 palabras·2 mins
SQL Bases de Datos
Alejandro Duarte
Autor
Alejandro Duarte
Alejandro Duarte es un Ingeniero de Software, escritor publicado y galardonado. Actualmente, trabaja para MariaDB plc como Ingeniero de Relaciones con Desarrolladores (Developer Relations Engineer). Comenzó su trayectoria en programación a los 13 años con BASIC en una rudimentaria pantalla negra, para lugo rápidamente transitar a C, C++ y Java durante sus años académicos en la Universidad Nacional de Colombia. Trasladándose primero al Reino Unido y luego a Finlandia, Alejandro profundizó su participación en la comunidad de código abierto. Es reconocido en los círculos de Java, acreditado con artículos y videos que acumulan millones de vistas, y presentaciones en eventos internacionales.

Nota: Traducido de la versión original en Inglés.

Hace unos meses, me involucré en un proyecto donde necesitaba generar reportes bastante grandes (más de 1 millón de filas) extraídos principalmente de una tabla SQL que crecía a un ritmo muy rápido. Esta tabla jugaba un papel central en el uso diario del sistema.

Para evitar perder rendimiento, programamos una copia de seguridad de la base de datos y un proceso para vaciar esa gran y problemática tabla cada 3 meses. Pero el problema con los reportes seguía siendo el mismo. En algún momento terminamos con una tabla de más de 3 millones de filas y a veces teníamos que generar reportes con más de 1 millón de filas. Incluso si el reporte era pequeño, consultar esta tabla estaba tomando demasiado tiempo (a veces más de 10 minutos).

Esto es lo que hicimos. Primero decidimos diseñar una especie de proceso ETL utilizando solo SQL (algunos argumentarán que esto no es ETL, pero yo creo que sí lo es). ¿Cómo? Desarrollamos un módulo para ejecutar todos los días a las 3:00 am scripts SQL definidos en tiempo de ejecución.

Estos scripts eran básicamente instrucciones tipo “ INSERT INTO table”. Tomaban datos de algunas tablas e insertaban el resultado en otra tabla. Los datos en la tabla de destino eran más adecuados para reportes, así que ganamos algo de tiempo al generar los reportes al mover el procesamiento (JOINs costosos principalmente) de las horas laborales a las 3:00 am, cuando nadie, ni siquiera el CEO, estaba usando el sistema. Los reportes eran mucho más rápidos (alrededor de 20 segundos para el más grande).

Un par de meses después de poner en producción este esquema, enfrentamos otro problema. La tabla de destino, que se suponía era más adecuada para reportes, empezó a ser un problema también. Como puedes imaginar, era demasiado grande. Nos enfrentábamos de nuevo a nuestra situación inicial. La solución: dividir ese gran conjunto de datos en conjuntos más pequeños. ¿Cómo? Cada fila en esa tabla tenía una marca de tiempo, así que dividimos los datos en semestres haciendo una tabla por semestre. El módulo ejecutor de scripts se modificó para poner los datos en la tabla correcta según la fecha actual. La aplicación de reportes también se actualizó para permitir a los usuarios seleccionar el semestre (así la aplicación podía consultar la tabla correcta).

Los reportes son bastante rápidos en el momento de escribir esto. Esta estrategia nos dio algo de tiempo para pensar en implementar una solución de Big Data.

Relacionados

Paginación: Una solución antigua de la web 1.0
·398 palabras·2 mins
UI
Nota: Traducido de la versión original en Inglés. Hace unos días, un usuario de Enterprise App me preguntó si la carga diferida (lazy loading) es mejor (particularmente en una aplicación de negocios) que la paginación.
Hola GitHub
·194 palabras·1 min
Noticias
Nota: Traducido de la versión original en Inglés. He sido usuario de ProjectLocker y Assembla durante años.
Mi nuevo sitio web
·162 palabras·1 min
Noticias
Nota: Traducido de la versión original en Inglés. Como algunos de ustedes ya saben, el próximo mes estaré haciendo mucho ruido acerca de Enterprise App e InfoDoc Pro.