O desempenho ainda é um problema para o MongoDB?
A Avalon fez um benchmarking do Couchbase Server e do MongoDB no ano passado, e muita coisa mudou desde então. O Couchbase Server 4.0 introduziu uma linguagem de consulta baseada em SQL, a N1QL. O Couchbase Server 4.1 adicionou instruções preparadas e índices de cobertura, e o desempenho da consulta melhorou.
O Couchbase Server 4.5 adicionou índices otimizados para memória, indexação de matriz e junções de índices, além de melhorias no armazenamento (gravações circulares) e na consistência (read-your-own-writes). O Couchbase Server tem um mecanismo de consulta mais avançado, mas, com esses aprimoramentos, será que ele é o mais rápido?
Desta vez, o Avalon avaliou o desempenho de leitura/gravação e de consulta.
Os resultados de leitura/gravação não devem ser uma surpresa.
O Couchbase Server tem uma taxa de transferência de leitura/gravação 6 vezes maior do que o MongoDB? Como? Por quê?
Tudo se resume a arquitetura, utilização de recursos e eficiência.
Quando se trata de desempenho de gravação, o MongoDB sofre com uma arquitetura mestre/escravo herdada. Com um nó primário e um secundário em execução em cada servidor, e com gravações limitadas aos nós primários, somente metade dos recursos do servidor pode ser utilizada para gravações.
Quando se trata de desempenho de leitura, o Couchbase Server se beneficia de uma arquitetura centrada na memória. Embora grave todos os dados no disco, ele mantém o maior número possível de documentos em um cache de objeto gerenciado, o que é muito mais eficiente do que armazenar em cache blocos de dados de arquivo.
Os resultados da consulta podem ser surpreendentes.
O Couchbase Server tem uma taxa de transferência de consulta 3x maior que o MongoDB? Como? Por quê?
Como eu disse, tudo se resume a arquitetura, utilização de recursos e eficiência.
O MongoDB executa cada consulta em cada nó porque depende de índices locais - cada nó contém apenas uma parte do índice. Como resultado, o desempenho da consulta é limitado ao de um único nó. Por exemplo, se um único nó pode executar 7.500 consultas por segundo, adicionar mais nós não ajuda - cada nó ainda precisa executar as mesmas 7.500 consultas por segundo.
O Couchbase Server se beneficia de índices globais otimizados para memória, bem como de serviços independentes para leitura e gravação de dados, indexação e consulta.
Quando se trata de latência de varredura, o Couchbase Server pode aproveitar os índices secundários globais (GSI), em que o serviço de índice mantém um índice completo (e não uma parte dele). Isso permite que o serviço de consulta identifique os documentos a serem retornados com uma única varredura de índice, limitando as solicitações de busca apenas aos nós que contêm um ou mais dos documentos a serem retornados. Com o armazenamento otimizado para memória, o índice inteiro não é armazenado apenas na memória, mas também em uma lista de saltos sem bloqueio, o que é muito mais eficiente do que uma árvore B, uma estrutura de dados otimizada para disco.
Quando se trata de latência de inserção, o Couchbase Server se beneficia do isolamento. Os serviços de índice e de dados, estejam eles em execução em nós diferentes ou não, são isolados com índices sendo atualizados de forma assíncrona. Como resultado, enquanto a latência de inserção do MongoDB foi severamente afetada pelas consultas, a latência de inserção do Couchbase Server não foi.
Você pode encontrar todos os detalhes na seção relatório completo.
Se (usuários > 100) retornar "Couchbase Server"; caso contrário, retornar "MongoDB";
