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

Question

我的一位同事正在与我争论在我们的应用程序(文本处理)中引入map-reduce概念。他的观点就是为什么我们不应该使用线程的概念，instead.We两者都是这种map-reduce范例的新概念。我认为使用map-reduce概念可以帮助开发人员减少处理线程同步、死锁和共享数据的开销。除了这个之外，还有什么比线程更适合map-reduce的概念吗？

Answer 1

你可以找到与此相关的论文，Comparing Fork/Join and MapReduce。

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

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

线程提供了以递归的方式将任务划分为多个子任务的工具；更多的层，在这个阶段进行“内部分叉”通信的可能性，更传统的编程。不会扩展到(至少在论文中)超过一台机器。这对于充分利用你的八核技术非常有用。

M-R只做了一次大的拆分，映射的拆分彼此之间根本不说话，然后把所有东西都减少在一起。单层，在reduce之前没有内部拆分的通信，并且可大规模扩展。非常适合利用您在云中所占的份额。

Answer 2

Map-reduce增加了大量的开销，但可以协调一大批机器来处理“令人尴尬的并行”用例。只有当你有多个核心并且只有一个主机时，线程才是值得的，但有许多框架在原始线程(例如并发，Akka)之上添加了抽象层，通常更容易使用。