比較MongoDB在公有云上的性能：AWS、Azure和Digital Ocean
英文原文：
我們從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個線程，看起來像是熱點區域。