没有扩大规模与-out的原因？

Question

作为程序员，我每隔几年就会做出革命性的发现。我要么在曲线之前，要么在相位之后约为π。我学到的一个难点是，缩小OUT并不总是更好，通常情况下，当我们重新组合并扩大规模时，最大的性能提升。

你有什么理由可以扩大规模？价格，性能，愿景，预计用量？如果是这样，这对你有用吗？

我们曾经扩展到数百个节点，这些节点将序列化并将必要的数据缓存到每个节点，并在记录上运行数学过程。需要（交叉）分析许多，数十亿条记录。采用横向扩展是完美的业务和技术案例。我们一直在优化，直到我们在26小时的时钟内处理了大约24小时的数据。真的很长一点，我们租用了一个巨大的（当时）IBM pSeries，将Oracle Enterprise放在上面，索引我们的数据并最终在大约6小时内处理相同的24小时数据。革命对我来说。

如此多的企业系统都是OLTP而且数据没有被削减，但许多人的愿望是集群或横向扩展。这是对新技术或感知表现的反应吗？

今天的应用程序或我们的编程matras是否更适合横向扩展？我们/我们是否应该在将来始终考虑这一趋势？

Answer 1

因为扩大规模

• 最终会受到实际购买的盒子大小的限制
• 可能变得非常低成本，例如一台拥有128个内核和128G内存的机器比16个内核和8个内存每个内核要贵16个。
• 有些东西不能很好地扩展 - 比如IO读取操作。
• 通过向外扩展，如果您的架构正确，您还可以实现高可用性。一台128核128G的ram机非常昂贵，但是第二台多余的机器是敲诈勒索的。

并且在某种程度上，因为这就是谷歌所做的。

Answer 2

向外扩展最适合embarrassingly parallel个问题。这需要一些工作，但许多Web服务适合该类别（因此目前的流行度）。否则你会遇到Amdahl's law，这意味着要获得速度，你必须不扩大规模。我怀疑你遇到了这个问题。此外，IO绑定操作也倾向于很好地扩展，因为等待IO会增加可并行化的％。

Answer 3

Jeff Atwood撰写的博客文章Scaling Up vs. Scaling Out: Hidden Costs有一些值得考虑的问题，例如软件许可和电费。

Answer 4

毫不奇怪，这一切都取决于你的问题。如果您可以轻松地将其划分为不能进行多少通信的子问题，则向外扩展会提供微不足道的加速。例如，在1B网页中搜索单词可以通过一台机器搜索1B页面来完成，或者通过1M机器搜索每页1000页而不会显着降低效率（因此加速1,000,000倍）。这被称为“令人尴尬的平行”。

然而，其他算法确实需要子部件之间更密集的通信。您需要进行交叉分析的示例是通信通常可以淹没添加更多框的性能提升的完美示例。在这些情况下，您需要将通信保持在（更大的）盒子内，通过高速互连，而不是像（10-）Gig-E那样“常见”。

当然，这是一个相当理论的观点。其他因素，如I / O，可靠性，易编程（一个大型共享内存机器通常比集群更少的麻烦）也会产生很大的影响。

最后，由于使用廉价商品硬件扩展（通常是极端的）成本优势，集群/网格方法最近吸引了更多（算法）研究。这使得新的并行化方法得以开发，从而最大限度地减少了通信，从而在集群上做得更好 - 而常用知识用于指示这些类型的算法只能在大型铁机上有效运行......