建议数据处理（MapReduce / DHT？）框架

Question

我需要在一组较大的小文件（~10M）中执行分布式搜索，每个文件都是一组key: value对。我有一组服务器，总共有56个CPU内核可供使用 - 这些服务器主要是双核和四核，还有一个16核的大型DL785。

系统需要设计用于在线查询，我理想地希望实现一个Web服务，该服务根据需要从前端返回JSON输出。

为了使问题更加复杂，对于任何特定搜索，有时我只想查看每个文件的最新版本，但其他搜索可能仅适用于存在于某个文件的那些版本的文件。特别的日期。

我看过Hadoop，但管理非常糟糕，默认的作业提交方法很慢。它似乎是为离线超大规模处理而设计的，而不是用于在线数据处理。

CouchDB作为文档存储看起来不错，并且知道<=>样式文档和版本控制以及MapReduce，但我找不到任何关于如何将它用作分布式 MapReduce系统的信息。所有集群文档都讨论了使用整个数据库的集群和复制来实现负载平衡，而我需要的是负载分配。

我还调查了各种DHT，虽然它们可以实际存储和检索单个记录，但它们在执行MapReduce的“map”部分时通常很差。迭代完整的文档集至关重要。

因此，我的理想系统将包括像Hadoop的HDFS这样的分布式文件系统，以及CouchDB的Web服务功能。

有人能指出我可能会有所帮助的方向吗？除了必须在Linux上运行外，实现语言并不是太令人担忧。

Answer 1

似乎问题域更适合像Solr这样的解决方案。 Solr为其他应用程序提供http接口，甚至 JSON 。您可以跨多台计算机对搜索进行分区，或者跨计算机分发单个副本以进行负载平衡（主/从）。这取决于哪种方法最适合您的数据。但根据我对实时搜索结果的体验，Lucene / Solr将打败任何基于map / reduce系统的系统。

将Solr集成到应用程序并进行增量更新非常简单。它虽然没有真正的版本控制的想法。如果真的有必要，你可能必须找到另一种方法来解决它。

Answer 2

我可能对您的应用程序需求有点困惑，您提到需要能够搜索键/值对，其中Solr将是一个很棒的应用程序。但是你也提到需要使用map / reduce的map部分，你需要扫描10M文档。我不确定你是否会找到一个能够扫描10M文档并以在线方式返回结果的解决方案（在毫秒范围内）。但另一个解决方案是查看 HBase 。它建立在HDFS之上，允许您运行所需类型的地图缩减作业，数百万个较小的项目。但是一份工作不是可以提交的，而是在你正在寻找的任何地方完成。

我目前有一个测试HBase设置RSS项目（2M项目，每个项目几Kb）。总DB大小约为5Gb。有几个作业针对此DB扫描所有项目然后输出结果。群集将以~5,000 /秒的速度扫描项目，但仍需要大约10分钟才能完成作业。