2010-05-01 15 views
5

Vorrei creare una sorta di configurazione distribuita per eseguire una tonnellata di query Web REST di piccole dimensioni/semplici in un ambiente di produzione. Per ogni 5-10 query correlate che vengono eseguite da un nodo, genererò una quantità molto piccola di dati derivati, che dovranno essere memorizzati in un database relazionale standard (come PostgreSQL).Soluzione per la distribuzione di MOLTE semplici attività di rete?

Quali piattaforme sono state create per questo tipo di set di problemi? La natura, le dimensioni dei dati e le quantità sembrano contraddire la mentalità di Hadoop. Ci sono anche altre architetture basate sulla rete come Condor e Sun Grid Engine, che ho visto menzionate. Non sono sicuro che queste piattaforme abbiano comunque un recupero dagli errori (verificando se un lavoro ha esito positivo).

Quello che mi piacerebbe davvero è una coda di tipo FIFO alla quale potrei aggiungere posti di lavoro, con il risultato finale del mio database che si aggiorna.

Qualche suggerimento sullo strumento migliore per il lavoro?

+0

Suoni del tutto simili a un programma di monitoraggio (proprietario) che sto finendo. Scarica periodicamente da più URL a intervalli configurabili, analizzando e salvando i risultati in un database PostgreSQL. Ho implementato questo come un singolo programma C++ che mantiene una coda di priorità dei lavori di download (in realtà una std :: map perché i lavori devono essere estratti quando il monitoraggio è disabilitato) e usa libcurl per eseguire il download. Non ho affrontato il raggruppamento dei risultati principalmente perché il programma di monitoraggio e il database vivono sullo stesso server. Non ho davvero usato una piattaforma, quindi +1 :-) –

risposta

1

Hai guardato Celery?

+0

I progetti sembrano interessanti, anche se abbastanza giovani. Inoltre, non sono sicuro della sua robustezza, basata sulle FAQ: "Uno dei motivi per cui la coda non viene mai svuotata potrebbe essere il fatto che il processo di sedimentazione stia prendendo in ostaggio i messaggi. Ciò potrebbe accadere se Celeryd non fosse correttamente spento". Inoltre, la dipendenza da django è piuttosto fastidiosa: "Mentre è possibile utilizzare Celery da Django, è comunque necessario eseguire Django stesso, utilizzando ORM e cache-framework." – EmpireJones

+0

@empirejones In realtà questa voce delle FAQ non è più rilevante. Si trattava di cancellare i lavori in attesa attualmente in coda. Un lavoratore può prenotare alcuni lavori in anticipo (a causa del numero di prefetch), se il lavoratore interrompe la connessione del broker, i lavori vengono inviati altrove (o lo stesso operatore se si riconnette). I bug correlati sono ora corretti, si è verificato un problema con il multiprocessing e il biforcazione. – asksol

Problemi correlati