Uma história de dois métodos de ejeção: Somente valor vs. Completo

Introdução

Gostaria de agradecer à nossa equipe de engenharia do Couchbase Server - especialmente a Dave Rigby e Jim Walker - pela enorme ajuda com este artigo e pela paciência infinita com todas as minhas perguntas. Muito obrigado, pessoal, eu realmente aprecio seu vasto conhecimento e sua disposição em compartilhá-lo!

No Couchbase Server, os dados são armazenados em buckets. O padrão tipo de caçamba - chamado de forma não criativa Couchbase assegura a persistência assíncrona dos dados no disco. O servidor tentará ter todos os seus dados, o conjunto ativo e o(s) conjunto(s) de réplica, na memória. No entanto, se os dados na memória atingirem 85% da cota de memória do bucket (esse nível é chamado de marca d'água alta), o servidor começará a ejetar (despejar) alguns dos documentos que não foram usados recentemente da memória. Os documentos ativos têm 40% de chance de serem removidos, e os documentos de réplica têm 60% de chance de serem removidos. O motivo é o seguinte: é mais importante ter um documento ativo residente na memória; no entanto, também queremos ter algumas réplicas de documentos na memória, para o caso de um nó falhar e as réplicas precisarem se tornar ativas. O processo de despejo continua até que os dados na memória fiquem abaixo de 75% da cota de memória do bucket (esse nível é chamado de marca d'água baixa).

Apenas um breve lembrete sobre a estrutura dos documentos armazenados no Couchbase:

• Documento chave ou IDComprimento variável - até 250 bytes, deve ser exclusivo para os documentos armazenados no mesmo bucket
• Documento metadadosComprimento fixo - 56 bytes para documentos armazenados no tipo de bucket Couchbase, 72 bytes para documentos armazenados no tipo de bucket Ephemeral (esse tipo de bucket está fora do escopo deste artigo)
• Documento valor: comprimento variável - até 20 MB, geralmente JSON, outros formatos também podem ser usados

Dois métodos de ejeção

Por padrão, um bucket do Couchbase usa Somente valor método de ejeção (ou despejo). Muitas versões atrás, essa era a única opção disponível. Como o nome indica, o processo de ejeção removerá apenas o valor dos documentos e manterá as chaves e os metadados do documento na memória o tempo todo.

A partir da versão 3.0 (Servidor Couchbase está na versão 6.5.1 no momento em que este artigo foi escrito), adicionamos a função Completo método de ejeção. É fácil supor que um balde configurado para expulsão total removerá as chaves, os metadados e os valores dos documentos como parte do processo de ejeção.

Compensação: desempenho vs. tamanho da memória

Então, qual opção você deve escolher para seus buckets? Aqui está o que a dica de ferramenta explica na GUI da nossa versão mais recente do Couchbase Server:

• Ejeção de valor: Durante a ejeção, somente o valor será ejetado (a chave e os metadados permanecerão na memória).
• Ejeção total: Durante a ejeção, tudo (incluindo chave, metadados e valor) será ejetado.
  O Value Ejection precisa de mais memória do sistema, mas oferece o melhor desempenho. A ejeção total reduz o requisito de sobrecarga de memória.

Para ser mais preciso, nem método "precisa de mais memória do sistema“: Completo A ejeção permite que o conjunto de dados exceda significativamente a memória, enquanto Valor A ejeção permite que o conjunto de dados seja maior do que a memória até certo ponto, pois ele deve manter as chaves e os metadados na memória.

Se latência de leitura consistente dos aplicativos que trabalham com os dados no Couchbase Server é (muito) importante, você deve optar pela ejeção de valores. Isso também exige que você dimensionar seu cluster corretamente, atribua cotas de memória suficientes em seus buckets, implemente retenção de documentos políticas (arquivar ou remover documentos antigos regularmente), e monitorar o uso da memória.

Se estiver dentro de limites orçamentários ou tecnológicos existentes é (muito) importante, então você deve considerar o despejo completo para seus grandes buckets. Esse pode ser o caso quando seus recursos de hardware no local estiverem esgotados e não houver como colocar mais RAM nos nós do Couchbase. Quando o dinheiro é escasso para gastos com tecnologia local ou na nuvem, a troca de desempenho pode salvar o dia.

Outro motivo para considerar a ejeção total é quando você espera que seu conjunto de dados seja grandepara que ele exceder configurações de memória razoáveis. Qual é o tamanho do grande? Digamos que sejam bilhões (sim, no plural!) de documentos, dezenas (também no plural!) de terabytes de dados. Nossos engenheiros de soluções e arquitetos de soluções estão sempre aqui para ajudá-lo dimensionar seu cluster do Couchbase corretamente - por favor, fale conosco.

Embora seja possível mudar de um método de ejeção para outro, essa é uma das poucas operações que exigem a reinicialização do balde e, portanto, algum tempo de inatividade. Mostramos o seguinte aviso em fonte vermelha na interface do usuário quando você tenta alterar o método de ejeção: A alteração da política de despejo reiniciará o bucket. Isso levará ao fechamento de todas as conexões abertas e a algum tempo de inatividade. Portanto, é aconselhável decidir sobre o método de ejeção de suas caçambas antes de colocá-las em produção.

Por que a diferença de desempenho?

Vamos analisar os diferentes cenários dos métodos de ejeção de balde e da residência de dados. Isso nos ajudará a entender como o desempenho é afetado.

1. Residência de dados completos

Quando seus dados estão totalmente residentes (ou seja, cabem em ~85% da cota de memória do bucket), o desempenho dos buckets de ejeção completa e somente de valor deve ser semelhante. As operações de documentos funcionam como mostrado abaixo:

• Obter (ler) um documento com chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, retorne o documento da memória.
    • RÁPIDO: Caso contrário, retorna o erro "o documento não existe".
• Inserir um documento com a chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, retorne o erro "o documento já existe".
    • RÁPIDO: Caso contrário, grave o documento na memória. Em seguida, persista e replique-o de forma assíncrona.
• Substituir um documento com a chave = = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, salve as alterações na memória. Em seguida, persista e replique-as de forma assíncrona.
    • RÁPIDO: Caso contrário, retorna o erro "o documento não existe".

2. Residência parcial de dados, ejeção somente de valor

Quando a residência de dados estiver abaixo de 100% para um bucket com somente valor ejeção, o Couchbase Server sabe que as chaves e os metadados do documento ainda estão na memória. Portanto, as operações de documentos serão parecidas com as seguintes:

• Obter (ler) um documento com chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, verifique se o valor do documento está na memória
      • RÁPIDO: Se sim, retorne o documento da memória.
      • LENTO: Caso contrário, leia o documento do disco para a memória e retorne-o.
    • RÁPIDO: Caso contrário, retorna o erro "o documento não existe".
• Inserir um documento com a chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, retorne o erro "o documento já existe".
    • RÁPIDO: Caso contrário, grave o documento na memória. Em seguida, persista e replique-o de forma assíncrona.
• Substituir um documento com a chave = = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, salve as alterações na memória. Em seguida, persista e replique-as de forma assíncrona.
    • RÁPIDO: Caso contrário, retorna o erro "o documento não existe".

3. Residência parcial de dados, ejeção total

Quando a residência de dados estiver abaixo de 100% para um bucket com completo ejection, Couchbase Server não pode confiar na presença de chaves de documentos e metadados na memória, porque eles poderiam ter sido removidos. Portanto, as operações de documentos serão parecidas com as seguintes:

• Obter (ler) um documento com chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, verifique se o valor do documento está na memória
      • RÁPIDO: Se sim, retorne o documento da memória.
      • LENTO: Caso contrário, verifique o disco
        • LENTO: Se o documento for encontrado no disco, leia o documento do disco para a memória e retorne-o.
        • LENTO: Caso contrário, retorna o erro "o documento não existe".
• Inserir um documento com a chave = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, retorne o erro "o documento já existe".
    • LENTO: Caso contrário, verifique o disco
      • LENTO: Caso contrário, grave o documento na memória. Em seguida, persista e replique-o de forma assíncrona.
      • LENTO: Se sim, retorne o erro "o documento já existe".
• Substituir um documento com a chave = = profile::john-doe::123
  • RÁPIDOVerificar na memória se essa chave existe.
    • RÁPIDO: Se sim, salve as alterações na memória. Em seguida, persista e replique-as de forma assíncrona.
    • LENTO: Caso contrário, verifique o disco
      • LENTO: Caso contrário, retorna o erro "o documento não existe".
      • LENTO: Se sim, grave o documento na memória. Em seguida, persista e replique-o de forma assíncrona.

Com baldes de despejo completo que não são 100% residentes na memória, muitos Existe as operações precisam ir para o disco. O número de buscas em segundo plano (leitura de documentos do disco para a memória, também conhecido como "erros de cache") provavelmente também será maior para os buckets de ejeção total.

Existem maneiras de melhorar o desempenho?

Além de Inserir e Substituir operações, os SDKs do Couchbase suportam Upserts. O upsert inserirá um documento, caso não exista, ou substituirá o documento existente. Devido à natureza somente de acréscimo do tratamento de mutações de dados no Couchbase Server, o upsert operações não requerem correspondente existe operação.  Portanto, o uso de inserções superiores em vez de inserções e substitui melhorará o desempenho do aplicativo, desde que o caso de uso permita essa substituição.

Os discos rápidos dedicados também melhorarão o desempenho dos buckets de ejeção total. Essa é uma das configurações recomendadas para os nós do Couchbase: discos dedicados por nó sobre armazenamento virtualizado.

Quando mudar de Ejeção somente de valor para Ejeção total

Vamos considerar a seguinte situação:

• Você tem um balde configurado com ejeção somente de valor
• O bucket cresceu até o ponto em que menos de 15-20% dos dados estão residentes na memória, que é a nossa taxa de residência mínima recomendada
• Você prevê a entrada de mais dados, já arquiva/exclui os documentos de acordo com os requisitos do caso de uso e não há como fornecer mais RAM ao bucket

Você deve mudar para o método de ejeção total?

Há uma boa métrica que pode ajudá-lo a responder a essa pergunta: a quantidade de metadados na RAM, em comparação com os dados do usuário na RAM para o mesmo bucket. Por "metadados", queremos dizer documentos chaves + metadadosneste caso específico. "Dados do usuário", neste caso, significa documento valor.

Você pode encontrar essas métricas na seção Recursos do vBucket na interface do usuário. Na captura de tela abaixo, vemos que os metadados ocupam cerca de 42% dos dados do bucket na memória:

Estatísticas de sobrecarga de metadados

Em um determinado momento, você pode começar a ver mensagens como as abaixo na interface do usuário e nos logs do Couchbase:

Aviso de sobrecarga de metadados

Com grande parte da cota de memória ocupada pelas chaves e metadados do documento, há pouco ou nenhum espaço para manter os valores do documento. Nesse caso, você verá o servidor fazendo muitas buscas em segundo plano para carregar dados do disco para a memória, apenas para serem ejetados em um futuro próximo, já que a memória disponível é muito pequena.

Se você não puder adicionar mais nós ao cluster e/ou realocar a memória de outros buckets, é recomendável mudar para o método de ejeção total do bucket em questão. Lembre-se: haverá algum tempo de inatividade enquanto seu bucket é reiniciado e passa pelo processo de aquecimento.

Resumo

• Somente valor ejection/eviction remove apenas os valores de documentos da memória, enquanto completo O despejo também remove as chaves e os metadados do documento.
• Você deve fazer um escolha informada do método de ejeção antes de colocar um balde em produção. Casos de uso de gravação pesada com muitos milhões de documentos são bons candidatos para a ejeção total. Alterar o método de ejeção posteriormente na produção pode ser dispendioso devido a algum tempo de inatividade.
• Upsert e os discos rápidos dedicados sempre melhoram o desempenho dos aplicativos, e isso é ainda mais importante para os buckets de ejeção total.
• Monitorar o balde sobrecarga de metadados. Esse é um bom indicador de que seu cluster pode estar precisando de mais RAM. Se você não conseguir obter mais memória para seu cluster do Couchbase e seu a sobrecarga de metadados é igual ou superior a 40%Se você não tiver um bucket de gravação, pode considerar mudar seus buckets grandes e pesados para ejeção total.