Quando um único nó de column store somente leitura não consegue mais acompanhar consultas analíticas extensas — seja pelo volume de dados, pela complexidade das consultas ou por varreduras simultâneas em tabelas do OSS — o processamento massivamente paralelo (MPP) de vários nós permite o scale-out com a adição de novos nós de column store somente leitura. O otimizador In-Memory Column Index (IMCI) distribui automaticamente as consultas elegíveis entre todos os nós do grupo de execução, aumentando a CPU disponível e o throughput de I/O sem exigir alterações no SQL.
Como funciona
O MPP de vários nós forma um grupo de execução composto por múltiplos nós de column store somente leitura. Para cada instrução SQL recebida, o otimizador IMCI decide se a executa em um único nó ou se a distribui pelo grupo.
Esse otimizador identifica com precisão o método de processamento transacional (TP) das instruções SQL e escolhe entre a execução em nó único ou a execução paralela em vários nós para cargas de trabalho de processamento analítico (AP) de grande porte.
Cenários
Aproveite a capacidade de dimensionamento do MPP de vários nós para aumentar os recursos de CPU e IOPS dedicados às consultas e reduzir a latência.
Processe consultas em memória distribuindo-as entre diversos nós para obter maior throughput.
Pré-requisitos
Antes de ativar o MPP de vários nós, verifique se seu cluster atende aos seguintes requisitos:
Um cluster PolarDB for MySQL Enterprise Edition
Versão 8.0.1, revisão 8.0.1.1.38 ou posterior
Pelo menos um nó de column store somente leitura adicionado ao cluster. Para obter instruções, consulte Adicionar um nó IMCI somente leitura.
Ative o MPP de vários nós
Para ativar e configure o MPP de vários nós, entre no grupo do DingTalk (ID: 27520023189) para obter suporte técnico.
Melhores práticas
Chaves de partição
O PolarDB oferece suporte a partições de nível 1 e nível 2 usando estratégias de particionamento HASH ou KEY. O MPP de vários nós utiliza uma estratégia share-nothing, na qual cada partição é atribuída a exatamente um nó. Isso significa que:
Cada nó armazena em cache apenas sua própria partição, melhorando a eficiência da memória.
As operações
JOINeGROUP BYnas chaves de partição são processadas localmente em cada nó, eliminando a transferência de dados entre nós.
Para tirar proveito disso:
Crie partições HASH ou KEY de nível 1 ou nível 2 nas colunas mais usadas em consultas com
JOINeGROUP BY.Mantenha a contagem de partições idêntica em todas as tabelas HASH e KEY. Se duas tabelas tiverem contagens diferentes, as operações
JOINentre elas exigirão transferência de dados entre nós e não poderão ser processadas localmente.Utilize um número primo grande como contagem de partições para reduzir a distribuição desigual de dados e melhorar a utilização dos recursos.
Chaves de ordenação
Para consultas que filtram grandes volumes de dados, crie partições RANGE ou adicione chaves de ordenação ao column store. Aplique partições RANGE e chaves de ordenação nas colunas presentes nos predicados da cláusula WHERE.
Por exemplo, para a condição de consulta WHERE date > '2024-10-01' AND date < '2024-10-07' AND customer_id = 'X231':
Crie partições RANGE na coluna
datepara ignorar partições inteiras de intervalo de datas durante a varredura.Adicione chaves de ordenação IMCI na coluna
customer_idpara pular segmentos de linhas que não correspondem ao predicado.
Em conjunto, essas técnicas reduzem o volume de dados a ser varrido e melhoram o tempo de resposta da consulta. Para mais informações, consulte Visão geral do IMCI e Configure chaves de ordenação para índices columnstore.
Verifique o uso do MPP de vários nós
A verificação do uso do MPP ocorre em duas etapas: primeiro, confirme se a consulta pode usar MPP; depois, verifique se o otimizador realmente escolheu o MPP para essa consulta.
Etapa 1: Verifique se uma consulta pode usar MPP
Adicione a dica SET_VAR(imci_plan_use_mpp=forced) para forçar o otimizador a gerar um plano de execução MPP. Se o plano resultante contiver um operador Exchange, a consulta suporta execução MPP de vários nós.
EXPLAIN SELECT /*+ SET_VAR(imci_plan_use_mpp=forced) */ COUNT(*) FROM nation;
Saída de exemplo:
+----+----------------------------+--------+---------------------------------------------------------------------------------+
| ID | Operator | Name | Extra Info |
+----+----------------------------+--------+---------------------------------------------------------------------------------+
| 1 | Select Statement | | IMCI Execution Plan (max_dop = 11, max_query_mem = 37438953472) |
| 2 | └─Compute Scalar | | |
| 3 | └─Aggregation | | |
| 4 | └─Consume | | Consume ProducerPipeId: 1 |
| 5 | └─Exchange | | PipeId: 1, Consumers: 23377031, Producers: 23377031,23377032, Part Type: Gather |
| 6 | └─Aggregation | | |
| 7 | └─Table Scan | nation | |
+----+----------------------------+--------+---------------------------------------------------------------------------------+
O operador Exchange na linha 5 confirma que a consulta pode ser executada em paralelo em vários nós.
Etapa 2: Verifique se o otimizador escolhe o MPP sem forçá-lo
Após confirmar que uma instrução SQL pode ser executada com o MPP de vários nós, visualize o plano de execução dessa instrução para verificar se o MPP será efetivamente utilizado. Caso o plano contenha o operador Exchange, a instrução SQL será executada em paralelo usando o MPP de vários nós.
Resultados de testes de desempenho
Para resultados de benchmarks em diferentes configurações de nós, consulte Desempenho do IMCI.