2010-05-01 13 views
5

Me gustaría crear una especie de configuración distribuida para ejecutar una tonelada de consultas web REST pequeñas/simples en un entorno de producción. Por cada 5-10 consultas relacionadas que se ejecutan desde un nodo, generaré una cantidad muy pequeña de datos derivados, que deberán almacenarse en una base de datos relacional estándar (como PostgreSQL).¿Solución para distribuir MUCHAS tareas de red simples?

¿Qué plataformas están diseñadas para este tipo de problema? La naturaleza, el tamaño de los datos y las cantidades parecen contradecir la mentalidad de Hadoop. También hay más arquitecturas basadas en grid como Condor y Sun Grid Engine, que he visto mencionar. No estoy seguro si estas plataformas tienen alguna recuperación de errores (verificando si un trabajo tiene éxito).

Lo que realmente me gustaría es una cola de tipo FIFO a la que pueda agregar trabajos, con el resultado final de que mi base de datos se actualice.

¿Alguna sugerencia sobre la mejor herramienta para el trabajo?

+0

Suena bastante similar a un programa de monitoreo (propietario) que estoy terminando. Se descarga periódicamente de varias URL a intervalos configurables, analizando y guardando los resultados en una base de datos PostgreSQL. Implementé esto como un único programa C++ que mantiene una cola de prioridad de trabajos de descarga (en realidad, un std :: map porque los trabajos deben retirarse cuando la monitorización está deshabilitada) y usa libcurl para realizar la descarga. No me he ocupado de agrupar los resultados principalmente porque el programa de monitoreo y la base de datos viven en el mismo servidor. Realmente no usé una plataforma, así que +1 :-) –

Respuesta

1

¿Has mirado Celery?

+0

Los proyectos parecen interesantes, aunque bastante jóvenes. Tampoco estoy seguro de su robustez, basada en las preguntas frecuentes: "Una de las razones por las que nunca se vacía la cola es que tiene un proceso de apio rancio tomando los mensajes como rehenes. Esto podría suceder si apical no se cerró correctamente". Además, la dependencia de django es algo molesta: "Si bien es posible usar Apio desde fuera de Django, aún necesitamos que Django se ejecute, esto es para usar el ORM y el cache-framework". – EmpireJones

+0

@empirejones En realidad, esa entrada de preguntas frecuentes ya no es relevante. Se trataba de eliminar trabajos actualmente en espera en la cola. Un trabajador puede reservar algunos trabajos por adelantado (debido al recuento de captación previa), si el trabajador retira la conexión del intermediario, los trabajos se envían a otro lugar (o al mismo trabajador si se vuelve a conectar). Los errores relacionados ahora están corregidos, se convierte en un problema con multiprocesamiento y bifurcación. – asksol

Cuestiones relacionadas