Quindi, prima di investire molto tempo ed energia in un particolare cloud, è importante comprendere le caratteristiche generali delle prestazioni di MongoDB su quel cloud. Abbiamo cercato queste informazioni e non le abbiamo trovate, quindi abbiamo deciso di metterle insieme per te come parte della nostra serie di spettacoli.
Il Benchmark Rig
Abbiamo deciso di confrontare AWS, Azure e DigitalOcean per questo test. Sono stati scelti due diversi set di configurazioni. La tabella seguente riassume le configurazioni della macchina:
Fornitore | Regione | ScaleGrid Medium* (Core/RAM/Disco/IOPS Prov) | ScaleGrid Large* (Core/RAM/Disco/IOPS Prov) |
AWS | Stati Uniti orientali | 1/3,75 GB/60 GB/300 | 2/7,5 GB/120 GB/500 |
Azure | Stati Uniti orientali | 2/3,5 GB/60 GB/fino a 2000 | 4/7 GB/120 GB/fino a 4000 |
DigitalOcean | New York 3 | 2/4 GB/25 GB/SSD** | 4/8 GB/35 GB/SSD** |
* Fare riferimento qui in "MongoDB Hosting" per i dettagli sulle configurazioni della macchina.
** DigitalOcean ha collegato direttamente gli SSD.
I test delle prestazioni del benchmark sono stati eseguiti utilizzando YCSB Workload A (aggiornamento del carico di lavoro pesante). Abbiamo parlato di YCSB, della sua configurazione e dei suoi carichi di lavoro in un post molto dettagliato il mese scorso.
- Tutti i test di benchmark sono stati eseguiti in una configurazione standalone
- Per entrambe le configurazioni, Sono stati inseriti 5 milioni di record con vari livelli di carico del server (in base al numero di thread client).
- Per la configurazione Medium, il carico di lavoro A è stato eseguito con valori predefiniti (50% aggiornamento, 50% lettura) con numero di operazioni di 5 milioni a vari livelli di carico del server.
- Per la configurazione Large, il carico di lavoro A è stato eseguito con valori predefiniti (50% aggiornamento, 50% lettura) con numero di operazioni di 10 milioni a vari livelli di carico del server.
Risultati
Discuteremo i risultati in base alle prestazioni degli inserti e alle caratteristiche di velocità effettiva/latenza durante l'aggiornamento del carico di lavoro pesante.
Inserisci prestazioni
Istanze medie
Le caratteristiche di throughput/latenza per l'inserimento di record 5M sulla configurazione Medium:
Istanze Large
Le caratteristiche di throughput/latenza per l'inserimento di record 5M nella configurazione Large:
Aggiorna le prestazioni
Istanze medie
Le caratteristiche di throughput/latenza per 5M di operazioni di scrittura/aggiornamento sulla configurazione media:
Il test è stato eseguito con 32 thread solo per DigitalOcean. AWS e Azure erano fodere piatte a 16 thread. Tuttavia, DigitalOcean dà l'impressione di ridimensionare linearmente fino a 32 thread.
Istanze Large
Le caratteristiche di throughput/latenza per 10 milioni di operazioni di scrittura/aggiornamento sulla configurazione Large:
Analisi generale
- Come previsto, MongoDB su DigitalOcean ha caratteristiche di throughput/bassa latenza costantemente elevate e batte gli altri a mani basse durante la fase di inserimento, estraendo il massimo dalle sue unità SSD locali. È interessante notare che, anche se va molto bene durante la fase di lettura/aggiornamento, altri provider gli danno un po' di concorrenza, specialmente quando il carico del server aumenta. Chiaramente AWS/Azure stanno utilizzando uno storage di rete a velocità effettiva molto più elevata.
- Per ottenere prestazioni migliori dal disco AWS, l'utente può utilizzare dischi di dimensioni maggiori o allocare più IOPS con provisioning.
- Sulle istanze medie, MongoDB su Azure sembra funzionare molto meglio di AWS in modo coerente, sia durante le fasi di inserimento che di aggiornamento/lettura. Questo è stato sorprendente. L'hardware è abbastanza uniforme. Nelle istanze Large, le prestazioni di AWS sono nettamente migliori rispetto ad Azure.
- Sia AWS che Azure degradano abbastanza bene le latenze all'aumentare del carico. Azure sembra avere una curva di degrado della latenza piuttosto buona.
- Un altro aspetto interessante delle prestazioni di MongoDB su AWS è il modo in cui è "piatto":sembra degradarsi con grazia anche su scala logaritmica.
- In base ai numeri delle latenze, sembra che il punto debole, dal punto di vista del carico, per le istanze Medium e Large sia rispettivamente di 8 e 16 thread.