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

Question

作为一名程序员,我每隔几年就会做出革命性的发现.我要么在曲线之前,要么在此阶段后面约为π.我学到的一个难点是,缩小OUT并不总是更好,通常最大的性能提升是在我们重新组合和扩大规模时.

你有什么理由扩大规模？价格,性能,愿景,预计用量？如果是这样,这对你有什么影响？

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

如此多的企业系统都是OLTP而且数据没有经过分析,但许多人的愿望是集群或横向扩展.这是对新技术或感知表现的反应吗？

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

Answer 1

因为扩大规模

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

而且在某种程度上,因为这就是谷歌所做的.

Answer 2

扩展是最令人尴尬的并行问题.这需要一些工作,但许多Web服务适合该类别(因此目前的流行度).否则你会遇到Amdahl定律,这意味着要获得速度,你必须扩大规模.我怀疑你遇到了这个问题.此外,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、可靠性、易于编程（一台大型共享内存机器通常比集群少得多）也会产生很大的影响。

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