Vamos analisar o NoSQL Benchmark do outono de 2014.
Apache Cassandra / DataStax Enterprise. MongoDB. Servidor Couchbase.
Vá.
Hardware
| Servidor (8) | Cliente (32) | |
| Processador | Intel Xeon E5-2620 V2 (2) | Intel Core i5-4440 |
| Memória | 64 GB | 8 GB |
| Armazenamento (dados) | SSD SATA 6Gb/s de 100 GB (2) | |
| Armazenamento (SO) | SSD SATA 6Gb/s de 80 GB |
Rede: 96Gb/s (switch de 1Gb/s com 48 portas)
Espere, 96 Gb/s? É uma matriz full duplex. (link)
Por que não fazer um benchmark com dezenas de servidores?
Prefiro benchmarks realizados em um servidor bare-metal, em servidores locais. Não é barato.
Dados
| 4 nós | 6 nós | 8 nós | |
| Entradas | 20M | 30M | 40M |
| Cópias | 2 | 2 | 2 |
| Feilds | 10 | 10 | 10 |
| Campo | 150 bytes | 150 bytes | 150 bytes |
| Entrada | 1.500 bytes | 1.500 bytes | 1.500 bytes |
| Dados | 55,8 GB | 83,8 GB | 111,6 GB |
Por que não fazer um benchmark com terabytes de dados?
O objetivo é identificar o desempenho e a escala do banco de dados quando os conjuntos de trabalho estão na memória. O conjunto de trabalho poderia ter 32 GB ou 384 GB. Não teria importado. Ele cabia na memória. O conjunto de trabalho poderia ter sido 10% dos dados, ou poderia ter sido 90% dos dados. Isso não teria importado. Ele caberia na memória.
Considere os clientes que fazem streaming de filmes da Netflix. Há muitos, muitos clientes. No entanto, apenas uma fração deles está fazendo streaming de filmes em um determinado momento. Esse é um conjunto de trabalho. Considere os usuários de aplicativos móveis e da Web. Eu jogo Words with Friends com minha esposa. Jogamos de dois a três jogos ao mesmo tempo. De vez em quando, lanço o aplicativo. Passo alguns minutos, se não vários minutos, jogando as palavras certas para esmagá-la. Somos todos adeptos do Amazon Prime. Entretanto, só fazemos compras de vez em quando. Quando compramos, fazemos parte de um grupo de trabalho. Clientes que estão comprando no momento. Não todos os clientes. Depois, há os dados em tempo real. Considere a análise do fluxo de cliques e os dados do sensor. O conjunto de trabalho são os usuários que estão visitando o site no momento. Não todos os usuários. O conjunto de trabalho é o último minuto, a última hora ou o último dia dos dados do sensor. Não todos os dados do sensor.
Embora um conjunto de trabalho na memória melhore o desempenho de leitura, ele não melhora o desempenho de gravação.
Todos os dados eram persistentes.
Configuração
Consistência
Apache Cassandra, eventualmente consistente (ONE). MongoDB e Couchbase Server, consistentes.
Durabilidade / Persistência
Apache Cassandra, MongoDB e Couchbase Server, persistência assíncrona.
Observação: o registro de confirmação foi desativado no Apache Cassandra.
Replicação
Há duas cópias.
Topologia
Apache Cassandra e Couchbase Server, um nó por servidor. MongoDB, dois nós por servidor.
Observação: o MongoDB se baseia em uma topologia mestre/escravo. Para garantir que cada servidor responda às solicitações de leitura/gravação do cliente, um mestre e um escravo (de diferentes shards) foram instalados em cada servidor.
Cargas de trabalho
Leitura intensa: 95% leituras / 5% gravações
Equilibrado: 50% leituras / 50% gravações
Nós de banco de dados e threads de cliente
Os benchmarks foram realizados em implementações de quatro, seis e oito servidores.
Os benchmarks foram realizados com um número crescente de threads de clientes.
Resultados
Leia mais
Apache Cassandra
Picos de rendimento entre 248 e 496 threads de clientes: 99K ops/s.
A adição de nós aumenta a taxa de transferência.
A latência nunca é inferior a 1 ms.
A adição de nós diminui a latência.
MongoDB
Picos de rendimento entre 132 e 198 threads de clientes: 227K ops/s.
A adição de nós aumenta a taxa de transferência.
A latência é inferior a 1 ms para até 231 threads de clientes: 200 mil operações/s.
A adição de nós diminui a latência.
Servidor Couchbase
A taxa de transferência atinge o pico em 2.970 threads de clientes: 1,62M ops/s.
A adição de nós aumenta a taxa de transferência.
A latência é inferior a 1 ms para até 1.320 threads de clientes: 1,44M ops/s.
A adição de nós diminui a latência.
MongoDB versus Couchbase Server
Vamos comparar a taxa de transferência e a latência do MongoDB e do servidor Couchbase sob carga equivalente.
A taxa de transferência do Couchbase Server aumenta com o aumento da carga. O MongoDB, nem tanto.
A latência do servidor Couchbase é inferior a 0,6 ms para até 264 threads de clientes: 642 mil operações/s.
O MongoDB tem menos de 1 ms até 231 threads de cliente: 200 mil operações/s
Explicação
- A latência de leitura do MongoDB se beneficia dos arquivos mapeados na memória. No entanto, os arquivos mapeados na memória não têm um desempenho tão bom quanto a memória direta. Além disso, o MongoDB depende de uma topologia arcaica e complexa. De fato, o benchmark comparou o MongoDB com 16 nós com o Couchbase Server com 8 nós.
Apache Cassandra x Servidor Couchbase
A taxa de transferência do Couchbase Server aumenta com o aumento da carga. O Apache Cassandra, nem tanto.
A latência do Couchbase Server é inferior a 0,7 ms até 792 threads de clientes: 1,22M ops/s.
A latência do Apache Cassandra nunca é inferior a 1 ms.
Explicação
O Apache Cassandra depende de um cache de linha pobre, desativado por padrão (JIRA).
Leitura/gravação balanceada
Apache Cassandra
Picos de throughput entre 272 e 544 threads de clientes: 89K ops/s.
A adição de nós aumenta a taxa de transferência.
A latência é inferior a 1 ms para até 680 threads de clientes: 79 mil operações/s.
A adição de nós diminui a latência.
MongoDB
A taxa de transferência atinge o pico com 256 threads de clientes: 85K ops/s.
A adição de nós aumenta a taxa de transferência.
A latência nunca é inferior a 1 ms.
A adição de nós diminui a latência.
Servidor Couchbase
A taxa de transferência atinge o pico em 3.000 threads de clientes: 1,18M ops/s.
A adição de nós aumenta a taxa de transferência.
A latência é inferior a 1 ms para até 480 threads de clientes: 499 mil operações/s.
A adição de nós diminui a latência.
MongoDB versus Couchbase Server
Vamos comparar a taxa de transferência e a latência do MongoDB e do Couchbase Server sob carga equivalente.
A taxa de transferência do Couchbase Server aumenta com o aumento da carga. O MongoDB, nem tanto.
A latência do Couchbase Server é inferior a 0,8 ms até 360 threads de cliente: 457 mil operações/s.
A latência do MongoDB nunca é inferior a 1 ms.
Explicação
Bem, um único bloqueio não ajuda (manual | JIRA). O bloqueio em nível de documento foi solicitado desde 2010.
Apache Cassandra x Servidor Couchbase
A taxa de transferência do Couchbase Server aumenta com o aumento da carga. O Apache Cassandra, nem tanto.
A latência do Couchbase Server é inferior a 1 ms até 480 threads de cliente: 499 mil operações/s.
A latência do Apache Cassandra é inferior a 1 ms para até 680 threads de clientes: 79 mil operações/s.
Explicação
A latência de gravação do Apache Cassandra se beneficia da tabela de memória, mas o Couchbas Server foi projetado para a simultaneidade.
Conclusão
| Leituras | Escreve | |||
| Baixa produtividade | Alto rendimento | Baixo rendimento | Alto rendimento | |
| Apache Cassandra | Ruim | Ruim | Excelente | Ruim |
| MongoDB | Excelente | Ruim | Ruim | Ruim |
| Servidor Couchbase | Excelente | Excelente | Excelente | Bom |
Dúvidas?
Comente ou participe da discussão em Reddit ou HN.
Você pode fazer o download do white paper aqui.
