Alto desempenho com o Couchbase Server no Google Cloud

O Couchbase Server é um banco de dados distribuído NoSQL de código aberto e vários modelos que incorpora um banco de dados de documentos JSON e um armazenamento de valores-chave. O Couchbase Server foi desenvolvido com base em uma arquitetura centrada na memória, projetada para oferecer alto desempenho, disponibilidade e escalabilidade consistentes para aplicativos corporativos da Web, móveis e da Internet das Coisas. O Couchbase Server também se sai muito bem no Google Compute Engine, oferecendo uma relação preço/desempenho superior. O Google publicou um conjunto de resultados na postagem do blog do Google Cloud aqui e, nesta postagem, gostaria de mostrar a você o conjunto completo de testes que fizemos na plataforma.

No último ano, os parceiros de tecnologia relataram algumas estatísticas de desempenho interessantes no Google Compute Engine, com Cassandra capaz de sustentar 1 milhão de gravações por segundo. Tomamos isso como um desafio e decidimos ver o quanto poderíamos aumentar a escala e reduzir o preço/desempenho. Este documento detalha os resultados de nossas experiências.

Antes de me aprofundar, quero agradecer a David Haikney (Couchbase) e Dave Rigby (Couchbase) por todo o trabalho que fizeram nas medições de benchmark e a Ivan Santa Maria Filho (Google) por toda a orientação que forneceu.

Resumo

O Couchbase Server foi capaz de sustentar 1,1 milhão de gravações por segundo. O tamanho do conjunto de dados era de 3 bilhões de itens com um tamanho de valor de 200 bytes. As cargas de trabalho de gravação pura não são o único tipo de carga de trabalho interessante no banco de dados, mas são desafiadoras. Vários clientes que desenvolvem aplicativos de IoT (Internet das Coisas) enfrentam um desafio semelhante. Os resultados do teste comprovam que o Couchbase Server no Google Cloud Platform pode ser uma ótima opção para aplicativos de IoT que gravam dados com alta velocidade e grandes volumes.

Detalhes da referência

Em nossa jornada, tentamos duas configurações principais de benchmark.

• Referência A: Essa configuração de referência operou com mais de 3 bilhões de itens. Essa medição simulou a configuração publicada em Cassandra no Google Cloud.
• Referência B: Essa segunda medição foi feita em um conjunto de dados menor de 100 milhões de itens. Essa medição simulou a configuração publicada por Aerospike no Google Cloud.

Antes de entrar em mais detalhes, você pode experimentar esses benchmarks por conta própria ou simplesmente consultar os scripts para obter mais detalhes. Aqui está o nosso repositório do github.

Referência A:

1,1 milhão de gravações por segundo em 3 bilhões de itens com 50 nós (n1-padrão-16)

• 1,1 milhão de gravações por segundo com um total de 3 bilhões de itens
• A latência média foi de 15 ms
• A latência do 95º% foi de 27 ms.
• O custo total da execução do benchmark por uma hora é de $56,3/h.

O gráfico abaixo mostra o aquecimento e as gravações sustentadas ao longo do tempo, atingindo 1,1 milhão.

O gráfico abaixo mostra a mediana e a latência do 95% durante a execução do teste

Conjunto de dados de base e configuração de bucket

• Carga de trabalho operada com um total de 3 bilhões de itens
• Cada item tem exatamente 200 bytes de valor.

Configuração do servidor Couchbase:

• O Debian foi o sistema operacional escolhido para essa execução (Debian Wheezy Backports).
• Configuração de cluster
  • A cota de RAM do servidor foi definida como 50 GB
  • A capacidade da fila de discos foi definida como 5 milhões de itens
  • As linhas de E/S estavam em 4 linhas de gravação e 1 linha de leitura
• Configuração da caçamba:
  • Todos os itens 3B foram configurados para residir em um único bucket.
  • 2 cópias dos dados foram mantidas em 2 nós separados para redundância. A configuração do bucket especificou uma réplica além da cópia principal.
  • A política de despejo do bucket foi definida como "despejo de valor"
  • A cota de RAM do bucket foi definida como 50 GB por nó.
  • A compactação foi desativada

Configuração da máquina virtual

• Contagem de VMs: 50
• Tamanho da VM: n1-padrão-16

Havia muitas opções para escolher nos tamanhos de VM. No entanto, descobrimos que o n1-standard-16 com 16 núcleos é uma ótima opção para o desempenho ideal em termos de preço. O teste foi executado com 50 VMs n1-standard-16 com um total de 60 GB de RAM em cada nó.

• Armazenamento: Discos persistentes SSD de 500 GB

O armazenamento do Google Cloud teve um ótimo desempenho no Couchbase Server. Usamos a opção de armazenamento persistente e não efêmero para tornar essa implementação realista para cargas de produção. A melhor taxa de transferência com o Couchbase Server foi obtida com a oferta de disco persistente SSD. O Couchbase Server usou SSD de 500 GB Disco persistente como o volume de dados. O Couchbase Server não usou o volume raiz de 10 GB para operações de banco de dados. O registro no diário foi desativado (noatime) no volume de dados.

• Custo por nó: $1.12 / hr.
• Custo total com 50 nós: $56,30 / h

Propriedades da carga de trabalho e durabilidade adicional com o sinalizador "ReplicateTo

A carga foi gerada usando a ferramenta pillowfight. Para fornecer a garantia de durabilidade adicional, a ferramenta pillowfight foi modificada para adicionar o sinalizador "ReplicateTo" a cada gravação. A opção garante que as gravações sejam reconhecidas somente depois que a operação de gravação atingir as duas cópias dos dados mantidos pelo Couchbase Server.

O Couchbase Server usa uma réplica mestre ativa para todas as suas gravações e mantém réplicas secundárias para redundância. O Couchbase Server vem com uma poderosa tecnologia de replicação integrada chamada DCP (protocolo de alteração de banco de dados). O DCP transmite as alterações para as réplicas secundárias. O Couchbase pode manter latências abaixo de milissegundos em seu modelo de gravação padrão com seu eficiente cache na memória. No entanto, a gravação replicada fornece a durabilidade firme sob uma falha de nó e garante que nenhum dado seja perdido no caso de um failover.

Configuração de geração de carga:

A geração de carga foi feita usando 32 clientes com VMs n1-highcpu-8.

A seguir, a opção de linha de comando usada para executar uma instância de cliente com pillowfight

./cbc-pillowfight -min-size=200 -max-size=200 -num-threads=2 -num-items=93750000 -set-pct=100 -spec=couchbase://cb-server-1/charlie -batch-size=50 -num-cycles=468750000 -sequential -no-population -rate-limit=20000 -tokens=275 -durability

Referência B:

1 milhão de gravações por segundo em 100 milhões de itens com 40 nós (n1-padrão-8)

• 1 milhão de gravações por segundo com um total de 100 milhões de itens
• A latência média foi de 18 ms
• A latência do 95º% foi de 36 ms.
• O custo total da execução do benchmark por uma hora é de $21,28/h.

Conjunto de dados de base e configuração de bucket

• Carga de trabalho operada com um total de 100 milhões de itens
• Cada item tem exatamente 200 bytes de valor.

Configuração do servidor Couchbase:

• O Debian foi o sistema operacional escolhido para essa execução (Debian Wheezy Backports).
• Configuração de cluster
  • A cota de RAM do servidor foi definida como 24 GB
  • A capacidade da fila de discos foi definida como 5 milhões de itens
  • As linhas de IO estavam em 2 linhas de gravação e 1 linha de leitura
• Configuração da caçamba:
  • Todos os itens de 100M foram configurados para residir em um único bucket.
  • 2 cópias dos dados foram mantidas em 2 nós separados para redundância. A configuração do bucket especificou uma réplica além da cópia principal.
  • A política de despejo do bucket foi definida como "despejo de valor"
  • A cota de RAM do bucket foi definida como 24 GB por nó.
  • A compactação foi desativada

Configuração da máquina virtual

• Contagem de VMs: 40
• Tamanho da VM: n1-padrão-8

Para essa contagem menor de itens, descobrimos que o n1-standard-8 com 8 núcleos é o mais adequado para um desempenho de preço ideal. O teste foi executado com uma VM 40x n1-standard-8 com um total de 30 GB de RAM em cada nó.

• Armazenamento: Disco persistente padrão de 500 GB

O armazenamento do Google Cloud teve um ótimo desempenho no Couchbase Server. Usamos a opção de armazenamento persistente e não efêmero para tornar essa implementação realista para cargas de produção. O preço/desempenho ideal com o Couchbase Server foi obtido com a oferta Standard Persistent Disk. O Couchbase Server usou 500 GB Disco persistente como o volume de dados. O Couchbase Server não usou o volume raiz de 10 GB para operações de banco de dados. O registro no diário foi desativado (noatime) no volume de dados.

• Custo por nó: $0.53 / hr.
• Custo total com 40 nós: $21,28 / h

Propriedades da carga de trabalho e durabilidade adicional com o sinalizador "ReplicateTo

A carga foi gerada usando a ferramenta pillowfight. Para fornecer a garantia de durabilidade adicional, a ferramenta pillowfight foi modificada para adicionar o sinalizador "ReplicateTo" a cada gravação. A opção garante que as gravações sejam reconhecidas somente depois que a operação de gravação atingir as duas cópias dos dados mantidos pelo Couchbase Server.

O Couchbase Server usa uma réplica mestre ativa para todas as suas gravações e mantém réplicas secundárias para redundância. O Couchbase Server vem com uma poderosa tecnologia de replicação integrada chamada DCP (protocolo de alteração de banco de dados). O DCP transmite as alterações para as réplicas secundárias. O Couchbase pode manter latências abaixo de milissegundos em seu modelo de gravação padrão com seu eficiente cache na memória. No entanto, a gravação replicada fornece a durabilidade firme sob uma falha de nó e garante que nenhum dado seja perdido no caso de um failover.

Configuração de geração de carga:

A geração de carga foi feita usando 32 clientes com VMs n1-highcpu-8.

A seguir, a opção de linha de comando usada para executar uma instância de cliente com pillowfight

./cbc-pillowfight -min-size=200 -max-size=200 -num-threads=2 -num-items=93750000 -set-pct=100 -spec=couchbase://cb-server-1/charlie -batch-size=50 -num-cycles=468750000 -sequential -no-population -rate-limit=20000 -tokens=275 -durability

Conclusão

1 milhão de gravações por segundo é uma quantidade impressionante de gravações e muitos de vocês talvez nunca atinjam esse tipo de taxa de transferência em seus sistemas, mas é reconfortante saber que é possível fazer esse 1 milhão de gravações por segundo em 3 bilhões de itens em apenas 50 nós no Google Cloud com preço/desempenho 6 vezes melhor em comparação com o Cassandra com gravações totalmente replicadas!