线程和Map-Reduce处理之间的区别？

Question

我的一位同事正在与我争论在我们的应用程序（文本处理）中引入map-reduce概念。他的观点是为什么我们不应该使用线程概念。我们都是这个map-reduce范例的新手。我认为使用map-reduce概念可以帮助开发人员处理线程同步，死锁，共享数据的开销。除了这个之外还有什么东西可以用于map-reduce概念而不是线程化吗？

Answer 1

Map-reduce增加了大量的开销，但可以协调大量机器以实现“令人尴尬的并行”用例。如果您有多个内核并且只有一个主机，那么线程是值得的，但是有许多框架在原始线程（例如Concurrent，Akka）之上添加抽象层，这些框架通常更容易使用。

Answer 2

您可以找到相关论文Comparing Fork/Join and MapReduce。

本文比较了三种并行范例的性能，可伸缩性和可编程性：fork / join，MapReduce和混合方法。

他们发现基本上Java fork / join具有低启动延迟并且适用于小输入（<5MB），但由于共享内存的大小限制，它无法处理更大的输入， 单节点架构。另一方面，MapReduce具有显着的启动延迟（几十秒），但对于计算群集上的更大输入（> 100MB）可以很好地扩展。

线程提供了以递归方式将任务划分为多个子任务的工具;更多层次，跨叉的可能性＆＃39;在这个阶段的沟通，更传统的节目。不延伸（至少在论文中）超出单个机器。非常适合利用你的八核。

M-R只进行一次大的拆分，映射的拆分根本不相互通信，然后将所有内容一起减少。单层，在减少之前没有交叉间通信，并且可以大规模扩展。非常适合利用您的云份额。