Informes en tiempo real a gran velocidad y escala

Cuando una importante empresa de logística del Reino Unido quiso mejorar la elaboración de informes para sus grandes cuentas, recurrió a Actian para diseñar, implantar y dar soporte al sistema de base de datos subyacente ("LARS") utilizando los productos Ingres, HVR y Vector para su arquitectura.

Resumen

El cliente tenía alrededor de 100 representantes de cuentas de clientes dedicados a grandes cuentas, y cada representante elaboraba manualmente su propio conjunto de informes diarios, semestrales y ad hoc basados en hojas de cálculo para enviarlos por correo electrónico a sus contactos de cuentas, a partir de una serie de extractos diarios de una base de datos Ingres de nivel operativo.

El cliente quería estandarizar el formato de los informes y automatizar su producción para ahorrar tiempo a los representantes, entregar los informes a sus cuentas de forma coherente y puntual y, en última instancia, hacer viable la externalización de la función.

El reto no consistía sólo en producir el volumen de informes analíticos complejos programados (más de 1.000 al día, agrupados en torno a las horas críticas de media mañana y media tarde) y, al mismo tiempo, dar soporte a la producción de informes complejos ad hoc para 200 usuarios con un tiempo de respuesta de segundos, sino también a) hacerlo sin una sobrecarga significativa de la base de datos operativa de origen y b) reducir la necesidad de la gama de extractos existentes de la base de datos operativa. Otro requisito era que en el futuro fuera posible "cambiar" otras aplicaciones existentes de la base de datos operativa a esta nueva base de datos, lo que obligaba a que el diseño de la base de datos fuera lo más similar posible al de la base de datos operativa existente.

Debido a los retrasos en el inicio del proyecto (por cambios en la organización del cliente), hubo una presión considerable para entregar el proyecto en el plazo más breve posible.

Arquitectura

Para proporcionar el servicio de análisis e informes front-end visible para el usuario se eligió un paquete semipersonalizado de una organización asociada, basado en el producto Logi Analytics.

El diseño del esquema de la base de datos se vio limitado por el diseño del esquema de la base de datos de origen, lo que dio lugar a la necesidad de proporcionar una serie de vistas de la base de datos que implicaban uniones sobre 12 tablas, algunas de las cuales tenían más de 300 millones de filas. Con el fin de ofrecer a los usuarios interactivos tiempos de respuesta realistas y, al mismo tiempo, satisfacer las necesidades de los informes programados, se eligió Vector como el SGBD ideal para esta base de datos, debido a su gran velocidad de procesamiento de consultas de recuperación complejas y a su capacidad para reflejar la estructura de la base de datos de origen Ingres prácticamente sin cambios.

Dado que la base de datos Ingres de origen y la base de datos Vector de destino tenían esencialmente esquemas similares, se eligió HVR (High Volume Replicator) como solución de software para mantener la base de datos Vector en línea con la base de datos Ingres de origen. El proceso de captura de HVR lee el registro de transacciones de la base de datos Ingres de origen y transmite las operaciones de inserción y actualización a través del concentrador de HVR a la máquina de destino, donde el proceso de integración de HVR refleja las inserciones y actualizaciones como "upserts" en la base de datos Vector (las "supresiones" se suprimieron en HVR para evitar que las purgas periódicas de la base de datos de origen también provocaran purgas en la base de datos de destino), lo que supuso una carga muy reducida para la máquina de la base de datos de origen.

La aplicación

La base de datos fuente de Ingres se ejecuta en una plataforma HP-UX antigua, por lo que HVR se instaló en un servidor Linux dedicado para que actuara como su Hub. La base de datos Vector se encuentra en otro servidor Linux dedicado. Un componente de "captura" de HVR se ejecuta en la máquina Ingres, captura los cambios de la base de datos de origen desde el registro de transacciones y los envía a través del concentrador de HVR al componente de "integración" de HVR que se ejecuta en el servidor Vector y que aplica los mismos cambios (mediante "upserts") a la base de datos Vector de destino.

Para satisfacer la necesidad del cliente de reducir los plazos de desarrollo, el proyecto se entregó listo para las pruebas de aceptación del usuario en 3 meses desde el inicio del desarrollo, gracias a la capacidad de Vector de reflejar un esquema Ingres con pocos cambios.

Para reducir el número de uniones de tablas en las vistas de 12 a un número más manejable de 9, se creó una tarea programada regularmente (que se ejecuta cada 10 minutos) para mantener una tabla desnormalizada.

El trabajo de actualización de desnormalización, el trabajo "upsert" de HVR, el gran número de informes programados y los usuarios interactivos coexisten felizmente en el servidor Vector.

Rendimiento vectorial

A menudo no tiene sentido citar los tiempos de respuesta de recuperación de un sistema, ya que hay muchas variables implicadas, pero podemos dar una idea del rendimiento de recuperación de la base de datos Vector en comparación con su base de datos de origen Ingres. Un miembro del personal informático del cliente tuvo que ejecutar una consulta SQL ad hoc excesivamente pesada en la base de datos de origen Ingres, que se ejecutó durante 10 minutos antes de que la eliminara por insostenible. Ejecutamos la misma consulta SQL en la base de datos Vector en tiempo real, durante el horario de máxima actividad, y se completó en 0,05 segundos. Aunque no se trata de una comparación directa, ya que las dos bases de datos se ejecutaban en plataformas y configuraciones de hardware diferentes, sí ilustra la espectacular velocidad de recuperación de la que es capaz Vector.

De hecho, el rendimiento de Vector fue tan impresionante que cambió los requisitos especificados por el equipo de cara al cliente. La práctica de trabajo prevista era permitir que se ejecutaran hasta ~200 informes complejos entre las 10 de la mañana y las 10:30, pero Vector era tan rápido y cómodo a escala que ahora todos estos informes se ejecutan en menos de 5 minutos a partir de las 10 de la mañana y eso solo estaba limitado por los recursos (núcleos, memoria, etc.) de la máquina.

Satisfacción del cliente

El cliente quedó tan impresionado con la novedosa arquitectura de la aplicación LARS que encargó un segundo proyecto, más exigente, basado en vectores y alimentado por un flujo continuo de mensajes. Este será el tema de una futura entrada en el blog.

Acerca de Emma McGrattan

Emma McGrattan es CTO en Actian, liderando la I+D global en análisis de alto rendimiento, gestión de datos e integración. Con más de dos décadas en Actian, Emma tiene múltiples patentes en tecnologías de datos y ha sido fundamental en el impulso de la innovación para aplicaciones de misión crítica. Es una autoridad reconocida, con frecuentes ponencias en conferencias del sector como Strata Data, y ha publicado artículos técnicos sobre analítica moderna. Conéctese con ella en LinkedIn https://www.linkedin.com/in/emma-mcgrattan/. En sus publicaciones del blog de Actian, Emma aborda la optimización del rendimiento, las arquitecturas de nube híbrida y las estrategias de análisis avanzadas. Explore sus artículos principales para desbloquear el éxito impulsado por los datos.