O MongoDB publicou um referência comparando o desempenho do MongoDB, do Apache Cassandra e do Couchbase Server em implantações de nó único para combater a um que publicamos comparando o desempenho do MongoDB e do Couchbase Server em implantações de 9 nós. O MongoDB tem um bom desempenho quando 1) está limitado a um único nó, 2) não armazena muitos dados e 3) não oferece suporte a muitos usuários. Esse é o ponto ideal para o MongoDB.
O MongoDB aumentou a conscientização sobre os bancos de dados NoSQL ao facilitar para os desenvolvedores a criação de uma prova de conceito ou de um pequeno aplicativo. No entanto, o MongoDB não consegue atender às rigorosas demandas das implementações de produção. O Couchbase Server, por outro lado, se destaca quando implantado como um banco de dados distribuído. Ele é dimensionado com facilidade para armazenar mais dados, oferecer suporte a mais usuários e fornecer maior rendimento e menor latência de acesso aos dados.
1) O benchmark de nó único não atende aos requisitos de escalabilidade
Se quiser ver o desempenho de um banco de dados com um pequeno conjunto de dados e poucos usuários, faça uma avaliação comparativa com uma implementação de nó único. Se quiser ver como será o desempenho em um ambiente de produção com um grande conjunto de dados e muitos usuários, faça uma avaliação comparativa com uma implementação em cluster.
É importante não apenas medir o desempenho em escala, mas também medir o desempenho enquanto atende aos requisitos da empresa. Por exemplo, alta disponibilidade.
Por que o MongoDB não comparou o desempenho de implementações distribuídas? Bem, é difícil para o MongoDB escalar além de um único nó.
Conforme observado pela InformationWeek (link), o dimensionamento não é linear. A adição de nós a um conjunto de réplicas do MongoDB não aumentará o desempenho de gravação porque cada gravação ainda será executada por um único nó - o nó primário. O mesmo se aplica aos shards do MongoDB: cada gravação ainda será executada pelos nós primários. Se houver três shards com três nós por shard, as gravações serão executadas pelos três nós primários.
2) O benchmark aplicou um cenário de gravação diferente para o Couchbase Server - não é uma comparação de igual para igual
O MongoDB executava uma operação por gravação - a atualização. No entanto, o MongoDB, inadvertidamente, fez com que o Couchbase Server executasse duas operações por gravação: uma leitura e uma atualização. Isso limitou o desempenho de gravação do Couchbase Server.
O MongoDB (com o WiredTiger) e o Couchbase Server utilizam o bloqueio em nível de documento. Se dois clientes atualizarem o mesmo documento ao mesmo tempo, um deles falhará e terá de tentar novamente a atualização. Esse é o caso do MongoDB e do Couchbase Server. Esse foi o cenário de gravação para o MongoDB nesse benchmark, mas não para o Couchbase Server.
Outro cenário de gravação é quando você precisa garantir que um cliente não possa atualizar um documento se ele tiver sido atualizado primeiro por um cliente diferente. Nesse cenário de gravação, o Couchbase Server oferece suporte à comparação e troca, enquanto o MongoDB recomenda a opção "Atualizar documento se atual" padrão. Esse era o cenário de gravação do Couchbase Server, mas não do MongoDB.
Por que o MongoDB faria com que o Couchbase Server executasse a comparação e a troca, mas não implementaria seu próprio padrão "Atualizar documento se atual"?
3) O benchmark utilizou um cliente Couchbase desatualizado, em vez do cliente atual
O MongoDB optou por usar uma biblioteca de cliente desatualizada lançada em 2013 para o Couchbase Server, o que limitou o desempenho do Couchbase Server. Lançamos uma nova biblioteca de clientes em setembro do ano passado, baseada em Netty e RxJava, seguida de versões menores em fevereiro e março.
Por que o MongoDB faria um benchmark do Couchbase Server com uma biblioteca de cliente desatualizada, mas faria um benchmark de si mesmo com sua biblioteca de cliente mais recente?
4) Durabilidade de nó único versus durabilidade de banco de dados distribuído
O objetivo da durabilidade é garantir que os dados não sejam perdidos quando um servidor falhar. Nesse benchmark, como ele foi realizado com implantações de nó único, os dados só podem ser duráveis quando são gravados no disco. Essa é a mesma limitação dos bancos de dados relacionais tradicionais.
Atualmente, os bancos de dados distribuídos contam com uma abordagem moderna de durabilidade que distribui o risco de perda de dados - eles replicam os dados em vários nós. O Couchbase Server é único no sentido de que, embora grave no disco como um banco de dados convencional, ele também aproveita a replicação mais rápida de memória para memória entre os nós. Os dados não são apenas duráveis, mas também altamente disponíveis. Eles podem ser replicados para nós em diferentes servidores, diferentes racks ou diferentes data centers.
Dito isso, se o MongoDB tivesse usado a biblioteca cliente mais recente, o desempenho de gravação do Couchbase Server teria sido pelo menos 10 vezes maior. A biblioteca cliente de dois anos atrás (1.1.8) esperava um mínimo de 100 ms antes de verificar se a gravação tinha sido gravada no disco. Em uma versão posterior (1.4.x), 10 ms. Na versão mais recente (2.x), 10µs. É por isso que você deve sempre fazer benchmark de bancos de dados com suas bibliotecas de clientes mais recentes, e não com as de dois anos atrás.
Implantações de nó único de regras do MongoDB
O MongoDB é adequado para uma prova de conceito ou um aplicativo pequeno que tenha um conjunto de dados pequeno e poucos usuários. O Couchbase Server é mais adequado para aplicativos com mais dados, mais usuários e requisitos de maior rendimento / menor latência - aqueles que se beneficiam de uma implementação distribuída. De fato, o Couchbase Server é frequentemente escolhido para alimentar aplicativos de missão crítica - pequenos ou grandes, de consumo ou empresariais, sociais ou de jogos - em que os bancos de dados relacionais tradicionais não conseguem fornecer a escalabilidade ou o desempenho necessários.
Discutir sobre Notícias Hacker
Para sua informação - Nós aferido MongoDB e Couchbase Server com implementações de 9 nós.
É marketing fazer um teste de desempenho em que o oponente sempre perderá, mas responder sem um teste de desempenho é um pouco como gritar \"Não, nós somos melhores! Nós prometemos! Não confie neles!"
Não tenho certeza se entendi. O que você quis dizer com responder sem um teste de desempenho?
Para fins de registro, o benchmark que o MongoDB promoveu (ao qual esta postagem do blog é uma resposta) foi executado para combater um benchmark anterior com clusters maiores (9 nós). O benchmark está disponível aqui: http://news.avalonconsult.com/…
O TLDR é que, para cargas de trabalho altamente simultâneas em um cluster de nove nós, o Couchbase Server lida com muito mais tráfego do que o MongoDB sem que os tempos de resposta diminuam. Isso é mais representativo das cargas de trabalho de produção com as quais nossos clientes se preocupam do que uma corrida de arrasto de um único nó.
Boas observações, Shane, mas me lembro de algo que Mike Stonebraker disse há muitos anos: \"... qualquer pessoa que projeta um benchmark está em uma situação \'no win\', ou seja, ela só pode ser criticada. Observadores externos encontrarão falhas no benchmark, que será artificial ou incompleto de uma forma ou de outra. Os fornecedores que tiverem um desempenho ruim no benchmark o criticarão sem piedade." O que seria realmente bom ver, na minha opinião, são benchmarks reais de clientes, em vez de apenas mais números do YCSB. Mas, como já trabalhei com benchmarks de desempenho de banco de dados no passado, conheço as dificuldades envolvidas.
Ralph, como isso foi enganoso?
Bem, a Bud Light continua a ser a cerveja mais popular do país. No entanto, ela não é uma boa cerveja.
Ralph, eu não trabalho para o Couchbase. Não posso comentar sobre o recente relatório de benchmark da Avalon, pois ainda não o li. Tenha cuidado com DB-engines.com - é uma classificação de popularidade que inclui menções/pesquisas na Web e não diz nada sobre números de instalação.
O YCSB atualiza um campo aleatório de cada dez durante as atualizações.
O MongoDB tem uma atualização que atualiza seletivamente um único campo (assim como a instrução SQL UPDATE), mas o Couchbase não tem isso.
Portanto, se você não ler o documento primeiro, substituirá os dez campos existentes por um novo (que é o que o benchmark da Thumbtack que você publicou no ano passado fez). Seu próprio benchmark Avalon leu o documento para substituir um dos campos por um novo valor, mas depois substituiu o documento existente, sobrescrevendo, portanto, todas as atualizações ocorridas nesse meio tempo. O uso do CAS é correto para preservar de fato todas as atualizações ocorridas. O CAS no MongoDB deve ser usado da mesma forma que no RDBMS somente quando for necessário atualizar um documento por um longo período (edição humana de um documento, por exemplo).
Para ser sincero, acho que o comando $set é útil quando o cenário de gravação inclui atualizações em diferentes campos do mesmo documento por vários clientes na mesma janela que não leem o documento primeiro.
Aparentemente, você não está familiarizado com o YCSB. A atualização fornece apenas um campo com um novo valor. Se você não leu o documento completo, como atualizá-lo no Couchbase?
Qual é o equivalente no Couchbase de UPDATE ycsbtable SET field6=newvalue WHERE primarykey=9999?
Você está certo. Como eu disse, acho que a operação $set é útil para aplicativos que atualizam campos específicos sem nunca ler o documento primeiro. Para outros aplicativos, esse pode ou não ser o caso. Por exemplo, perfis de usuário. Se um usuário quiser atualizar seu perfil, o aplicativo o lê primeiro. Ele é exibido e o usuário o edita. Com o Couchbase Server, o aplicativo pode modificar o documento que leu com base nas edições do usuário e, em seguida, atualizá-lo. Com o MongoDB, o aplicativo poderia usar o comando $set. Nesse contexto, o aplicativo leria o documento primeiro, seja ele do MongoDB ou do Couchbase Server.
Seu próprio benchmark fez duas operações: leu o documento e depois o substituiu - porque não há outra maneira de atualizar um campo. e seu próprio benchmark ignorou conflitos com outros threads.
seu código está errado.
https://github.com/kruthar/YCS…
Você não precisa ler o documento primeiro.
O objetivo do YCSB é medir o desempenho de uma operação de atualização. Em um aplicativo do mundo real, o documento já teria sido lido. Por exemplo, para preencher um formulário de edição. Você mede o desempenho da leitura para estimar quanto tempo levará para exibir o formulário. Quando o formulário é enviado, você modifica o documento e o atualiza. Você mede o desempenho da atualização para estimar quanto tempo levará para exibir a confirmação. Você pode criar um documento, gerar os dados para seus campos com o YCSB e realizar uma atualização com ele. Problema resolvido.
O benchmark Avalon não executou operações de comparação e troca para o MongoDB ou o Couchbase Server. Uma atualização parcial não oferece a mesma garantia que uma operação CAS. É uma forma opcional de controle de simultaneidade otimista que impede que um cliente atualize um documento se não tiver conhecimento de atualizações anteriores.
Por exemplo, a conta de um titular de cartão de crédito. Primeiro, um cliente verifica o campo de pagamento para ver se foi feito um. Não foi. Em seguida, enquanto o primeiro cliente está verificando o campo de pagamento, um segundo cliente atualiza o campo de pagamento para \"recebido\" porque um pagamento acabou de ser processado. Por fim, o primeiro cliente atualiza o campo de status para \"late\" porque não está ciente da atualização realizada pelo segundo cliente. Embora seja bom ter atualizações parciais, elas não resolveriam esse problema. Elas permitiriam que esses dois clientes atualizassem campos diferentes ao mesmo tempo, mas o resultado seria inválido. É por isso que temos o CAS.
A propósito, para o Couchbase Server 4.0 é assim:
http://docs.couchbase.com/deve…
UPDATE ycsbtable USE KEYS \"9999" SET field6 = \"newvalue\"
Pelo menos o benchmark deles incluía o código usado para que todos pudessem ver. Se você executou seu próprio benchmark, mostre seu código.
Ele deveria ter incluído a URL do repositório do GitHub. Aqui está ele:
https://github.com/kruthar/cou…