Portanto, antes de investir muito tempo e energia em uma nuvem específica, é importante entender as características gerais de desempenho do MongoDB nessa nuvem. Procuramos essa informação e não a encontramos – então decidimos reuni-la para você como parte de nossa série de performances.
A Plataforma de Referência
Decidimos comparar AWS, Azure e DigitalOcean para este teste. Dois conjuntos diferentes de configurações foram escolhidos. A tabela abaixo resume as configurações da máquina:
| Provedor | Região | ScaleGrid Medium* (Cores/RAM/Disk/Prov IOPS) | ScaleGrid Large* (Núcleos/RAM/Disco/Prov IOPS) |
| AWS | Leste dos EUA | 1/3,75 GB/60 GB/300 | 2/7,5 GB/120 GB/500 |
| Azure | Leste dos EUA | 2/3,5 GB/60 GB/até 2.000 | 4/7 GB/120 GB/até 4.000 |
| DigitalOcean | Nova York 3 | 2/4 GB/25 GB/SSD** | 4/8 GB/35 GB/SSD** |
* Consulte aqui em "MongoDB Hosting" para ver os detalhes das configurações da máquina.
** A DigitalOcean tem SSDs diretamente conectados.
Os testes de desempenho de referência foram executados usando a carga de trabalho A do YCSB (atualizar carga de trabalho pesada). Falamos sobre o YCSB, configurando-o e suas cargas de trabalho em um post bem detalhado no mês passado.
- Todos os testes de benchmark foram realizados em uma configuração independente
- Para ambas as configurações, 5 milhões de registros foram inseridos com vários níveis de carga do servidor (com base no número de threads do cliente).
- Para a configuração média, a carga de trabalho A foi executada com valores padrão (50% de atualização, 50% de leitura) com contagem de operações de 5 milhões em vários níveis de carga do servidor.
- Para a configuração Grande, a carga de trabalho A foi executada com valores padrão (50% de atualização, 50% de leitura) com contagem de operações de 10 milhões em vários níveis de carga do servidor.
Resultados
Discutiremos os resultados com base no desempenho da inserção e nas características de taxa de transferência/latência sob carga de trabalho pesada de atualização.
Inserir desempenho
Instâncias médias
As características de taxa de transferência/latência para inserção de registro de 5 milhões na configuração média:
Instâncias grandes
As características de taxa de transferência/latência para inserção de registro de 5 milhões na configuração grande:
Atualizar desempenho
Instâncias médias
As características de taxa de transferência/latência para operações de gravação/atualização de 5 milhões na configuração média:
O teste foi executado com 32 threads apenas para a DigitalOcean. AWS e Azure eram forros planos em 16 threads. No entanto, o DigitalOcean dá a impressão de escalar linearmente até 32 threads.
Instâncias grandes
As características de taxa de transferência/latência para operações de gravação/atualização de 10 milhões na configuração grande:
Análise geral
- Como esperado, o MongoDB na DigitalOcean tem características de alta taxa de transferência/baixa latência consistentemente e supera os outros durante a fase de inserção, extraindo o máximo de suco de suas unidades SSD locais. Curiosamente, embora corra muito bem durante a fase de leitura/atualização, outros provedores oferecem um pouco de concorrência, especialmente quando a carga do servidor aumenta. Claramente, a AWS/Azure está usando armazenamento em rede com taxa de transferência muito maior.
- Para obter melhor desempenho do disco da AWS, o usuário pode usar tamanhos de disco maiores ou alocar mais IOPS provisionadas.
- Em instâncias médias, o MongoDB no Azure parece se sair muito melhor do que o AWS de forma consistente, tanto durante as fases de inserção quanto de atualização/leitura. Isso foi surpreendente. O hardware é bastante equilibrado. Em instâncias grandes, o desempenho da AWS é significativamente melhor que o Azure.
- A AWS e o Azure degradam muito bem as latências à medida que a carga aumenta. O Azure parece ter uma curva de degradação de latência bastante boa.
- Outro aspecto interessante do desempenho do MongoDB na AWS é como ele é “flat-line”:parece se degradar graciosamente mesmo em uma escala de log.
- Com base nos números de latências, parece que o ponto ideal, do ponto de vista de carregamento, para instâncias médias e grandes é de 8 e 16 threads, respectivamente.
