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.