我的一位同事正在和我争论在我们的应用程序（文本处理）中引入 map-reduce 概念。他的观点是为什么我们不应该使用线程概念。我们都是这种 map-reduce 范式的新手。我认为使用 map-reduce 概念可以帮助开发人员摆脱处理线程同步、死锁、共享数据的开销。除了这个之外，还有什么可以用于 map-reduce 概念而不是线程？
问问题
4250 次
2 回答
4
你可以找到相关的论文，比较 Fork/Join 和 MapReduce。
该论文比较了三种并行范例的性能、可扩展性和可编程性：fork/join、MapReduce 和混合方法。
他们发现基本上 Java fork/join 具有较低的启动延迟，并且可以很好地适应小输入（<5MB），但由于共享内存、单节点架构的大小限制，它无法处理更大的输入。另一方面，MapReduce 具有显着的启动延迟（数十秒），但可以很好地扩展计算集群上更大的输入（>100MB）。
线程提供了以递归方式将任务划分为多个子任务的工具；更多的层，在这个阶段“跨叉”通信的可能性，更传统的编程。不延伸（至少在论文中）超出单台机器。非常适合利用您的八核。
MR 只进行一次大拆分，映射的拆分彼此之间根本不交谈，然后将所有内容缩减在一起。单层，在减少之前没有拆分间通信，并且可大规模扩展。非常适合利用您的云份额。
于 2014-08-22T05:05:11.193 回答
2
Map-reduce 增加了大量的开销，但可以协调大量机器以实现“令人尴尬的并行”用例。只有当你有多个内核和一个主机时，线程才是值得的，但是有许多框架在原始线程（例如并发，Akka）之上添加了抽象层，这些抽象层通常更容易使用。
于 2012-12-11T08:45:14.217 回答