Saiba mais sobre o teste de desempenho para gravações duráveis com o SDK 3.0+ e a configuração da infraestrutura usando o cbc-pillowfight do Couchbase.
O teste de desempenho da durabilidade com qualquer banco de dados pode ser subjetivo e desafiador, pois há outros fatores que influenciam o desempenho. A durabilidade é o ato de poder gravar em cópias ativas, de réplica e persistentes dos dados. O Couchbase tem diferentes níveis de durabilidade com base no caso de uso e nos SLAs. Mas, em última análise, a velocidade da rede, a velocidade de gravação em disco e os recursos de CPU disponíveis são tão sensíveis ao desempenho quanto o próprio banco de dados.
O que define o desempenho (ou alto desempenho) das gravações duráveis? É a latência da operação? É a taxa de transferência (operações por segundo)? Isso depende do caso de uso. A resposta popular geralmente é... AMBOS!
Atualizações de durabilidade no SDK do Couchbase
As versões anteriores do Couchbase SDK (Pré-3.0) têm gravações duráveis com os parâmetros replicarPara e persistTo. ReplicarPara aguarda a conclusão da gravação de 1 a 3 réplicas. PersistTo aguarda que a cópia ativa no disco também seja gravada. Os desenvolvedores queriam um controle mais refinado e um melhor desempenho com gravações duradouras em réplicas e no disco.
O Couchbase SDK 3.0 foi lançado há cerca de um ano. Uma atualização fundamental para a nova versão do SDK é a durabilidade, tendo em mente a latência e a taxa de transferência.
Consulte as definições na documentação:
Há três níveis de durabilidade:
- Maioria - O servidor garantirá que a alteração esteja disponível na memória da maioria das réplicas configuradas.
- Majoritário e Persistente para Ativo - Nível de maioria, além de persistir no disco no nó ativo.
- PersistToMajority (Persistir para a maioria) - Nível da maioria, além de persistir no disco na maioria das réplicas configuradas.
Cada nível de durabilidade tem um impacto no desempenho, pois o SDK aguardará a conclusão da gravação usando maioria, persistToou ambos.
Em minha experiência de trabalho com clientes com histórico de banco de dados relacional, a decisão imediata é optar pelo nível de durabilidade mais alto. Mas a experiência deles é bem diferente, pois os RDBMS têm durabilidade incorporada na arquitetura para impedir leituras antes que as gravações sejam feitas.
Considerando que o Couchbase tem um controle mais refinado sobre as configurações de durabilidade do que os usuários de RDBMS tradicionais poderiam esperar. Por exemplo, o Couchbase também tem um durabilidade do nível da caçamba configuração.
Além disso, a escolha da durabilidade é específica para o caso de uso, o aplicativo e os SLAs. Se a durabilidade no nível do bucket não for controle suficiente, o Couchbase oferece suporte a durabilidade em uma base de gravação por gravação - cada gravação individual pode ser configurada para uma durabilidade específica ou pode ser definida para o nível do bucket, ou seja, todas as gravações seguirão o mesmo nível de durabilidade.
Considerações sobre a configuração do servidor para testes
Ainda mais importante do que o mecanismo de durabilidade dentro da arquitetura do banco de dados são as especificações da máquina de hospedagem para testar o desempenho das gravações duráveis. O Couchbase nunca colocará uma cópia ativa e uma cópia de réplica no mesmo disco; nós armazenamos automaticamente os dados e garantimos que as réplicas não residirão com uma cópia ativa em um nó diferente.
Isso significa que a gravação em réplicas é afetada pela velocidade e latência da rede. Quanto mais rápida for a rede, mais rápida será a gravação durável na réplica, ou seja, na maioria. O fator mais influente da máquina de hospedagem para gravações duráveis é a latência e a taxa de transferência do disco. O Couchbase recomenda SSDs locais para persistência, não apenas pela velocidade, mas também pela recuperação rápida e eficiente de um nó em caso de falha.
Considerações sobre a nuvem pública
Atualmente, cada vez mais clientes estão realizando testes e POCs em ambientes de nuvem pública para obter velocidade, simplicidade e investimento temporário de recursos.
Seleção de armazenamento/disco
Na nuvem pública, todos os provedores têm diferentes níveis de armazenamento em disco para instâncias de máquina, desde o armazenamento do tipo EBS, que normalmente é o mais lento, até SSDs NVRAM de alto desempenho.
Qualquer tipo de armazenamento funcionará, mas a avaliação deve estar ciente de que o desempenho dos tipos de volume é, sem dúvida, o fator mais importante para gravações duráveis, independentemente do banco de dados que estiver sendo avaliado. Por exemplo, este link da documentação da AWS mostra como os tipos de armazenamento podem ser complicados no armazenamento em nuvem pública.
Seleção do tipo de instância
Os clientes que testaram com sucesso a durabilidade do Couchbase tentam combinar o ambiente de teste com o ambiente hospedado de produção. No entanto, os clientes também implementam t3.large ou t3.small para teste e, em seguida, pergunte por que não está funcionando.
Cenários de rede
Certifique-se de que o cliente esteja na mesma rede que o ambiente do servidor para obter o melhor desempenho. Os testes de baixa qualidade geralmente são executados em um laptop sem fio para um nome de host exposto publicamente em uma nuvem pública. Há tantos saltos de rede da rede sem fio para o roteador, rede pública, rede hospedada etc. que as latências são enormes.
Em resumo, com o tratamento de eventos para gravações duráveis, o Couchbase tem gravações muito rápidas. As gravações duráveis são feitas tão rapidamente quanto o ambiente de hospedagem permite e/ou está configurado.
Teste de durabilidade do Couchbase
A durabilidade pode ser testada usando qualquer aplicativo que você já tenha criado com o SDK do Couchbase; no entanto, para simplificar e padronizar os testes, uma de nossas ferramentas pode ajudar.
Incluída no Couchbase Server está uma ferramenta de linha de comando de medição de desempenho chamada cbc-pillowfight. O Pillowfight faz parte do Couchbase há anos, portanto é sólido como uma rocha para testes de desempenho. O Pillowfight é baseado no Couchbase C SDK, portanto, tem alto desempenho. Ele é muito rápido, a ponto de ser rápido demais! O que quero dizer com "rápido demais"? Falarei sobre isso daqui a pouco.
As informações de instalação e configuração são apresentadas em este blog anterior com relação ao teste do Couchbase com o pillowfight e alguns cenários de amostra são apresentados a seguir.
Opções para testes de desempenho usando pillowfight
As configurações padrão do pillowfight podem não ser ideais para o tipo de aplicativo que você usará com o Couchbase. Há muitas maneiras de ajustar o pillowfight para que se adapte melhor aos seus casos de uso. Para obter a lista completa de opções, digite cbc-pillowfight -help na linha de comando.
Aqui estão algumas opções notáveis que você pode querer experimentar:
- -I ou -num-itens com um número, para especificar em quantos documentos você deseja operar.
- -json para usar cargas úteis JSON nos documentos. Por padrão, os documentos são criados com cargas úteis não JSONmas talvez você queira ter documentos JSON reais para testar outros aspectos do desempenho enquanto a luta de travesseiros estiver em execução.
- -e para expirar documentos após um determinado período de tempo. Se estiver usando o Couchbase como cache ou armazenamento de curto prazo, convém usar essa configuração para monitorar o efeito da expiração dos documentos.
- -subdoc para usar a API de subdocumento. Nem toda operação precisará ser feita em um documento inteiro.
- -M ou -tamanho máximo para definir um limite máximo para o tamanho dos documentos. Talvez você queira ajustar isso para adequar um tamanho de documento mais realista ao seu sistema. Há também um -m e um -min-size correspondentes
Aqui está outro exemplo usando as opções acima:
cbc-pillowfight.exe -U couchbase://localhost/pillow -u Administrator -P password -I 10000 -json -e 10 -subdoc -M 1024
Isso iniciará um pillowfight usando 10.000 documentos JSON, que expiram após 10 segundos, usam a API de subdocumento e têm um tamanho máximo de documento de 1024 bytes.
Observação: Há um -t -num-threads opção. Atualmente, se você estiver usando o Windows (como eu), estará limitado a um único thread (consulte este código).
O Pillowfight pode ser ajustado para operações específicas, especialmente para testes de desempenho de gravações duráveis.
Vamos revisar esse comando de luta de travesseiros:
cbc-pillowfight -U / -u -P -I 2000 -set-pct=100 -min-size=100 -max-size=250 -t 10 -durability majority_and_persist_to_active -no-population
O que esse comando está fazendo?
-I 2000 é o número de itens, 2000.
-set-pct=100 is 100% das operações são gravações. Se definido como 50, então 50/50 são gravações e leituras.
-min-size=100 é um documento de tamanho mínimo de 100 bytes.
-max-size=250 é um documento de tamanho máximo de 250 bytes. O Pillowfight randomizará os documentos de 100 a 250 bytes.
-t 10 é de 10 threads
-durabilidade majority_and_persist_to_active é a configuração de durabilidade. O SDK gravará na maioria das réplicas, se houver mais de uma, e aguardará a persistência da cópia ativa no disco.
-sem população A configuração confirma a gravação e a exclui.
Gerenciamento de threads/buffers
Esse comando continuará criando documentos e gravando no Couchbase o mais rápido possível. O Pillowfight criará uma lista de chaves como uma matriz e gravará recursivamente. Quando chegar ao fim, ele voltará ao topo da matriz e começará a escrever as mesmas chaves novamente.
Lembra-se do meu comentário anterior "muito rápido"? Ao testar a durabilidade, especialmente em ambientes de hospedagem lentos com redes lentas e armazenamento em massa (EBS S3), o pillowfight será muito mais rápido do que a infraestrutura. Isso significa que um thread de pillowfight ainda estará esperando para terminar enquanto outro thread estiver esperando para fazer a próxima gravação.
Como podemos criar um teste que realmente teste a durabilidade? Faça com que o buffer de chaves seja grande e não volte ao topo.
cbc-pillowfight -U / -u -P -I 2000000 -set-pct=100 -min-size=100 -max-size=250 -t 10 -durability majority_and_persist_to_active -batch-size 1 -no-population
Qual é a diferença entre esses comandos? O comando acima cria uma lista de 2 milhões de chaves e só a percorre uma vez. Isso garantirá que um thread não fique aguardando a gravação de um thread anterior para concluir o mesmo documento. Isso está realmente testando o Couchbase e a capacidade do ambiente de hospedagem de gravações duradouras. É possível remover tamanho do loteSe você não tiver um thread, provavelmente não haverá threads esperando para escrever.
Mesmo que o teste não use pillowfight, o aplicativo e os critérios de teste devem estar cientes de que, se um buffer de documentos for usado recursivamente, há uma probabilidade de que, com os threads, uma gravação possa estar aguardando a conclusão de outra gravação.
Conclusões
O Couchbase é capaz de realizar gravações de alto desempenho, mas cada caso de uso e condições são exclusivos do teste. A configuração do ambiente de teste correto é essencial para qualquer teste de gravação durável.
O Pillowfight é uma ótima ferramenta para testar o Couchbase com muitos dos recursos já incorporados, como a configuração da proporção de leituras para gravações, threading, tamanho do documento e níveis de durabilidade.
Se o aplicativo de teste estiver sendo criado, é importante realizar testes que realmente testem o banco de dados e a infraestrutura. Os resultados são subjetivos não apenas ao banco de dados, mas também ao ambiente em que ele foi testado.
Se tiver alguma dúvida, entre em contato comigo em james.powenski@couchbase.com Terei o maior prazer em ajudar.
