![]() |
1
8
[提前向小组致歉,因为他们将部分响应空间用于类似元的事情]
从行动中,拉尔斯·D:
拉尔斯,
(1) 非实际问题:一个[显然]主要是计算过程(没有提及分布式/复制存储结构),高度并行(1500台服务器),进入50毫秒大小的任务,这些任务共同提供亚秒响应(?供人类消费?)。然而,这一过程只需要(每天……?)几次。
别再回头看了!
此外,我很乐意接受你的暗示(本页其他人暗示不否决),删除我的回复,如果你发现这样做有助于促进更好的回复。 --最初的答复-- 警告: 并不是所有的过程或数学计算都可以很容易地分割成单独的部分,然后可以并行运行。。。 也许你可以在网上查看维基百科的条目 Cloud Computing 理解云计算并不是唯一允许并行计算的架构。 如果你的过程/计算可以有效地分成可并行的部分,也许你可以研究 Hadoop ,或 MapReduce ,以便对这些并行过程有一个大致的了解。此外,(我相信使用相同或类似的算法),也存在商业上可用的框架,例如 EC2 从…起 amazon . 然而,请注意,上述系统并不特别适合快速响应时间。它们在长达一小时(然后是一些)的数据/数字处理和类似的工作中表现得更好,而不是像你希望并行化的那种长达一分钟的计算,因此它能在1/10秒内提供结果。 上述框架是通用的,从某种意义上说,它们可以运行大多数任何性质的流程(同样,这些流程至少可以部分分块),但也有针对特定应用程序的各种服务,如搜索或DNA匹配等。搜索应用程序的响应时间特别短(例如,比照谷歌),顺便说一句,这在一定程度上与这样一个事实有关,即这样的工作可以非常容易、快速地分块进行并行处理。 |
![]() |
2
5
抱歉,你期望太高了。 问题是,您只需要支付处理能力的费用。然而,您的主要限制是延迟,您希望这是免费的。那是行不通的。你需要弄清楚你的延迟预算是多少。 仅仅是从多个计算服务器聚合数据,每个级别需要几毫秒的时间。这里将有一个高斯分布,因此对于1500台服务器,最慢的服务器将在3分钟后响应。因为需要一个层次结构,第二层有40台服务器,在这里您将再次等待最慢的服务器。 互联网上的往返也迅速增加;这也需要20到30毫秒的延迟预算。 另一个考虑因素是,这些假设的服务器将花费大量空闲时间。这意味着它们已经通电,既能用电,又不能产生收入。任何一个有这么多空闲服务器的派对都会关掉它们,或者至少在睡眠模式下只是为了省电。 |
![]() |
3
2
MapReduce不是解决方案!Map Reduce在Google、Yahoo和Microsoft中用于从海量数据(整个Web!)中创建索引他们的磁盘上有。这项任务非常艰巨,Map Reduce的设计目的是让它在几小时内完成,而不是几年,但启动Map Reduce的主控制器已经是2秒了,所以对于你的100毫秒来说,这不是一个选项。 现在,通过Hadoop,您可以从分布式文件系统中获得优势。它可能允许您将任务分发到靠近数据物理位置的位置,但仅此而已。顺便说一句:设置和管理Hadoop分布式文件系统意味着控制1500台服务器! 坦率地说,在你的预算中,我没有看到任何“云”服务可以让你租用1500台服务器。唯一可行的解决方案是在Sun和IBM提供的网格计算解决方案上租用时间,但他们希望您按照我所知的时间投入数小时的CPU。 顺便说一句:在Amazon EC2上,你需要在几分钟内安装一台新服务器,至少需要保留一个小时! 希望你能找到解决办法! |
![]() |
4
2
我不明白你为什么要这么做,只是因为“我们的用户界面通常旨在在不到100毫秒的时间内完成所有操作,这一标准也应该适用于此”。 首先,“瞄准”!='不得不承认,这是一个指导方针,为什么你会因为这个而引入这些大规模的过程。考虑1500毫秒x=150秒秒=2.5分钟。将2.5分钟缩短为几秒钟是一个更健康的目标。还有一个地方可以放“我们正在处理您的请求”和一个动画。 所以我的答案是——发布一个有合理目标的问题的修改版本:几秒钟,30-50台服务器。我不知道这个问题的答案,但是我觉得这个问题是错的。甚至可能是6-8台多处理器服务器。 |
![]() |
5
1
谷歌通过拥有一个庞大的小型Linux服务器群来实现这一点,这些服务器联网在一起。他们使用的是一种Linux风格,他们为自己的搜索算法定制了这种风格。成本包括软件开发和廉价PC。 |
![]() |
6
1
看起来,你确实期望将工作分配到多台计算机上的速度至少提高1000倍。也许可以。不过,您的延迟要求似乎很棘手。 您是否考虑过分配工作时固有的延迟?基本上,这些计算机必须靠得相当近,才能避免遇到光速问题。此外,机器所在的数据中心也必须非常靠近您的客户,这样您就可以在不到100毫秒的时间内将请求发送给他们并返回。至少在同一个大陆上。 还要注意,任何额外的延迟都需要系统中有更多的节点。将50%的可用计算时间浪费在延迟或任何其他无法并行化的情况下,需要将并行部分的计算能力提高一倍,以跟上速度。 我怀疑云计算系统是否最适合解决这样的问题。至少我的印象是,云计算的支持者宁愿不告诉你机器在哪里。当然,我还没有看到任何延迟术语 SLAs 那是 available. |
![]() |
7
1
你有相互冲突的要求。您对100ms延迟的要求与您只偶尔运行程序的愿望直接不符。 您在问题中提到的谷歌搜索类型方法的一个特点是,集群的延迟取决于 最慢的 节点。因此,您可以让1499台计算机在不到100毫秒的时间内做出响应,但如果一台计算机需要更长的时间,比如1s——无论是因为重试,还是因为需要向您的应用程序发送页面,或者是连接不良——您的整个集群都需要1s才能生成响应。这种方法是不可避免的。 实现您所寻求的延迟类型的唯一方法是让集群中的所有计算机始终将您的程序以及它所需的所有数据加载到RAM中。必须从磁盘加载程序,甚至必须从磁盘将其分页,这将需要超过100毫秒的时间。一旦你的一台服务器必须点击磁盘,你的100毫秒延迟要求就结束了。 在共享服务器环境中,考虑到您的成本限制,这就是我们在这里讨论的,几乎可以肯定的是,您的1500台服务器中至少有一台需要点击磁盘才能激活您的应用程序。 所以你要么要花足够的钱说服别人让你的程序始终处于活动状态并在内存中,要么就必须放宽延迟要求。 |
![]() |
8
1
两种思路: a) 如果这些限制真的、绝对的、真正地建立在常识基础上,并且以你在第n次编辑中提出的方式可行,那么预先应用的数据似乎并不庞大。那么,用存储来换取时间上的预计算怎么样。桌子有多大?太字节太便宜了! b) 这听起来很像是雇主/客户的要求,在常识上没有充分的依据。(根据我的经验) 假设一个核的计算时间为15分钟。我猜你是这么说的。 只要花费合理的钱,你就可以买到一个有16个合适的、32个超线程内核和48 GB内存的系统。 这将使我们进入30秒的范围。 添加十几TB的存储和一些预计算。 也许在那里可以达到10倍的增长。 3秒。 3秒太慢了吗?如果是,为什么? |
![]() |
9
0
听起来你需要使用这样的算法 MapReduce: Simplified Data Processing on Large Clusters Wiki . |
![]() |
10
0
退房 并行计算 以及这篇维基百科文章中的相关文章——“并发编程语言、库、API和并行编程模型都是为并行计算机编程而创建的。”。。。 http://en.wikipedia.org/wiki/Parallel_computing |
![]() |
11
0
虽然云计算是一个很酷的新概念,但你的场景听起来更像是需要一个 cluster ,即如何使用并行性在较短时间内解决问题。 我的解决方案是:
|
![]() |
12
0
你所要求的并不存在,原因很简单,这样做需要1500台机器上有1500个应用程序实例(可能有大量内存数据)空闲,这会消耗所有机器上的资源。现有的云计算产品都没有这样的基础。App Engine和Azure等平台无法让你直接控制应用程序的分发方式,而亚马逊EC2等平台则按实例小时收费,每天的费用超过2000美元。 |
![]() |
drainzerrr · Go锁定结构的一部分 6 年前 |
![]() |
Azim · 使用java 8并行处理图像 6 年前 |
|
user8005765 · Karatsuba-多项式与CUDA相乘 6 年前 |
![]() |
Adi · 并行读取大型XSLT字符串 6 年前 |
![]() |
A.J · 同时运行两个python文件 6 年前 |
![]() |
Kristofer · 当索引设置为私有时,如何确保访问缓冲区是私有的 6 年前 |