La prima cosa di cui preoccuparsi per questo problema è quali dati sono necessari dove e quando. Per fare ciò, di solito inizio con la stupida versione seriale del problema.
Trova tutti i pacchi del valore di x $ / acro che si trovano entro i piedi di y di un altro pacco che è valutato a meno di z $ / acro.
foreach p in parcels {
if value(p) > x {
foreach q in parcels {
if (dist(p,q) <= y) and (value(q) < z) {
emit(p)
}
}
}
}
Sebbene questo algoritmo non sia ottimizzato, risolverà il problema.
Ho risolto un problema simile per la tesi del mio Master che trovava il pacco più vicino per ogni punto in un set di dati. Ho implementato la soluzione in PostGIS , Hadoop
e MPI . La versione completa della mia tesi è qui , ma riassumerò i punti importanti in quanto si applica a questo problema.
MapReduce non è una buona piattaforma su cui risolvere questo problema perché richiede l'accesso all'intero set di dati (o un sottoinsieme accuratamente selezionato) per elaborare un singolo pacchetto. MapReduce non gestisce bene i set di dati secondari.
MPI, tuttavia, può risolverlo abbastanza facilmente. La parte più difficile è determinare come dividere i dati. Questa suddivisione si basa sulla quantità di dati disponibili, sul numero di utenti che devono essere eseguiti e sulla quantità di memoria disponibile per processore. Per il miglior ridimensionamento (e quindi le prestazioni) è necessario disporre di più copie del set di dati dei pacchi in memoria (su tutti i computer) contemporaneamente.
Per spiegare come funziona, suppongo che ognuno dei tuoi 50 computer abbia 8 processori. Assegnerò quindi a ciascun computer la responsabilità di controllare 1/50 dei pacchi. Questo controllo verrà eseguito da 8 processi sul computer, ognuno dei quali ha una copia della stessa parte 1/50 dei pacchi e 1/8 del set di dati del pacco. Si noti che i gruppi non sono limitati a una singola macchina, ma possono oltrepassare i limiti della macchina.
Il processo eseguirà l'algoritmo, ottenendo i pacchi per p dal set 1/50 di pacchi e i pacchi per q dal set 1/8. Dopo il ciclo interno, tutti i processi sullo stesso computer parleranno insieme per determinare se il pacco debba essere emesso.
Ho implementato un algoritmo simile a questo per il mio problema. Puoi trovare la fonte qui .
Anche con questo tipo di algoritmo non ottimizzato sono stato in grado di ottenere risultati impressionanti che erano altamente ottimizzati per il tempo del programmatore (il che significa che avrei potuto scrivere uno stupido algoritmo semplice e il calcolo sarebbe ancora abbastanza veloce). Il prossimo punto da ottimizzare (se proprio ne hai bisogno), è impostare un indice quadtree del secondo set di dati (da cui ottieni q) per ogni processo.
Per rispondere alla domanda originale. C'è un'architettura: MPI + GEOS. Aggiungete un piccolo aiuto dalla mia implementazione ClusterGIS e si può fare molto. Tutto questo software può essere trovato come open source, quindi senza costi di licenza. Non sono sicuro di quanto sia portatile su Windows (forse con Cygwin) mentre ci lavoravo su Linux. Questa soluzione può essere implementata su EC2, Rackspace o qualunque cloud sia disponibile. Quando l'ho sviluppato utilizzavo un cluster di calcolo dedicato presso un'università.