Clusters elásticos no Banco de Dados do Azure para PostgreSQL

Os clusters elásticos no serviço banco de dados do Azure para PostgreSQL são uma oferta gerenciada da extensão de código aberto Citus para PostgreSQL que permite a fragmentação horizontal do PostgreSQL.

Embora o Citus seja apenas uma extensão, ele conecta várias instâncias do PostgreSQL. Quando uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL é implantada com o Citus, ela manipula o gerenciamento e a configuração de várias instâncias do PostgreSQL como um único recurso. Ela também configura automaticamente os nós e os torna conhecidos pela extensão Citus.

Os clusters elásticos no serviço oferecem dois modelos de fragmentação: fragmentação baseada em linha e fragmentação baseada em esquema. Verifique a documentação de código aberto sobre modelos de fragmentação, caso queira saber mais.

Arquitetura

Um cluster elástico consiste em um ou mais nós de instâncias de servidor flexíveis do Azure Database para PostgreSQL. Essas instâncias são automaticamente conhecidas umas das outras e interconectadas para formar um cluster do Citus. Os nós devem ser da mesma camada de computação e armazenamento e podem ser escalados ou reduzidos verticalmente de forma uniforme para camadas mais altas ou baixas.

Os clusters elásticos usam instâncias de servidores flexíveis (chamados de nós) para coordenar uns com os outros em uma arquitetura de "nada compartilhado". A arquitetura também permite que o banco de dados seja dimensionado, adicionando mais nós ao grupo de servidores.

Conectar-se ao cluster usando a porta 5432 coloca você no nó coordenador designado. Os clusters elásticos também permitem que você faça balanceamento de carga de conexões em todo o cluster, usando um método de hash de cinco tuplas, se você se conectar usando a porta 7432. Usando a 7432, você ainda pode chegar no nó atualmente designado como coordenador. Para determinadas operações em todo o cluster, como distribuir tabelas, talvez seja necessário se conectar pela porta 5432. É altamente recomendável que você sempre se conecte na porta 5432, quando planeja executar atualizações de esquema de aplicativo e alterações semelhantes. Se você habilitar o PgBouncer em clusters elásticos, poderá usar a porta 8432 para balancear a carga de conexões entre instâncias pgBouncer em cada nó (ou usar a porta 6432 para o coordenador designado).

Ao contrário do Cosmos DB para PostgreSQL, os endereços do nó não são expostos externamente. Se você examinar tabelas de metadados do Citus como pg_dist_node, poderá observar que todos os nós têm o mesmo endereço IP que no exemplo 10.7.0.254, mas números de porta diferentes.

select nodeid, nodename, nodeport from pg_dist_node;

 nodeid |  nodename  | nodeport
--------+------------+----------
      1 | 10.7.0.254 |     7000
      2 | 10.7.0.254 |     7001
 
(2 rows)

Na infraestrutura do Azure, esses nós residem em máquinas virtuais diferentes, embora possam parecer portas diferentes no mesmo computador.

Para saber mais sobre o Citus, você pode consultar a documentação oficial do projeto de código aberto.

Por padrão, tabelas e esquemas criados com Citus não são distribuídos automaticamente entre o cluster. Você precisará decidir sobre um modelo de fragmentação e decidir distribuir esquemas ou distribuir os dados da tabela com fragmentação baseada em linha.

Para cada consulta em tabelas distribuídas, o nó consultado o roteia para um único nó ou o paraleliza em vários nós. A decisão depende se os dados necessários residem em um único nó ou em vários. Com a fragmentação baseada em esquema, o coordenador encaminha as consultas diretamente para o nó que hospeda o esquema. Em ambos, na fragmentação baseada em esquema e na fragmentação baseada em linha, o nó decide o que fazer consultando as tabelas de metadados. Essas tabelas acompanham o local e a integridade dos nós e a distribuição de dados entre nós.

Depois que os dados são distribuídos usando um dos modelos de fragmentação, você poderá se conectar a qualquer um dos nós para executar operações DML (Linguagem de Manipulação de Dados) (SELECT, UPDATE, INSERT, DELETE). Todos os nós contêm os metadados necessários para localizar os dados necessários para a consulta e podem obtê-los para responder à consulta.

Atualmente, as operações DDL (Linguagem de Definição de Dados) e operações em todo o cluster estão limitadas ao nó que mantém a função de coordenador. Certifique-se de executar operações DDL e em todo o cluster conectando-se à porta 5432, em vez de usar a porta 7432.

Você pode escalar horizontalmente um cluster elástico adicionando novos nós e reequilibrando os dados nele. O rebalanceamento é uma operação online e não impede a execução de cargas de trabalho.

Fragmentos

A seção anterior descreveu como as tabelas distribuídas são armazenadas como fragmentos em nós de trabalho. Esta seção discute mais detalhes técnicos sobre esses fragmentos.

A tabela de metadados pg_dist_shard contém uma linha para cada fragmento de cada tabela distribuída no sistema. A linha corresponde a um identificador de fragmento (shardid) com um intervalo de inteiros em um espaço de hash (shardminvalue, shardmaxvalue).

SELECT * from pg_dist_shard;

logicalrelid  | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
 github_events |  102026 | t            | 268435456     | 402653183
 github_events |  102027 | t            | 402653184     | 536870911
 github_events |  102028 | t            | 536870912     | 671088639
 github_events |  102029 | t            | 671088640     | 805306367
 
 (4 rows)

Se o nó deseja determinar qual fragmento contém uma linha de github_events, ele faz o hash do valor da coluna de distribuição na linha. Em seguida, o nó verifica qual intervalo do fragmento contém o valor do hash. Os intervalos são definidos para que a imagem da função hash seja sua união não contínua.

Posicionamentos de fragmentos

Imagine que o fragmento 102027 esteja associado à linha em questão. A linha é lida ou gravada em uma tabela chamada github_events_102027 em um dos trabalhos. Com as informações armazenadas nas tabelas de metadados, a extensão determina o que é esse trabalho específico. O mapeamento do fragmento para o trabalho é conhecido como posicionamento do fragmento.

O nó reescreve as consultas em fragmentos que se referem a tabelas específicas como github_events_102027 e executa esses fragmentos nos trabalhos apropriados. Este é um exemplo de consulta executada nos bastidores para localizar o nó que contém o fragmento com identificador 102027.

SELECT
    shardid,
    node.nodename,
    node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
  ON placement.groupid = node.groupid
 AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;

┌─────────┬───────────┬──────────┐
│ shardid │ nodename  │ nodeport │
├─────────┼───────────┼──────────┤
│  102027 │ localhost │     5433 │
└─────────┴───────────┴──────────┘

Conteúdo relacionado

• Modelos de fragmentação em clusters elásticos no Banco de Dados do Azure para PostgreSQL.
• Tipos de tabela em clusters elásticos no Banco de Dados do Azure para PostgreSQL.
• Perguntas frequentes sobre limitações de clusters elásticos do Banco de Dados do Azure para PostgreSQL.