英文原文：
我们从MongoDirector.com得到的一个常见问题是MongoDB在各种公有云像AWS、Azure、Digital Ocean等的相对性能。每个云对于严重影响MongoDB性能的磁盘架构做了特定的选择。
因此在你花费大量的时间和精力到一个特定的云之前，理解MongoDB在该云上的整体性能特征很重要。我们查找这个信息并没有找到 -- 因此我们决定将它给你整合到一起作为我们的性能系列文章中的一部分。
基准平台
针对这次测试，我们决定比较AWS、Azure和Digital Ocean。我们选择了两个不同的配置集合。以下表格总结了机器配置：
| Provider |
Region |
MongoDirector Medium* |
MongoDirector Large* (Cores/RAM/Disk/Prov IOPS) |
| AWS |
US East |
1/3.75GB/60GB/300 |
2/7.5GB/120GB/500 |
| Azure |
East US |
2/3.5GB/60GB/upto 2000 |
4/7GB/120GB/upto 4000 |
| Digital Ocean |
New York 3 |
2/4GB/25GB/SSD** |
4/8GB/35GB/SSD** |
*参考这里 “MongoDB Hosting”下面关于机器配置的详细信息。
**Digital Ocean已直接附加上了SSD。
性能基准测试使用YCSB 负载 A（大量更新的负载）运行。在上个月我们在一篇非常详细的文章中谈论过YCSB、配置它和它的负载。
1. 所有的基准测试在一个单一配置下执行。
2. 对于所有配置，使用各种级别的服务器负载（基于大量的客户端线程）插入5百万条记录。
3. 对于中等配置，负载A使用各种级别的服务器负载，以5百万的操作总数，以默认值（50%更新，50%读取）执行。
4. 对于大型配置，负载A使用各种级别的服务器负载，以1千万的操作总数，以默认值（50%更新，50%读取）执行。
结果
我们将基于在大量更新负载下的插入性能和吞吐量/延时特征来讨论结果。
插入性能
中等实例
在中等配置下，对于插入5M记录的吞吐量/延时（Throughput/latency）特征：
大型实例
在大型配置下，插入5M记录的吞吐量/延时（Throughput/latency）特征：
更新性能
中等实例
在中等配置下，对于写入/更新5M操作时吞吐量/延时（Throughput/latency）特征：
这个测试只对于Digital Ocean使用32个线程运行。AWS和Azure在16个线程时是水平线。然而Digital Ocean给人的印象是直到32个线程才线性增长。
大型实例
在大型配置下，对于写入/更新10M操作的吞吐量/延时（Throughput/latency）特征：
整体分析
1. 如所期待的，Digital Ocean始终有着持续的高吞吐量/低延时特性，并在插入阶段打败了其他对手，从它本地SSD驱动获取最大性能。有趣的是，即使它在读取/更新阶段运行良好，其他提供商给了一点点竞争，尤其当服务器负载增加时。显然AWS/Azure是使用更高吞吐量的网络存储。
2. 为了从AWS磁盘获得更好的性能，用户可以使用更大的磁盘大小或者分配更高精度的IOPS。
3. 在中等实例，在插入和更新/读取阶段，Azure似乎一直比AWS做得更好。这是令人惊喜的。硬件是完全平等的。在大型实例，AWS性能明显比Azure更好。
4. AWS和Azure随着负载增加，延时降低都很好。Azure似乎有一个更好的延时降低曲线。
5. 另一个AWS性能有趣的方面是，它始终是多么的平：即使在对数刻度上也是优雅降低。
6. 基于延时数量，从负载的立场，对于中等和大型实例分别是8个和16个线程，看起来像是热点区域。
本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1739593 ，如需转载请自行联系原作者
