Diseñando un procesador con disparador de temporizador que depende de datos provenientes de eventos.
Estoy tratando de diseñar un procesador activado por temporizador (todo en Azure) que procesará un conjunto de registros que se le asignarán para ser consumidos. Los agrupará basándose en una columna, creará archivos a partir de ellos y los volcará en un contenedor de blobs. Se supone que los registros que consumirá se generarán en función de un evento, cuando se levante ese evento, conteniendo una clave que se puede utilizar para consultar los datos del registro (los datos/registro generados deben extraerse de diferentes servicios).
Esto es lo que estoy pensando actualmente:
- Se levanta un evento en el topic de event-grid.
- La función de Azure (ConsumerApp) se activa con el evento, lee la clave, llama a una API de servicio para obtener todos los datos y almacena ese registro en una tabla de almacenamiento, con una marca de “listo para ser consumido”.
- La función de Azure (ProcessorApp) se activa por temporizador, leerá de la tabla de almacenamiento, agrupará según otra columna, los creará y los volcará como archivos. Esto también puede marcar los registros como procesados, si no fueron actualizados previamente por ConsumerApp.
Algunas de mis preguntas sobre esto, aparte de cualquier manera de hacerlo de una manera mejor y diferente, son:
- El almacenamiento de tabla se llenará rápidamente, lo que nuevamente disminuirá la velocidad para leer los “casos listos”, ¿existe algún enfoque mejor para almacenar estos datos intermedios y temporales? Una cosa que pensé fue vaciar la tabla regularmente o eliminar el registro de la aplicación del consumidor en lugar de marcarlo como “procesado”.
- La API de servicio se llama para cada evento, lo que podría aumentar la carga en ese servicio/su base de datos. ¿Debo agrupar la llamada de registros como una sola llamada a la API, ya que el procesador se ejecutará solo después de un intervalo determinado, o existe un enfoque mejor aquí?
Se agradecerán cualquier comentario sobre este enfoque o un diseño nuevo.
davy.ai
Respuesta
Resumen del diseño
Según la información proporcionada, estás intentando diseñar un procesador activado por temporizador que consuma registros generados por un evento. Los registros se generan en función de una clave, que se utiliza para consultar datos de diferentes servicios. El procesador agrupará los registros en función de una columna, creará archivos y los almacenará en un contenedor de blob.
Tu diseño actual implica el uso de un tema de Event Grid, dos Azure Functions (ConsumerApp y ProcessorApp) y una tabla de almacenamiento para almacenar los registros. ConsumerApp se activa mediante el evento, lee la clave, llama a una API de servicio para obtener los datos y almacena el registro en la tabla de almacenamiento. ProcessorApp se activa mediante un temporizador, lee de la tabla de almacenamiento, agrupa los registros, crea archivos y marca los registros como procesados.
Pregunta 1
La tabla de almacenamiento se llenará rápidamente, lo que disminuirá la velocidad para leer los ‘casos listos’. ¿Existe algún enfoque mejor para almacenar estos datos intermedios y temporales?
Un enfoque posible es utilizar una cola de mensajes en lugar de una tabla de almacenamiento para almacenar los registros. Cuando ConsumerApp recupera el registro de la API de servicio, puede agregarlo a una cola de mensajes. Luego, ProcessorApp puede leer de la cola de mensajes, agrupar los registros, crear archivos y marcar los registros como procesados. Usar una cola de mensajes en lugar de una tabla de almacenamiento puede reducir la carga en el almacenamiento y mejorar la velocidad de procesamiento.
Otro enfoque posible es utilizar una caché en lugar de una tabla de almacenamiento para almacenar los registros temporalmente. Cuando ConsumerApp recupera el registro de la API de servicio, puede agregarlo a la caché. Luego, ProcessorApp puede leer de la caché, agrupar los registros, crear archivos y marcar los registros como procesados. Usar una caché en lugar de una tabla de almacenamiento puede brindar un acceso más rápido a los registros.
Pregunta 2
Se llama a la API de servicio para cada evento, lo que podría aumentar la carga en ese servicio/su base de datos. ¿Deberías agrupar la llamada para obtener registros como una sola llamada a la API, ya que el procesador se ejecutará solo después de un intervalo establecido, o hay un enfoque mejor aquí?
Agrupar las llamadas para obtener registros como una sola llamada a la API puede reducir la carga en el servicio/base de datos y mejorar el rendimiento. Cuando se genera un evento, ConsumerApp puede agregar la clave a una cola. Luego, ProcessorApp puede recuperar las claves de la cola, agruparlas y realizar una sola llamada a la API de servicio para recuperar todos los registros para esas claves. Este enfoque puede reducir el número de llamadas a la API de servicio y mejorar la eficiencia del sistema.
Otro enfoque posible es utilizar una caché para almacenar los registros temporalmente, como se menciona en la respuesta a la Pregunta 1. Si los registros ya están en la caché, ConsumerApp puede recuperarlos de la caché en lugar de llamar a la API de servicio. Este enfoque puede reducir aún más la carga en el servicio/base de datos y mejorar el rendimiento.
Comentarios
Tu diseño actual parece razonable, pero hay ciertas áreas que se pueden mejorar, como se mencionó anteriormente. El uso de una cola de mensajes o una caché puede reducir la carga en el almacenamiento y mejorar la velocidad de procesamiento. Agrupar las llamadas para obtener registros como una sola llamada a la API puede reducir la carga en el servicio/base de datos y mejorar la eficiencia del sistema.
En general, tu enfoque de diseño es sólido y, con algunas mejoras menores, puede ser un sistema confiable y eficiente.