O dimensionamento mais rápido dos recursos do banco de dados é essencial para a manutenção de bancos de dados eficientes e de alto desempenho, especialmente com a pressão cada vez maior da ingestão de dados, o aumento das demandas de consulta e a necessidade de lidar com failovers sem problemas. Como o tráfego de consultas orientadas por aplicativos é tratado principalmente por serviços de índice, o dimensionamento mais rápido dos serviços de rebalanceamento de índices é essencial para aplicativos de alto desempenho.

Para o serviço de índice, a operação de dimensionamento (também chamada de reequilíbrio) envolve a movimentação de índices/replicas/partições individuais entre os nós de serviço de índice disponíveis no cluster. O objetivo é minimizar os desequilíbrios de carga e otimizar as métricas de utilização de recursos, como CPU e memória, em todos os nós.

Este artigo explora as limitações e os aprimoramentos feitos no processo de rebalanceamento de índices no Couchbase-Server versão 7.6. Ele apresenta um novo fluxo de rebalanceamento baseado em transferências eficientes de arquivos, oferecendo benefícios significativos, como reduções substanciais no tempo de rebalanceamento e utilização otimizada de recursos, incluindo menor consumo de CPU e memória.

 

Visão geral do rebalanceamento do serviço de índice

Em um nível elevado, o reequilíbrio do serviço de índice opera em três fases:

Planejamento

    1. No fase de planejamentoEm um cluster, as informações de todos os índices em todos os nós do cluster são reunidas, juntamente com suas estatísticas de carga. A carga de um índice é derivada de vários fatores, como utilização da CPU, utilização da memória, taxa de varredura, taxa de processamento de mutação, utilização de disco etc.
    2. Um algoritmo de otimização é usado para minimizar a variação de carga no cluster. Por exemplo, se um nó de serviço de índice tiver um tráfego de mutação e varredura significativamente maior em comparação com os outros, o algoritmo redistribuirá os índices para equilibrar a carga geral e reduzir a variação.
    3. O algoritmo de otimização decide os movimentos do índice de seus nós existentes para novos nós em um ambiente simulado para chegar a uma distribuição que minimize a variação de carga no cluster.

Fase de execução

    1. Com base no plano final decidido na fase de planejamento, os índices são movidos de seus nós existentes para novos alvos.
    2. Essa fase é o fator que mais contribui para o tempo de rebalanceamento do índice, diretamente afetado pelo método de movimentação e pelo número de índices envolvidos.

Eliminação de índices nos nós de origem

    1. Quando os índices nos novos nós de destino estiverem totalmente reconstruídos e prontos para lidar com as consultas, todas as solicitações de varredura de entrada para esses índices serão redirecionadas para os novos nós.
    2. Os índices nos nós de origem existentes serão removidos assim que os índices correspondentes nos novos nós estiverem prontos para atender ao tráfego de varredura.

O Fase de execuçãoAtualmente, o sistema de indexação de dados da Microsoft, Inc., depende da reconstrução dos índices que estão sendo movidos por meio do re-streaming e do reprocessamento de todos os documentos do serviço de dados. Embora esse esquema funcione bem em termos funcionais, ele tem as seguintes desvantagens:

    • Aumento do tempo de rebalanceamento do índice
    • Varreduras mais lentas 
    • Processamento de mutação mais lento

Essas desvantagens se devem principalmente a:

Sobrecarga de recursos durante o rebalanceamento

    • O serviço de dados precisa fazer o restreaming de todos os documentos relevantes para o índice com o objetivo de reconstruir os índices. Muitas vezes, o restreaming de todos os dados exige o backfilling do disco, o que pode levar a uma pressão adicional no disco
    • O processo do projetor precisa reprocessar todos os documentos para extrair dados relevantes para esse índice, o que pode consumir mais CPU e memória. Essas despesas gerais também podem criar contenção de recursos para o tráfego incremental dos índices existentes.
    • Também para o processo do indexador, as compilações de índices adicionam sobrecargas consideráveis de recursos na CPU, memória e E/S de disco devido ao novo tráfego de mutação recebido. Em geral, são necessárias operações de leitura de E/S aleatórias durante determinados estágios da criação de índices, o que torna mais lento todo o pipeline de criação de índices.

Interrupção do conjunto de trabalho 

    • Os requisitos de memória devido à reconstrução do índice durante a redução da memória disponível para os índices existentes
    • O conjunto de trabalho dos índices existentes pode ser removido da memória
    • Isso faz com que as varreduras e o processamento de mutação fiquem mais lentos se os dados relevantes não estiverem disponíveis na memória e precisarem ser buscados no disco

Rebalanceamento da transferência de arquivos

O rebalanceamento de transferência de arquivos é uma abordagem para reduzir a sobrecarga de reconstrução de índices. Em vez de reconstruir os índices, o nó de origem transfere diretamente os arquivos de dados indexados para o nó de destino sem interagir com o serviço de dados. Depois que a transferência de dados for concluída, o serviço de índice acompanhará as mutações que ocorreram durante a transferência, transmitindo-as do serviço de dados. As varreduras e mutações continuarão a ser processadas para os índices existentes, independentemente do status da transferência.

A transferência de dados entre os nós de origem e de destino ocorre por meio de um protocolo personalizado criado com base no modelo de solicitação-resposta HTTP. O nó de origem contém um cliente capaz de ler sequencialmente dados indexados com instantâneos do disco e publicar os dados no nó de destino como vários blobs binários pequenos. A transferência de dados é sempre criptografada. O nó de destino hospeda um servidor que recebe esses blobs binários, descriptografa-os e reconstrói os dados indexados durante o processo de transferência. Todos os dados recebidos pelo servidor no nó de destino são armazenados de forma persistente no disco.

Após a conclusão da transferência de dados, o nó de destino recupera o índice do disco e reverte para um ponto de recuperação válido disponível nos dados transferidos. Em seguida, ele solicita que o serviço de dados transmita as mutações que ocorreram desde a geração desse ponto de recuperação. Quando todas as mutações necessárias forem processadas, o índice se tornará pronto para digitalização no nó de destino e, posteriormente, é descartado do nó de origem.

Como a maioria dos dados indexados é transferida diretamente, ignorando a necessidade de reconstrução, a sobrecarga associada às reconstruções de índices é eliminada durante a transferência de dados. Isso melhorou significativamente a velocidade de rebalanceamento e reduziu o consumo associado de CPU e memória. Como resultado, o impacto sobre o conjunto de trabalho também é mínimo, permitindo que as varreduras e o tráfego de mutação sejam processados em taxas semelhantes às de antes do rebalanceamento.

As únicas despesas gerais de recursos incorridas com as transferências de arquivos são aquelas relacionadas à própria transferência de dados e à recuperação de quaisquer mutações que possam ter ocorrido durante o processo de transferência. A utilização de recursos durante a transferência de dados e o processo de recuperação pode ser dividida da seguinte forma:

    • Largura de banda de leitura de disco (nó de origem)Eficiente, devido às leituras sequenciais.
    • CPU e memória (nó de origem)Mínimo, devido à publicação de pequenos blobs binários.
    • CPU e memória (nó de destino)Mínimo, devido ao processamento de pequenos blobs binários.
    • Largura de banda de gravação em disco (nó de destino)Eficiente, devido às gravações principalmente sequenciais.
    • Largura de banda de leitura de disco (recuperação, nó de destino) Mínimo, pois apenas uma parte dos dados precisa de recuperação.

Para minimizar as interrupções nas operações críticas de varredura e mutação, os nós de origem e de destino restringem a largura de banda do disco a um valor configurável, com padrão de 200 MB/s, durante o rebalanceamento. Essa taxa escolhida empiricamente garante eficiência equilibrada e impacto mínimo no desempenho, com consumo de recursos observado de menos de 2 núcleos de CPU e dezenas de MB de memória por nó. 

Resultados de desempenho com rebalanceamento de transferência de arquivos

Configuração de benchmark

    • Configuração do cluster:
      • Nós de serviço de dados: 4
      • Nós de índice: 3
    • Dados:
      • Volume: 1 bilhão de documentos
      • Tamanho médio do documento: 230 bytes
      • Distribuição: Compartilhado em 2 coleções em um único bucket
    • Índices:
      • Tipo: Particionado
      • Replicação: 1 réplica por índice
      • Número de partições: 3 por índice
      • Total de instâncias: 18 (3 índices * 3 partições * 2 réplicas)
      • Tamanho médio do campo do índice secundário: 140 bytes
      • Uso total do disco: ~710GB (em todas as instâncias)
    • Recursos de serviço de índice:
      • Cota de memória: 128 GB por nó
      • Núcleos de CPU: 80 por nó

Comparação

Esse benchmark de desempenho compara dois métodos de rebalanceamento para tempos de rebalanceamento, CPU e utilização de memória para o caso de rebalanceamento de swap:

    1. Rebalanceamento de recomposição de índice (Rebalanceamento DCP) Reconstrói os índices do zero durante o rebalanceamento.
    2. Rebalanceamento da transferência de arquivosTransfere diretamente os arquivos de dados de índice existentes entre os nós.

Troca de saldo

    • Começamos com 2 nós de índice no cluster, cada um com cerca de 355 GB de dados indexados em 9 instâncias de índice em cada nó.
    • Adicionamos um novo nó de índice e removemos um existente.
    • Todos os dados indexados do nó removido são transferidos para o nó recém-adicionado.
    • O tráfego de varredura continua a atingir os nós iniciais até que a transferência de dados seja concluída.

Comparação do tempo de rebalanceamento do swap

Rebalanceamento da transferência de arquivos concluído em apenas 37 minutosem comparação com um impressionante 272 minutos com o método tradicional de rebalanceamento do DCP. Isso representa um Melhoria de 7x em velocidade! Essa eficiência se deve em grande parte à transferência direta de arquivos de dados, em vez de reconstruí-los inteiramente. Embora a transferência de dados em si, teoricamente, leve cerca de 29,6 minutos (supondo 200 MB/s sustentados), o tempo total de rebalanceamento se alinha bem com o tempo real de rebalanceamento de ponta a ponta (incluindo as fases de planejamento e recuperação).

Reequilibrar a comparação da CPU

O rebalanceamento do DCP consome significativamente mais recursos da CPU em comparação com o rebalanceamento da transferência de arquivos. Isso ocorre porque o processo do indexador precisa reconstruir todas as mutações transmitidas pelo serviço de dados, o que é um processo computacionalmente intensivo. Por outro lado, o rebalanceamento da transferência de arquivos tem um consumo de CPU muito menor, com picos ocasionais no uso da CPU durante a fase de recuperação após a transferência de dados.

Comparação de memória de reequilíbrio

O rebalanceamento do DCP também exige muito mais memória em comparação com o rebalanceamento da transferência de arquivos. Durante o processo de reconstrução, o processo do indexador precisa alocar e gerenciar constantemente a memória para todas as mutações recebidas, o que leva a uma pressão significativa sobre os recursos disponíveis. No entanto, o rebalanceamento da transferência de arquivos funciona de forma diferente. Como transfere diretamente os arquivos de dados para o disco em vez de reconstruir tudo na memória, ele requer apenas uma quantidade mínima de memória para processamento, reduzindo significativamente as demandas gerais de memória.

Reequilibrar o tempo de utilização de E/S do disco

O rebalanceamento da transferência de arquivos mantém uma taxa de E/S de disco estável durante todo o processo, graças à velocidade de transferência controlada. Esse estrangulamento garante uma eficiência equilibrada e minimiza o impacto no desempenho. Podem ocorrer picos ocasionais durante a fase de recuperação onde as mutações são processadas, mas, de modo geral, a E/S do disco permanece estável. Em contrapartida, o rebalanceamento do DCP sofre de saturação quase constante de E/S do disco devido à sua abordagem de reconstrução pesada, o que pode levar a gargalos de desempenho.

 

Reequilibrar a largura de banda de transferência no nó de origem

Embora o DCP aproveite um puxar em que os nós de destino recuperam os dados diretamente, a transferência de arquivos se baseia na nó de origem empurrando ativamente os dados para fora. Isso resulta em um nitidamente maior out_bytes_per_second métrica (dados enviados) para o nó de origem durante o rebalanceamento da transferência de arquivos. No rebalanceamento do DCP, essa métrica cai perto de zero se nenhuma varredura estiver sendo executada ativamente, pois a extração de dados ocorre somente sob demanda.

Outras comparações de tempo de rebalanceamento

Discutimos anteriormente a impressionante economia de tempo obtida durante as operações de troca de rebalanceamento (movimentação de dados diretamente entre os nós que estão sendo adicionados e removidos). Temos o prazer de informar ganhos semelhantes em dois outros cenários: rebalanceamento (adicionando novos nós de índice e redistribuindo índices para eles) e rebalanceamento (removendo os nós de índice e redistribuindo seus índices para os nós restantes). A tabela abaixo resume as melhorias gerais no tempo de rebalanceamento observadas em uma configuração semelhante à descrita anteriormente.

Tipo de rebalanceamento Tempo de rebalanceamento do DCP (min) Tempo de reequilíbrio da transferência de arquivos (min)
Rebalanceamento (2 nós → 3 nós) 123,6 min 12,3 min
Rebalanceamento (3 nós → 2 nós) 144,7 min 36,3 min

Ativação do reequilíbrio da transferência de arquivos

O reequilíbrio da transferência de arquivos é ativado por padrão nas implementações do Capella. Para implementações auto-hospedadas, ele deve ser ativado manualmente pelo usuário final (na interface do usuário ou usando solicitações de linha de comando). Mais detalhes estão disponíveis na seção documentação de rebalanceamento.

Resumo

O método tradicional de rebalanceamento do Couchbase Index Service sofre com o alto uso de recursos e com os longos tempos de rebalanceamento devido à reconstrução do índice. O novo rebalanceamento de transferência de arquivos resolve esse problema transferindo diretamente os arquivos de dados entre os nós, reduzindo significativamente a sobrecarga de recursos (CPU, memória, E/S de disco) e os tempos de rebalanceamento. Os tempos de rebalanceamento do índice melhoraram em até 7 vezes em alguns casos, como o rebalanceamento de swap. Isso se traduz em dimensionamento mais rápido, melhor desempenho do aplicativo e utilização mais eficiente dos recursos do cluster.

Autor

Postado por Varun Velamuri, engenheiro principal

Varun Velamuri é engenheiro principal da equipe de indexação secundária global da Couchbase. Ele tem experiência em trabalhar com tecnologias relacionadas à programação simultânea, sistemas paralelos e distribuídos, bancos de dados distribuídos, otimizações de desempenho etc. Antes da Couchbase, ele trabalhou como engenheiro líder de pesquisa nos Laboratórios de Sistemas Paralelos da Siemens Research, em Bangalore, concentrando-se em tecnologias relacionadas à programação paralela e simultânea, ferramentas de correção para programação multithread, processamento de eventos distribuídos etc.

Deixar uma resposta