O MongoDB 3.0 é uma versão importante com melhorias há muito esperadas. A mais notável? O mecanismo de armazenamento opcional WiredTiger. Afinal de contas, o WiredTiger foi fundado pelas pessoas por trás do Berkeley DB. O MongoDB afirma que o desempenho de gravação do WiredTiger é de 7 a 10 vezes mais rápido do que o mecanismo de armazenamento padrão, o MMAP. Talvez seja, talvez não seja. De qualquer forma, o WiredTiger é melhor.
Então, o MongoDB diminuiu a diferença de desempenho em relação ao Couchbase Server?
Avalon Consulting aferido MongoDB e Couchbase Server para descobrir.
Cenário de referência
O cenário de benchmark exigia uma consistência forte; o MongoDB e o Couchbase Server garantem uma consistência forte por padrão, uma carga de trabalho equilibrada de 50% de leituras e 50% de atualizações para representar uma ampla gama de casos de uso e refletir o desempenho de leitura e gravação, um conjunto de trabalho que não cabia na memória e os dados a serem replicados para durabilidade e disponibilidade. Por fim, a latência de leitura e gravação não pode exceder 5 ms.
A Avalon Consulting implantou os dois bancos de dados com nove nós e nove servidores - um nó por servidor. Afinal, a implementação de três vezes o número de nós do MongoDB exigiria três vezes o número de assinaturas em um ambiente de produção com suporte.
- Forte consistência
- 50% Reads, 50% Updates
- Latência de leitura e gravação < 5ms
- 9 servidores, 9 nós - 1 servidor por nó
- Dados replicados (1 primário, 2 secundários)
- Dados > Memória *
- 300 milhões de documentos
- 286 GB primário (1x) + 572 GB secundário (2x)
- 90 GB de memória primária residente (32%)
* O conjunto de trabalho era todo o conjunto de dados.
Metodologia
Execute o benchmark no Amazon Web Services com o Yahoo! Cloud Serving Benchmark, uma estrutura de teste de desempenho de código aberto. Meça a taxa de transferência e a latência do percentil 95 enquanto aumenta o número de clientes simultâneos de 70 para 525 em incrementos de 35 até que a latência exceda 5 ms.
Resultados
- A latência do MongoDB excedeu 5ms com 245 clientes simultâneos a 72K.
- A taxa de transferência do Couchbase Server foi 2.x maior com 245 clientes simultâneos a 186K.
- A latência do Couchbase Server foi inferior a 5ms com 525 clientes simultâneos a 298K.
- A latência do Couchbase Server excedeu 5ms com 805 clientes simultâneos a 336K.
Conclusão
O problema com o MongoDB não era o mecanismo de armazenamento, embora o MMAP não o favorecesse, mas sim a fragmentação. E continua sendo. Não existe um mecanismo de armazenamento capaz de superar as limitações da fragmentação. A latência do MongoDB é aceitável, mas não por muito tempo. O WiredTiger ajudou com a latência, mas a taxa de transferência ainda era limitada por um banco de dados não projetado para concorrência. Supondo que o MongoDB seja dimensionado linearmente, seria necessário de 3 a 5 vezes o número de nós para ter um desempenho tão bom quanto o do Couchbase Server.
Você pode encontrar todos os detalhes no relatório.
Discutir sobre Notícias Hacker
