É oficial. Os principais fornecedores de bancos de dados NoSQL - DataStax, MongoDB e Couchbase - estão brigados.
Nos últimos 30 dias,
- O Couchbase publicou um referência em 19 de março.
- O MongoDB respondeu publicando um referência em 31 de março.
- A DataStax respondeu publicando um referência em 13 de abril.
É importante realizar benchmarks competitivos. Quando patrocinamos um benchmark, ficamos sabendo qual é o desempenho do nosso banco de dados em um cenário específico com uma configuração específica. Quando a concorrência patrocina um benchmark, ficamos sabendo qual é o desempenho dele em um cenário diferente com uma configuração diferente. Dito isso, todos nós devemos à comunidade garantir que os benchmarks representem cenários do mundo real com configurações adequadas. E, para isso, precisamos ser transparentes.
Embora estejamos felizes pelo fato de a DataStax ter reconhecido a importância dos benchmarks, esse benchmark não fornece uma representação precisa do desempenho do Couchbase Server. A falta de transparência desse benchmark levanta uma série de questões não respondidas que criam incerteza sobre sua validade.
1) Por que o cache foi configurado incorretamente para o Couchbase Server?
O Couchbase Server oferece suporte a duas opções de otimização de cache - ejeção de "valor", a opção padrão, e ejeção "completa". Esse parâmetro de comparação ativou a otimização de cache incorreta, ejeção "completa", para esse cenário, limitando significativamente o desempenho de leitura do Couchbase Server.
O Couchbase Server armazena em cache os metadados e o valor quando um documento é inserido.
Quando a ejeção de "valor" estiver ativada e não houver memória suficiente, o Couchbase Server ejetará o valor de outros documentos, mas manterá seus metadados.
Quando a ejeção "completa" estiver ativada e não houver memória suficiente, o Couchbase Server ejetará os metadados e o valor de outros documentos.
Recomendamos a ejeção de "valor" para o cenário desse benchmark porque havia memória suficiente para armazenar em cache os metadados de todos os 500 milhões de documentos. Isso teria melhorado o desempenho da leitura, eliminando a E/S desnecessária do disco para determinar onde os dados estavam armazenados no disco.
O Couchbase Server e o MongoDB são capazes de melhorar o desempenho de leitura. Por que o desempenho de leitura deles foi tão ruim nesse benchmark?
Os números não batem. Como o Couchbase Server teve um desempenho pior com uma porcentagem maior de dados na memória e um tamanho de documento muito menor? O tamanho dos documentos no benchmark do Couchbase era de 1K. No benchmark do DataStax, era de 100 bytes.
Desempenho do servidor Couchbase em
(1) Benchmark do Couchbase e (2) Benchmark do DataStax
| Referência | Operações por segundo por núcleo | Dados por nó | Memória por nó | Nós | Núcleos por nó |
| 1 patrocinado pelo Couchbase | 4,600 | 32 GB | 10 GB | 9 | 8 |
| 2 Patrocinado pela DataStax | 375 | 50 GB | 23 GB | 8 | 4 |
2) Por que o cliente YCSB do Couchbase Server foi baseado em uma biblioteca de cliente desatualizada?
O repositório do GitHub mostra que o cliente YCSB para o Couchbase Server usado nesse benchmark é baseado em uma biblioteca de cliente antiga para o Couchbase Server 2.5. Ele deveria ter sido baseado na biblioteca de clientes atual do Couchbase Server 3.0. O cliente antigo esperava um mínimo de 10 milissegundos antes de verificar se os dados foram gravados no disco. O cliente atual espera apenas 10 microssegundos.
O desempenho de gravação do Couchbase Server teria sido melhor com um cliente de segunda geração.
3) Por que a replicação foi desativada para o Cassandra?
A DataStax configurou o Cassandra sem replicação - isso não é recomendado no mundo real. É um nível de risco inaceitável. Se um nó falhar, os dados ficarão indisponíveis. A DataStax desativou a replicação para melhorar o desempenho de gravação do Cassandra?
O Cassandra é eventualmente consistente por padrão. O Couchbase Server e o MongoDB impõem uma consistência forte por padrão. Se o Cassandra fosse configurado para replicar dados, haveria problemas com a consistência. Se a consistência forte fosse configurada por meio de quóruns, haveria um impacto negativo no desempenho.
O Couchbase Server replica os dados para dois nós por padrão - eles são armazenados no proprietário e em duas réplicas. O MongoDB replica os dados em vários nós - eles são armazenados no nó primário e nos nós secundários. Esse benchmark não informa o número de réplicas configuradas para o Couchbase Server nem o número de nós secundários implantados para o MongoDB. Nós simplesmente não sabemos, e é por isso que a transparência é importante. Não conseguimos reproduzir os testes de desempenho sem isso.
4) As gravações do Cassandra eram duráveis?
O Couchbase Server e o MongoDB foram configurados para gravações duráveis. Não está claro se o Cassandra foi ou não configurado para gravações duráveis. Caso contrário, o Cassandra se beneficiaria de uma vantagem significativa de desempenho em detrimento da durabilidade. Por padrão, as gravações do Cassandra não são duráveis.
5) Por que a replicação não foi usada para obter durabilidade?
Recomendamos ativar a replicação para obter durabilidade. Ao replicar os dados para vários nós, os dados são duráveis porque não serão perdidos se um nó falhar. Nesse benchmark, os dados são armazenados em um único nó, portanto, não são duráveis a menos que sejam gravados no disco. No entanto, um banco de dados distribuído, como o Cassandra ou o Couchbase Server, pode armazenar os dados em vários nós... e é isso que recomendamos.
Crédito extra: Defenda o MongoDB
É isso mesmo, estamos defendendo o MongoDB.
Primeiro, ficamos surpresos com o fato de a DataStax ter configurado o MongoDB com particionamento baseado em intervalo, sabendo que as chaves eram incrementais ("user1", "user2", "user3"). MongoDB 2.4 apresentado particionamento baseado em hash.
Em segundo lugar, ficamos surpresos com o fato de a DataStax ter publicado um benchmark que inclui um candidato a versão do MongoDB. Acreditamos que os benchmarks devem se limitar a versões geralmente disponíveis. Eles não devem incluir versões milestone, candidate, alpha ou beta. O Couchbase referência inclui o MongoDB 3.0 porque esperamos pela versão GA.
Terceiro, não acreditamos que isso represente bem o desempenho de leitura do MongoDB. Afinal de contas, o MongoDB executou até 74 mil operações por segundo no benchmark do Couchbase. Isso é muito mais do que as 2 mil operações por segundo demonstradas nesse benchmark. Não sabemos o motivo, e isso se deve à falta de transparência desse benchmark.
Conclusão: Para serem úteis, os benchmarks precisam ser transparentes e configurados adequadamente
É importante para os fornecedores, os clientes em potencial e a comunidade que os benchmarks sejam facilmente reproduzidos. Para que isso aconteça, os benchmarks publicados devem incluir toda a configuração do cliente e toda a configuração do banco de dados. No entanto, seria difícil para nós reproduzir esse benchmark devido à falta de transparência.
Dito isso, é difícil fazer benchmark de bancos de dados. Não basta saber como configurar seu próprio banco de dados, é preciso saber como configurar outros bancos de dados também. Depois de fazer o benchmark do Cassandra, aprendemos a configurá-lo melhor nos benchmarks subsequentes. Esperamos que a DataStax tenha aprendido a configurar melhor o Couchbase Server.
Se necessário, teremos o maior prazer em ajudar com seu próximo benchmark.
Discutir sobre Notícias Hacker
