Controle de admissão de consulta no Couchbase Analytics

O Couchbase Analytics é otimizado para executar consultas analíticas ad-hoc, que normalmente processam mais dados do que cabem na memória. Ele emprega um mecanismo de processamento massivamente paralelo (MPP) que tenta utilizar totalmente a capacidade de processamento disponível em qualquer nó que esteja executando o serviço Analytics em um cluster do Couchbase. Ao mesmo tempo, o mecanismo garante que ele opere dentro do orçamento de memória alocado para o serviço do Analytics em cada nó. Para isso, o serviço do Analytics tem um recurso de controle de admissão de consultas que decide quais consultas podem ser executadas simultaneamente. Neste artigo, explicamos os princípios básicos do funcionamento do mecanismo de controle de admissão de consultas do Analytics e damos alguns exemplos.

O controlador de admissão de consultas do Analytics decide se uma consulta recém-recebida pode ser executada imediatamente, se precisa ser enfileirada ou se deve ser rejeitada. As decisões são tomadas com base em 1) os recursos disponíveis para o serviço do Analytics e 2) os recursos exigidos por uma determinada consulta. A seguir, explicamos como cada um deles é calculado.

Recursos disponíveis do Analytics:

O Analytics mantém um pool de recursos com o seguinte:

Memória total disponível para processamento de consultas:
Por padrão, o Analytics dedica 50% da memória alocada para o serviço Analytics em cada nó para o processamento de consultas. Os outros 50% são usados para outras áreas, como o cache do buffer de armazenamento e o pipeline de ingestão. A soma dos 50% de memória em cada nó nos dará o total de memória disponível para o processamento de consultas no Analytics.
Por exemplo, se um cluster tiver três nós executando o serviço Analytics, cada um com 16 GB de memória, então:

Total de trabalhadores de consulta:
O Analytics usa o número de núcleos informado pelo sistema operacional para determinar o número de núcleos em cada nó do Analytics. A soma do número de núcleos em cada nó e a multiplicação pelo valor de coresMultiplier nos dá o número total de trabalhadores de consulta disponíveis para o processamento de consultas. Como as consultas analíticas ad-hoc tendem a ser vinculadas à E/S, um núcleo de CPU pode participar do processamento de outras consultas simultâneas enquanto outra consulta está aguardando E/S. O coresMultiplier, que é um parâmetro configurável no serviço Analytics, que tem um valor padrão de 3, permite que você especifique esse nível de simultaneidade por núcleo para garantir que cada núcleo tenha trabalho suficiente para se manter ocupado.
Por exemplo, se um cluster tiver três nós com o serviço Analytics e cada um tiver 8 núcleos e coresMultiplier estiver definido como 3, então:

Consultar recursos necessários:

Quando uma nova consulta é recebida pelo processador de consultas do Analytics, o compilador de consultas determina os recursos necessários para processar a consulta em termos de memória e operadores de consultas:

Memória necessária:
A memória necessária para qualquer consulta varia de acordo com a natureza da consulta. Por exemplo, uma consulta que exige a classificação do resultado normalmente requer mais memória do que uma consulta simples que conta apenas o número de documentos em uma coleção ou recupera documentos em um pequeno intervalo de valores para algum campo. O compilador de consultas do Analytics examina todas as operações envolvidas em uma consulta e determina a memória máxima exigida por cada consulta.

Trabalhadores de consulta necessários:
Uma implantação típica do Analytics tem uma partição de dados (shard) por núcleo em cada nó. Como o Analytics tenta processar dados em todas as partições de dados em um cluster em paralelo, os trabalhadores de consulta necessários para qualquer consulta que exija acesso a dados é igual ao número de partições de dados.

Por exemplo, uma consulta que tenta contar todos os documentos em uma coleção em um cluster que tem 24 partições de dados exigirá o uso de 24 trabalhadores de consulta.

Exemplos:

Nos exemplos abaixo, supomos um cluster do Couchbase com 3 nós executando o serviço Analytics com 16 GB de memória e 8 núcleos em cada um.

Exemplo 1:
coresMultiplier = 3
Memória total disponível = 48 GB
Total de trabalhadores de consulta disponíveis = (8 + 8 + 8) * 3 = 72 trabalhadores
Número de consultas simultâneas recebidas = 5 (cada uma exigindo 2 GB de memória e 24 trabalhadores)

O Analytics executará 3 consultas simultaneamente e enfileirará as consultas 4 e 5, pois o cluster tem apenas 72 trabalhadores de consulta disponíveis e cada consulta requer 24 trabalhadores. Quando uma das três primeiras consultas for concluída, uma das consultas em fila será executada. (Observação: não ajudaria no desempenho admitir imediatamente, em vez de enfileirar, as consultas 4 e 5, pois o sistema tem trabalho suficiente para se manter ocupado com as três primeiras. Tentar fazer mais de uma vez não aceleraria as coisas e, de fato, poderia levar a uma contenção de recursos contraproducente).

Exemplo 2:
coresMultiplier = 3
Memória total disponível = 48 GB
Total de trabalhadores de consulta disponíveis = (8 + 8 + 8) * 3 = 72 trabalhadores
Número de consultas simultâneas recebidas = 3 (cada uma exigindo 20 GB de memória e 24 trabalhadores)

O Analytics executará duas consultas simultaneamente e enfileirará a terceira consulta, pois não temos memória suficiente para executar as três simultaneamente. (Observação: tentar fazer mais, reduzindo a memória alocada para cada consulta, provavelmente levaria a mais derramamento de dados, maior custo de E/S e, portanto, menor desempenho).

Exemplo 3:
coresMultiplier = 3
Memória total disponível = 48 GB
Total de trabalhadores de consulta disponíveis = (8 + 8 + 8) * 3 = 72 trabalhadores
Número de consultas simultâneas recebidas = 1 (exigindo 50 GB de memória e 24 trabalhadores)

O Analytics rejeitará a consulta, pois não tem memória suficiente para executá-la. Observe que a adição de um nó adicional do Analytics ao cluster aumentará os recursos disponíveis e poderá tornar possível a execução dessa consulta. (Observação: também é possível usar uma dica de consulta para direcionar uma consulta para alocar menos memória para os operadores da consulta, permitindo que a consulta seja executada, embora com um custo de E/S mais alto).

Exemplo 4:
coresMultiplier = 5
Memória total disponível = 48 GB
Total de trabalhadores de consulta disponíveis = (8 + 8 + 8) * 5 = 120 trabalhadores
Número de consultas simultâneas recebidas = 5 (cada uma exigindo 2 GB de memória e 24 trabalhadores)

O Analytics executará todas as 5 consultas simultaneamente, pois temos memória e trabalhadores de consulta suficientes. É importante observar que, embora o aumento do valor de coresMultiplier permita que mais consultas sejam executadas simultaneamente, isso pode resultar em uma taxa de transferência geral mais baixa se o armazenamento subjacente não puder lidar com as solicitações de E/S simultâneas ou se os núcleos da CPU começarem a falhar, conforme mencionado acima. Portanto, talvez seja necessário fazer um exercício de ajuste cuidadoso com base nos recursos disponíveis e na natureza da carga de trabalho ao ajustar o parâmetro coresMultiplier.

Conclusão:

Neste artigo, explicamos como funciona a lógica de controle de admissão de consultas do serviço Analytics e os fatores que ela usa para tomar decisões de admissão de consultas. Também explicamos como o parâmetro coresMultiplier pode ser usado para permitir a execução simultânea de mais consultas e as consequências da alteração de seu valor.