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
-
- 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.
- 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.
- 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
-
- Com base no plano final decidido na fase de planejamento, os índices são movidos de seus nós existentes para novos alvos.
- 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
-
- 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.
- 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ó
- Configuração do cluster:
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:
-
- Rebalanceamento de recomposição de índice (Rebalanceamento DCP) – Reconstrói os índices do zero durante o rebalanceamento.
- Rebalanceamento da transferência de arquivos – Transfere 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.
-
- Leia mais Novos recursos do Couchbase Server 7.6.