Pergunta

Eu tenho uma necessidade para realizar a pesquisa distribuídos em um conjunto muito largo de arquivos pequenos (~ 10M) com cada arquivo sendo um conjunto de pares key: value. Eu tenho um conjunto de servidores com um total de 56 CPU núcleos disponíveis para isso -. Estas são na sua maioria dual core e quad core, mas também um grande DL785 com 16 núcleos

As necessidades de sistema a ser projetado para consultas on-line, eu estou idealmente olhando para implementar um serviço web que retorna saída JSON sob demanda a partir de um front-end.

Para mais havendo complicar, para qualquer pesquisa específico às vezes eu vou só quer olhar para o mais recente versão de cada arquivo, mas outras pesquisas só podem ser aplicadas a essas versões de arquivos que existiam em um data particular.

Eu olhei Hadoop, mas a administração é bastante horrível, e os métodos de submissão de trabalho padrão são lentos. Parece ser projetado para fora de linha de processamento de escala muito grande, e não para processamento de dados online.

CouchDB parece bom como um repositório de documentos e sabe sobre documentos estilo key: value e controle de versão e MapReduce, mas eu não consigo encontrar nada sobre como ele pode ser usado como um sistema MapReduce distribuído. Todas as conversações de documentação agrupamento sobre o uso de clusters e replicação do inteira banco de dados para balanceamento de carga , enquanto que o que eu preciso é load-distribuição .

Eu também investigou várias DHTs, e enquanto eles estão bem para realmente armazenar e recuperar registros individuais, eles são geralmente pobres em fazer a parte 'mapa' de MapReduce. Iteração sobre o conjunto documento completo é crucial.

Daí o meu sistema ideal seria constituído um sistema de arquivos distribuídos como HDFS do Hadoop, com as capacidades do CouchDB de serviços web.

Alguém pode me apontar na direção de qualquer coisa que possa ajudar? linguagem de implementação não é muito de uma preocupação, exceto que ele deve rodar em Linux.

Foi útil?

Solução

Parece que o domínio do problema seria mais adequado para uma solução como Solr. ofertas Solr http interfaces com outros aplicativos, mesmo JSON . Você pode particionar a pesquisa em várias máquinas ou distribuir uma cópia única entre máquinas para balanceamento de carga (master / slave). Seria depender do que funcionou melhor para seus dados. Mas, na minha experiência para resultados de pesquisa em tempo real, Lucene / Solr vai bater qualquer sistema baseado em um mapa do sistema / reduzir.

É muito simples de integrar Solr em um aplicativo e fazer atualizações incrementais. Realmente não têm qualquer idéia de versionamento embora. Se isso é realmente necessário você pode ter que encontrar outra maneira de alinhavar-lo.

Outras dicas

Eu posso ser um pouco confuso sobre o que suas necessidades de aplicação são, você menciona a necessidade de ser capaz de pesquisar através de pares de valores / chave, onde Solr seria uma grande aplicação. Mas você também mencionam a necessidade de usar a parte mapa do mapa / reduzir e que você precisa para documentos 10M de digitalização. Eu não tenho certeza que você vai encontrar uma solução que irá digitalizar documentos 10M e resultados de retorno de forma on-line (no intervalo de milissegundos). Mas uma outra solução é também olhar para HBase . Isto constrói em cima do HDFS e permite que você execute mapa reduzir postos de trabalho do tipo que você quiser, milhões de itens menores. Mas um trabalho não vai ser submittable e terminar em qualquer lugar perto o tempo que você está procurando.

Eu tenho atualmente um teste HBase configurado com itens RSS (itens 2M, vários Kb por item). Tamanho total DB é ~ 5Gb. Há vários trabalhos que são executados contra este DB a digitalização de todos os itens e resultados, em seguida, outputting. O cluster irá digitalizar itens em ~ 5.000 / segundo, mas ainda leva cerca de 10 minutos para concluir um trabalho.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top