可伸缩性 – 未扩展与-out的原因？
发布时间：2020-12-16 19:21:39 所属栏目：安全 来源：网络整理
导读：作为程序员,我每隔几年就会做出革命性的发现.我要么在曲线之前,要么在相位之后约为π.我学到的一个难点是,缩小OUT并不总是更好,通常最大的性能提升是在我们重新组合和扩大规模时. 你有什么理由要扩大规模？价格,性能,愿景,预计用量？如果是这样,这对你有什么
|
作为程序员,我每隔几年就会做出革命性的发现.我要么在曲线之前,要么在相位之后约为π.我学到的一个难点是,缩小OUT并不总是更好,通常最大的性能提升是在我们重新组合和扩大规模时.
你有什么理由要扩大规模？价格,性能,愿景,预计用量？如果是这样,这对你有什么作用？ 我们曾经扩展到数百个节点,这些节点将序列化并将必要的数据缓存到每个节点,并在记录上运行数学过程.需要(交叉)分析许多,数十亿条记录.采用横向扩展是完美的业务和技术案例.我们一直在优化,直到我们在26小时挂钟处理了大约24小时的数据.真的很长一点,我们租用了一个巨大的(当时)IBM pSeries,将Oracle Enterprise放在其上,索引我们的数据并最终在大约6小时内处理相同的24小时数据.革命对我来说. 如此多的企业系统都是OLTP,而且数据没有经过分析,但许多人的愿望是集群或横向扩展.这是对新技术或感知表现的反应吗？ 今天的应用程序或我们的编程matras是否更适合横向扩展？我们/将来是否应该始终考虑这一趋势？ 解决方法
毫不奇怪,这一切都取决于你的问题.如果您可以轻松地将其划分为不能进行多少通信的子问题,则扩展会提供微不足道的加速.例如,在1B网页中搜索单词可以通过一台机器搜索1B页面来完成,或者通过1M机器搜索每页1000页而不会显着降低效率(因此加速1,000,000倍).这被称为“令人尴尬的平行”.
然而,其他算法确实需要子部件之间更密集的通信.您需要进行交叉分析的示例是通信通常可以淹没添加更多框的性能提升的完美示例.在这些情况下,您需要将通信保持在(更大的)盒子内,通过高速互连,而不是像(10-)Gig-E那样“共同”. 当然,这是一个相当理论的观点.其他因素,如I / O,可靠性,易编程(一个大型共享内存机器通常比集群更少的麻烦)也可以产生很大的影响. 最后,由于使用廉价商品硬件扩展(通常是极端的)成本优势,集群/网格方法最近吸引了更多(算法)研究.这使得新的并行化方法已经开发出来,可以最大限度地减少通信,从而在集群上做得更好 – 而常用的知识用于指示这些类型的算法只能在大型铁机上有效运行…… （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |