Elastic clusters in Azure Database for 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 do Citus para o 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 lida com o gerenciamento e a configuração de várias instâncias do PostgreSQL como um único recurso. Ele também configura automaticamente os nós e os torna conhecidos para a 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. Consulte a documentação de código aberto sobre modelos de fragmentação, se quiser saber mais.

Arquitetura

Um cluster elástico consiste em um ou mais nós do Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL. Essas instâncias são automaticamente dadas a conhecer umas às outras e interconectadas para formar um cluster Citus. Os nós devem ser da mesma camada de computação e armazenamento e podem ser uniformemente dimensionados para cima ou para baixo para níveis mais altos ou mais baixos.

Os clusters elásticos usam instâncias de servidores flexíveis (chamados 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 cluster.

Conectar-se ao cluster usando a porta 5432 coloca você no nó coordenador designado. Os clusters elásticos também permitem balancear a carga de conexões dentro do cluster, usando um método de hash de cinco tuplas, se for feita uma conexão usando a porta 7432. Usando 7432 você ainda pode pousar no nó atualmente designado como coordenador. Para determinadas operações em todo o cluster, como a distribuição de tabelas, pode ser necessário conectar-se 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 do PgBouncer em cada nó (ou usar a porta 6432 para o coordenador designado).

Ao contrário do Cosmos DB para PostgreSQL, os endereços de nó não são expostos externamente. Se você olhar para tabelas de metadados Citus como pg_dist_node, então você pode notar todos os nós com o mesmo endereço IP como 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 vivem em máquinas virtuais diferentes, mesmo que pareçam ser portas diferentes na mesma máquina.

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

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

Para cada consulta em tabelas distribuídas, o nó consultado a roteia para um único nó ou paraleliza-a entre 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 roteia as consultas diretamente para o nó que hospeda o esquema. Em ambos, fragmentação baseada em esquema e fragmentação baseada em linha, o nó decide o que fazer consultando tabelas de metadados. Essas tabelas rastreiam a localização 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ê pode se conectar a qualquer um dos nós para executar operações DML (Data Modification Language) (SELECT, UPDATE, INSERT, DELETE). Todos os nós contêm os metadados necessários para localizar os dados necessários para a consulta e são capazes de obtê-los para responder à consulta.

As operações DDL (Data Definition Language) e as operações em todo o cluster estão atualmente limitadas ao nó que deté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 expandir um cluster elástico adicionando novos nós e reequilibrando os dados nele. O rebalanceamento é uma operação online e não bloqueia cargas de trabalho em execução.

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 pg_dist_shard tabela de metadados contém uma linha para cada fragmento de cada tabela distribuída no sistema. A linha corresponde a um identificador de estilhaço (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ó quiser determinar qual fragmento mantém uma linha de github_events, ele hash o valor da coluna de distribuição na linha. Em seguida, o nó verifica qual intervalo do fragmento contém o valor em hash. Os intervalos são definidos de modo a que a imagem da função hash seja a união não contígua.

Posicionamentos de estilhaços

Suponha que a 102027 de estilhaços esteja associada à linha em questão. A linha é lida ou escrita em uma tabela chamada github_events_102027 em um dos trabalhadores. Com as informações armazenadas nas tabelas de metadados, a extensão determina o que é aquele trabalhador específico. O mapeamento de fragmento para trabalhador é conhecido como colocação de estilhaço.

O nó reescreve consultas em fragmentos que se referem às tabelas específicas como github_events_102027 e executa esses fragmentos nos trabalhadores apropriados. Aqui está um exemplo de uma consulta executada nos bastidores para encontrar o nó que contém 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údos relacionados

• Modelos de compartilhamento 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 clusters elásticos do Azure Database para limitações do PostgreSQL.