Esta es una pregunta bastante específica para usuarios avanzados de apio. Permítanme explicar el caso de uso que tengo:
Tengo que ejecutar ~1k-100k tareas que ejecutarán una simulación (película) y devolverán los datos de la simulación como una lista bastante grande de objetos más pequeños (fotogramas), digamos 10k-100k por fotograma y 1k fotogramas. Entonces, la cantidad total de datos producidos será muy grande, pero supongamos que tengo una base de datos que puede manejar esto. La velocidad no es un factor clave aquí. Más tarde, necesito calcular las características de cada cuadro, lo que se puede hacer de forma completamente independiente.
Los marcos se ven como un dict que apunta a algunas matrices numpy y otros datos simples como cadenas y números y tienen un identificador único UUID.
Es importante que los objetos finales de interés sean uniones y divisiones arbitrarias de estas listas generadas. Como metáfora, considere que las películas resultantes se cortan y se recombinan en nuevas películas. Estas listas finales (películas) son básicamente una lista de referencias a los marcos que usan sus UUID.
Ahora, considero usar apio para obtener estas primeras películas y, dado que estas terminarán en la base de datos backend de todos modos, podría mantener estos resultados indefinidamente, al menos los que especifique para mantener.
¿Puedo configurar un back-end, preferiblemente una base de datos no SQL, de manera que mantenga los resultados y acceda a estos más tarde independientemente de Celery usando los objetos UUID? Y si es así, eso tiene sentido debido a los gastos generales y el rendimiento, etc.
Otra posibilidad sería no devolver nada y dejar que el trabajador almacene el resultado en una base de datos. ¿Es eso lo preferido? Parece innecesario tener un segundo canal de comunicación con otra base de datos cuando Celery ya puede hacerlo.
También estoy interesado en los comentarios sobre el uso de Celery en general para tareas altamente independientes que duran mucho tiempo (> 1 h) y devuelven objetos de resultados grandes. Una falla no es problemática y solo puede reiniciarse. ¡Las películas resultantes son estocásticas! por lo que los enfoques funcionales pueden ser problemáticos. ¡Incluso almacenar la semilla aleatoria podría no garantizar resultados reproducibles! aunque no tengo efectos secundarios. Es posible que tenga muchos trabajadores disponibles que estén ampliamente distribuidos. Imagine muchas máquinas de escritorio en un entorno cerrado donde cada trabajador ayuda, incluso si es lento. La velocidad y la seguridad de la red no son un problema aquí. Sé que este no es el caso de uso original, pero parecía muy fácil usarlo para estos casos. La mejor analogía que encontré son proyectos como Folding@Home.
¿Puedo configurar un back-end, preferiblemente una base de datos no SQL, de manera que mantenga los resultados y acceda a estos más tarde independientemente de Celery usando los objetos UUID?
Sí, puede configurar el apio para almacenar sus resultados en una base de datos NoSQL como redis para el acceso posterior mediante UUID. Las dos configuraciones que controlarán el comportamiento de su interés son result_expires y result_backend .
result_backend especificará en qué base de datos NoSQL desea almacenar sus resultados (por ejemplo, elasticsearch o redis) mientras que result_expires especificará cuánto tiempo después de que se complete una tarea, el resultado de la tarea estará disponible para el acceso.
Una vez completada la tarea, puede acceder a los resultados en python de esta manera:
from celery.result import AsyncResult result = task_name.delay() print result.id uuid = result.id checked_result = AsyncResult(uuid) # and you can access the result output here however you'd likeY si es así, eso tiene sentido debido a los gastos generales y el rendimiento, etc.
Creo que esta estrategia tiene mucho sentido. Por lo general, he usado esto varias veces al generar informes de ejecución prolongada para usuarios web. La publicación inicial devolverá el UUID de la tarea de apio. El cliente web puede sondear el servidor de aplicaciones a través de javascript usando el UUID para ver si la tarea está lista o completa. Una vez que el informe está listo, la página puede redirigir al usuario a la ruta que le permitirá descargar o ver el informe al pasar el UUID.