Så innan du investerar mycket tid och energi i ett visst moln är det viktigt att förstå de övergripande prestandaegenskaperna hos MongoDB på det molnet. Vi letade efter den här informationen och hittade den inte – så vi bestämde oss för att sätta ihop den åt dig som en del av vår föreställningsserie.
The Benchmark Rig
Vi bestämde oss för att jämföra AWS, Azure och DigitalOcean för detta test. Två olika uppsättningar av konfigurationer valdes. Tabellen nedan sammanfattar maskinkonfigurationerna:
Leverantör | Region | ScaleGrid Medium* (Cores/RAM/Disk/Prov IOPS) | ScaleGrid Large* (Cores/RAM/Disk/Prov IOPS) |
AWS | Östra USA | 1/3,75 GB/60 GB/300 | 2/7,5 GB/120 GB/500 |
Azure | Östra USA | 2/3,5 GB/60 GB/upp till 2000 | 4/7GB/120GB/upp till 4000 |
DigitalOcean | New York 3 | 2/4GB/25GB/SSD** | 4/8GB/35GB/SSD** |
* Se här under “MongoDB Hosting” för information om maskinkonfigurationer.
** DigitalOcean har direktanslutna SSD-enheter.
Benchmarkprestandatesterna kördes med YCSB Workload A (uppdatera tung arbetsbelastning). Vi pratade om YCSB, inställningen och dess arbetsbelastningar i ett mycket detaljerat inlägg förra månaden.
- Alla benchmark-tester utfördes i en fristående konfiguration
- För båda konfigurationerna, 5 miljoner poster infogades med olika nivåer av serverbelastning (baserat på antalet klienttrådar).
- För konfigurationen Medium exekverades Workload A med standardvärden (50 % uppdatering, 50 % läst) med operationsantal på 5 miljoner på olika nivåer av serverbelastning.
- För den stora konfigurationen kördes Workload A med standardvärden (50 % uppdatering, 50 % läs) med operationsantal på 10 miljoner på olika nivåer av serverbelastning.
Resultat
Vi kommer att diskutera resultat baserat på infogningsprestanda och egenskaper för genomströmning/fördröjning under uppdatering av tung arbetsbelastning.
Infoga prestanda
Medelstora instanser
Genomströmnings-/latensegenskaperna för infogning av 5M-poster på Medium-konfigurationen:
Stora instanser
Genomströmnings-/latensegenskaperna för infogning av 5M-poster i Large-konfigurationen:
Uppdatera prestanda
Medelstora instanser
Genomströmnings-/latensegenskaperna för 5M skriv-/uppdateringsoperationer på mediumkonfigurationen:
Testet kördes med 32 trådar endast för DigitalOcean. AWS och Azure var platta foder med 16 trådar. DigitalOcean ger dock intrycket av att skala linjärt till 32 trådar.
Stora instanser
Genomströmnings-/fördröjningsegenskaperna för 10 miljoner skriv-/uppdateringsoperationer på den stora konfigurationen:
Övergripande analys
- Som förväntat har MongoDB på DigitalOcean konsekvent egenskaper med hög genomströmning/låg latens genomgående och slår de andra helt enkelt under insättningsfasen och extraherar maximal juice ur sina lokala SSD-enheter. Intressant nog, även om det går väldigt bra under läs-/uppdateringsfasen, ger andra leverantörer det en hel del konkurrens, speciellt när serverbelastningen ökar. Uppenbarligen använder AWS/Azure nätverkslagring med mycket högre genomströmning.
- För att få bättre prestanda från AWS-disken kan användaren använda större diskstorlekar eller allokera mer provisionerad IOPS.
- På Medium-instanser verkar MongoDB på Azure klara sig mycket bättre än AWS konsekvent, både under insättnings- och sedan uppdaterings-/läsfaserna. Detta var överraskande. Hårdvaran är ganska jämnt matchad. På stora instanser är AWS-prestanda markant bättre än Azure.
- Både AWS och Azure försämras i latenser ganska bra när belastningen ökar. Azure verkar ha en ganska bra fördröjningskurva för latens.
- En annan intressant aspekt av MongoDB på AWS-prestanda genomgående är hur "platt-lined" den är:verkar försämras graciöst även på en log-skala.
- Baserat på latenssiffror, ser det ut som sweet spot, ur belastningssynpunkt, för Medium och Large-instanser 8 respektive 16 trådar.