PolarDB:Use o recurso Elastic Parallel Query para executar consultas analíticas

Como funciona

O Elastic Parallel Query utiliza dois tipos de nós:

• Nó coordenador de consulta (QC): recebe a solicitação de consulta, divide o plano de execução em shards, encaminha os shards para os nós de execução paralela (PX) e agrega os resultados.

• Nós PX: cada nó executa um shard atribuído, lê blocos de dados do sistema de armazenamento compartilhado Polar File System (PolarFS) e retorna os resultados ao nó QC.

Na figura acima, RO1 é o nó QC, enquanto RO2, RO3 e RO4 são nós PX. O RO1 divide o plano de execução em três shards e os distribui. Cada nó PX lê dados do PolarFS e envia os resultados de volta ao RO1, que os combina para gerar o resultado final.

Observações de uso

O Elastic Parallel Query vem desativado por padrão e exige múltiplos nós somente leitura. Seu uso é recomendado apenas para consultas analíticas executadas com baixa frequência.

Parâmetros

Configure os parâmetros a seguir para ativar e ajustar o Elastic Parallel Query.

Considerações importantes:

• polar_enable_px: defina como on antes que qualquer outra configuração tenha efeito. Configure-o no nível do sistema para ativar o recurso globalmente ou no nível da sessão para restringi-lo a cargas de trabalho específicas.

• `polar_px_dop_per_node`: valores muito altos em nós com sessões simultâneas multiplicam o uso de processos de trabalho. Cada sessão pode consumir até polar_px_dop_per_node trabalhadores por nó; portanto, o uso total = DoP x número de sessões ativas. Certifique-se de que o total não exceda polar_px_max_workers_number.

• polar_px_enable_replay_wait: defina como on somente quando sua carga de trabalho envolver alterações recentes de DDL (como CREATE TABLE) ainda não reexecutadas pelos nós somente leitura. Para cargas analíticas com muitas leituras e sem atividade recente de DDL, mantenha este valor como off para evitar sobrecarga de reexecução.

• px_workers: utilize este parâmetro para limitar o Elastic Parallel Query a tabelas específicas de alto valor, em vez de ativá-lo globalmente. Essa abordagem reduz o consumo desnecessário de recursos em tabelas que não se beneficiam do paralelismo.

Controle o paralelismo nos níveis de sistema, sessão e consulta

Ative e ajuste o Elastic Parallel Query em três níveis. A escolha depende do seu caso de uso:

• System level: aplique o Elastic Parallel Query globalmente para todas as consultas e sessões. Recomendado quando seu cluster é dedicado a cargas de trabalho analíticas.

• Session level: ative, desative ou force o Elastic Parallel Query para a conexão atual. Ideal para consultas analíticas ad hoc em um cluster com carga de trabalho mista.

• Query level: substitua o paralelismo para uma única consulta usando dicas. Use esta opção para otimização pontual de consultas específicas sem alterar os padrões da sessão ou do sistema.

postgres=# alter system set polar_enable_px=1;
ALTER SYSTEM
postgres=# alter system set polar_px_dop_per_node=1;
ALTER SYSTEM
postgres=# select pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)
postgres=# \c postgres
You are now connected to database "postgres" as user "postgres".

postgres=# drop table if exists t1;
DROP TABLE
postgres=# select id into t1 from generate_series(1, 1000) as id order by id desc;
SELECT 1000
postgres=# alter table t1 set (px_workers=1);
ALTER TABLE
postgres=# explain (verbose, costs off)   select * from t1 where id < 10;
                QUERY PLAN
-------------------------------------------
 PX Coordinator 2:1  (slice1; segments: 2)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

ALTER SESSION ENABLE PARALLEL QUERY
ALTER SESSION DISABLE PARALLEL QUERY
ALTER SESSION FORCE PARALLEL QUERY [PARALLEL integer]

--enable
postgres=# set polar_enable_px = false;
SET
postgres=# set polar_px_enable_hint = true;
SET
postgres=# alter session enable parallel query;
ALTER SESSION

postgres=# explain (verbose, costs off)   select /*+ PARALLEL(4)*/ * from t1 where id < 10;
INFO:  [HINTS] PX PARALLEL(4) accepted.
                QUERY PLAN
-------------------------------------------
 PX Coordinator 8:1  (slice1; segments: 8)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

--disable
postgres=# set polar_enable_px = false;
SET
postgres=# set polar_px_enable_hint = true;
SET
postgres=# alter session disable parallel query;
ALTER SESSION

postgres=# explain (verbose, costs off)   select /*+ PARALLEL(4)*/ * from t1 where id < 10;
       QUERY PLAN
------------------------
 Seq Scan on public.t1
   Output: id
   Filter: (t1.id < 10)
(3 rows)

--force
postgres=# set polar_enable_px = false;
SET
postgres=# set polar_px_enable_hint = false;
SET
postgres=# alter session force parallel query;
ALTER SESSION

postgres=# explain (verbose, costs off)   select * from t1 where id < 10;
           QUERY PLAN
-------------------------------------------
 PX Coordinator 2:1  (slice1; segments: 2)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

postgres=# alter session force parallel query parallel 2;
ALTER SESSION
postgres=# explain (verbose, costs off)   select * from t1 where id < 10;
                QUERY PLAN
-------------------------------------------
 PX Coordinator 4:1  (slice1; segments: 4)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

postgres=# set polar_enable_px = true;
SET
postgres=# set polar_px_dop_per_node = 1;
SET
postgres=# explain (verbose, costs off)   select * from t1 where id < 10;
                QUERY PLAN
-------------------------------------------
 PX Coordinator 2:1  (slice1; segments: 2)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

set polar_px_enable_hint = true;  -- default: false

/*+ PARALLEL(DEFAULT) */   -- use the DoP from polar_px_dop_per_node
/*+ PARALLEL(integer) */   -- use the specified DoP
/*+ NO_PARALLEL(tablename) */  -- disable Elastic Parallel Query for the specified table

postgres=# set polar_enable_px = false;
SET
postgres=# set polar_px_dop_per_node = 1;
SET
postgres=# set polar_px_enable_hint = true;
SET
postgres=# explain (verbose, costs off)   select * from t1 where id < 10;
       QUERY PLAN
------------------------
 Seq Scan on public.t1
   Output: id
   Filter: (t1.id < 10)
(3 rows)

postgres=# explain (verbose, costs off)   select /*+ PARALLEL(DEFAULT) */ * from t1 where id < 10;
                QUERY PLAN
-------------------------------------------
 PX Coordinator 2:1  (slice1; segments: 2)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

postgres=# explain (verbose, costs off)   select /*+ PARALLEL(4) */ * from t1 where id < 10;
                QUERY PLAN
-------------------------------------------
 PX Coordinator 8:1  (slice1; segments: 8)
   Output: id
   ->  Partial Seq Scan on public.t1
         Output: id
         Filter: (t1.id < 10)
 Optimizer: PolarDB PX Optimizer
(6 rows)

postgres=# explain (verbose, costs off)   select /*+ PARALLEL(0) */ * from t1 where id < 10;
       QUERY PLAN
------------------------
 Seq Scan on public.t1
   Output: id
   Filter: (t1.id < 10)
(3 rows)

postgres=# explain (verbose, costs off)   select /*+ NO_PARALLEL(t1) */ * from t1 where id < 10;
       QUERY PLAN
------------------------
 Seq Scan on public.t1
   Output: id
   Filter: (t1.id < 10)
(3 rows)

Exemplo: ativar o Elastic Parallel Query para uma tabela

O exemplo a seguir demonstra o efeito do Elastic Parallel Query em uma consulta de tabela única.

Crie uma tabela de teste com um milhão de linhas:

CREATE TABLE test(id int);
INSERT INTO test SELECT generate_series(1,1000000);
EXPLAIN SELECT * FROM test;

Por padrão, o Elastic Parallel Query está desativado e o planejador usa uma varredura sequencial:

                       QUERY PLAN
--------------------------------------------------------
 Seq Scan on test  (cost=0.00..35.50 rows=2550 width=4)
(1 row)

Ative o Elastic Parallel Query para a tabela e execute a consulta novamente:

ALTER TABLE test SET (px_workers=1);
SET polar_enable_px=on;
EXPLAIN SELECT * FROM test;

O plano agora usa um PX Coordinator, confirmando que a execução paralela está ativa:

QUERY PLAN
-------------------------------------------------------------------------------
 PX Coordinator 2:1  (slice1; segments: 2)  (cost=0.00..431.00 rows=1 width=4)
   ->  Seq Scan on test (scan partial)  (cost=0.00..431.00 rows=1 width=4)
 Optimizer: PolarDB PX Optimizer
(3 rows)

Para consultar os nós somente leitura disponíveis e atribuir nós específicos para o Elastic Parallel Query:

-- List all read-only nodes
SHOW polar_cluster_map;
 polar_cluster_map
-------------------
  node1,node2,node3
(1 row)

-- Use only node1 and node2
SET polar_px_nodes='node1,node2';

SHOW polar_px_nodes;
 polar_px_nodes
----------------
  node1,node2
(1 row)

Dados de desempenho

Os resultados a seguir foram obtidos em um teste utilizando cinco nós somente leitura:

• Varredura completa de tabela (SELECT COUNT(*)): o Elastic Parallel Query foi 60 vezes mais rápido que a execução paralela em um único nó.

• Consultas TPC-H: o Elastic Parallel Query apresentou desempenho 30 vezes superior à execução paralela em um único nó.

Este teste baseia-se no benchmark TPC-H, mas não atende a todos os requisitos oficiais desse benchmark. Os resultados podem não ser diretamente comparáveis aos resultados publicados do benchmark TPC-H.