A primeira coisa a se preocupar com esse problema é quais dados são necessários, onde e quando. Para fazer isso, geralmente começo com a versão estúpida e serial do problema.
Encontre todas as parcelas no valor de x $ / acre que estão a y pés de outra parcela avaliada em menos de z $ / acre.
foreach p in parcels {
if value(p) > x {
foreach q in parcels {
if (dist(p,q) <= y) and (value(q) < z) {
emit(p)
}
}
}
}
Embora esse algoritmo não seja otimizado, ele resolverá o problema.
Resolvi um problema semelhante para minha tese de mestrado, que encontrou a parcela mais próxima para cada ponto de um conjunto de dados. Eu implementei a solução no PostGIS , Hadoop
e MPI . A versão completa da minha tese está aqui , mas vou resumir os pontos importantes que se aplicam a esse problema.
O MapReduce não é uma boa plataforma para resolver esse problema, pois requer acesso a todo o conjunto de dados (ou a um subconjunto cuidadosamente selecionado) para processar um único pacote. O MapReduce não lida bem com conjuntos de dados secundários.
O MPI, no entanto, pode resolver isso com bastante facilidade. A parte mais difícil é determinar como dividir os dados. Essa divisão é baseada na quantidade de dados existentes, em quantos processadores você precisa executá-los e em quanta memória você tem por processador. Para obter o melhor dimensionamento (e, portanto, desempenho), você precisará ter várias cópias do conjunto de dados das parcelas na memória (em todos os computadores) de uma só vez.
Para explicar como isso funciona, assumirei que cada um dos seus 50 computadores possui 8 processadores. Atribuirei a cada computador a responsabilidade de verificar 1/50 das parcelas. Essa verificação será executada por 8 processos no computador, cada um com uma cópia da mesma parte 1/50 das parcelas e 1/8 do conjunto de dados da parcela. Observe que os grupos não estão limitados a uma única máquina, mas podem cruzar os limites da máquina.
O processo executará o algoritmo, obtendo as parcelas para p do conjunto 1/50 de parcelas e as parcelas para q do conjunto 1/8. Após o loop interno, todos os processos no mesmo computador conversarão juntos para determinar se a parcela deve ser emitida.
Eu implementei um algoritmo semelhante a este para o meu problema. Você pode encontrar a fonte aqui .
Mesmo com esse tipo de algoritmo não otimizado, eu era capaz de obter resultados impressionantes altamente otimizados para o tempo do programador (o que significa que eu poderia escrever um algoritmo simples estúpido e a computação ainda seria rápida o suficiente). O próximo ponto a otimizar (se você realmente precisar) é configurar um índice quadtree do segundo conjunto de dados (de onde você obtém q) para cada processo.
Para responder à pergunta original. Existe uma arquitetura: MPI + GEOS. Dê uma pequena ajuda da minha implementação do ClusterGIS e muito pode ser feito. Todo esse software pode ser encontrado como código aberto, sem taxas de licenciamento. Não tenho certeza de como é portátil para o Windows (talvez com Cygwin), pois trabalhei nele no Linux. Esta solução pode ser implantada no EC2, Rackspace ou em qualquer nuvem disponível. Quando o desenvolvi, estava usando um cluster de computação dedicado em uma universidade.