我正在建立一个新的可以迅速处理大量科学数据的云产品。迄今为止我们最大的客户数据集大约有3000个表，平均每个40到80MB，总计150GB。我们的目标是在10秒或更少的时间之内处理它们。每个表都可以被独立处理，因此我们着重并行化，即部署使用了1000个或更多的vCPU。棘手的部分是如何快速阅读那么多的数据到内存中。现在大约80%的计算时间是花在读取数据上的，这就导出了将要连载的三篇文章的重点是：云存储性能。作为解决这个问题的一部分，我评估了几种不同的方法：对象存储，数据库支持的存储和附加存储。每种方法我将在连载的不同部分中详细描述。
写这篇文章中途，谷歌碰巧发布了他们的多重云PerfKitBenchmarker。只要我能找到，这篇文章也将第一时间发布PerfKitBenchmarker的测评结果。
第一部分：对象存储
必须注意：基准是特定于应用程序的，也有少部分基于网络负载，邻近VM活动。当读到这里，考虑一下这些基准是否和你的应用程序有关，并且要理解这些结果可能不会反应到你的经历中。
对象存储（Amazon AWS 简单存储服务（S3），谷歌云存储（GCS），微软Azure存储）提供了一个简单的放/得到/头/表（PUT/GET/HEAD/LIST）接口，用来存储因为太大而不能放进数据库的任何类型的数据。它很具有吸引力，因为便宜、通过自动冗余和缩放来服务并发需求，提供安全保障。而缺点是具有延迟（为每一个文件建立一个新的HTTP连接）和受限制的网络吞吐量和可用性。
下载
我看了两个关键指标：用从相同地区相同供应商的虚拟机下载文件时，下载第一个字节的时间来测量延迟和吞吐量（表1）。在这个平面图上，百分位在X轴表示，指标在y轴表示。因此，你可以看到一些典型响应（例如平均，0.5）和最佳、最差的情况。
本质上Azure和AWS S3有相同的延迟，但是GCS平均高出三倍以上。然而，谷歌大约提供了Azure吞吐量的4倍和S3吞吐量的两倍。因此，GCS应该早于Azure完成下载大于1MB的文件和早于S3完成下载超过5 MB的文件。（强调完成下载，是因为如果你的应用程序可以处理流输入，且正在处理那些慢于已经下载的数据，那么S3和Azure将会在任何大小的文件面前都表现得更好。）
看到AWS S3那些不自然地速度为91 MB/s (732 Mbps)的平右尾了嘛？我敢打赌这是由AWS强制执行的最大的吞吐量。
网络吞吐量上限有问题
网络吞吐量是这些基准的核心，因此设计一个架构时必须考虑这些虚拟存储器的类型。在上面我给出了虚拟存储器类型的结果，以足够的网络带宽来精确测量存储的吞吐量而不是虚拟机的吞吐量。我会在以后的文章中加入网络吞吐量的细节，但是现在从表格二中可以看到GCE和Azure，1个vCPU就可以提供足够的吞吐量，而AWS EC2需要一个更大的机器 ，一个8 VCPU c4.2xlarge才足够，但我用了16个vCPU c4.4xlarge。
一些EC2实例类型有足够的网络吞吐量使S3的吞吐量遇到瓶颈，如果你用每一个vCPU下载一个文件（即通过VCPU计数分开网络带宽，这是一个简单却有效的视图；如表2右）。另一方面谷歌计算引擎有更高的网络吞吐量，例如大多数机器类型有比GCS更多的带宽，尽管GCS比S3拥有更高的吞吐量。Azure的低吞吐量还是被大多数类型接受得很好。
为了解释的更加彻底，我用GCE上和Azure上用16个vCPU和在AWS上用一个vCPU运行了储存基准。有趣的是，从存储的吞吐量上来看，谷歌和微软的较小虚拟机略高于较大虚拟机（未显示），这可能是因为有虚拟机在共享硬盘。AWS的m3.medium被限制在32.5MB/S。
GCS多区桶岩石
表1中的GCS结果表现为一个“多区”桶。S3没有多区桶；S3桶实际上相当于GCS地区桶。相反的是，多区桶允许不花费数据传输费用或复制成本从这组区域访问。（从另一个地区访问桶时，AWS每GB收取0.02美元。）如果你在多个地区有数据处理服务器的话，这是非常理想的。所有的两个美国数据中心中的吞吐量是非常棒的（图3）。我在服务条款中找不到任何有用的东西，但我怀疑多区桶因此也更容错。
上面链接中的文档显示区域桶将比多区桶提供更低的延迟和更高的吞吐量，所以我还测试了一个从所有四个us-central1计算发动机区域中来的us-central1地区桶（图4），和一个从三个us-east1区域中来的GCS us-east1地区桶（图5），看看我们是否能得到更快的吞吐量或提高GCS糟糕的延迟。
在区域桶中，不知道怎么回事延迟得到了增加。平均吞吐量和区域桶相比，或者相同，或者略高于它，虽然尾巴通常是更糟。真是奇怪。
上传
对于我的应用程序，我并不依赖于快速上传，但为了完整性，我这里还有一些基准测试结果（图6）。类似于下载，谷歌延迟较高，但具有更快的吞吐量，微软有最低的延迟和吞吐量，AWS是都处于中间。
对象存储处理并发性好
最终，谷歌的gsutil包括一个perfdiag命令。而且因为它建立在boto上，它实际上可以用于GCS和S3。这个工具包括一次读或写多个对象的能力，这就增加了一些新的信息（表3）。这表明，这些平台在规模上很好地服务于并发请求，我们将使用它们。 
得到的结论
亚马逊和Azure提供最低的延迟，而不管从上传量还是从下载量来说，谷歌提供了最高的吞吐量。这意味着AWS和Azure excel擅长小文件，而GCE擅长大文件，这也强调了对应用程序使用的数据的大小所做基准的重要性。
在设计高速数据处理系统时，必须考虑到AWS EC2网络吞吐量的很大的局限性。谷歌的独特多区桶可以降低成本来处理来自同一地区（如大陆）的多个数据中心的数据。
对象存储自动提供高聚合吞吐量。
最终，请注意，我只是从API访问方面来展示数据（AWS和谷歌是完全相同的博代码），我也观察到不同的客户在性能上的差异（特定供应商CLIs，node.js API 包，cURL’ing URLs，等等。）
原文出自：zachbjornson