Nós e tabelas no Azure Cosmos DB for PostgreSQL

Artigo
08/15/2024

APLICA-SE AO: Azure Cosmos DB for PostgreSQL (da plataforma da extensão de dados Citus para PostgreSQL)

Nós

O Azure Cosmos DB for PostgreSQL permite que os servidores do PostgreSQL (chamados de nós) coordenem-se entre si em uma arquitetura "sem compartilhamento". Coletivamente, os nós em um cluster contêm mais dados e usam mais núcleos de CPU do que seria possível em apenas um servidor. A arquitetura também permite que o banco de dados seja dimensionado adicionando mais nós ao grupo de servidores.

Coordenador e trabalhos

Cada cluster tem um nó coordenador e vários nós de trabalho. Os aplicativos enviam as consultas ao nó coordenador, que as retransmite para os nós de trabalhos relevantes e acumula os resultados.

O Azure Cosmos DB for PostgreSQL permite ao administrador de banco de dados distribuir tabelas e/ou esquemas, armazenando linhas diferentes em nós de trabalho diferentes. As tabelas e/ou esquemas distribuídos são a chave para o desempenho do Azure Cosmos DB for PostgreSQL. A incapacidade de distribuir tabelas e/ou esquemas os deixa totalmente no nó de coordenador e sem poder aproveitar o paralelismo entre máquinas.

Para cada consulta em tabelas distribuídas, o coordenador a roteia para um único nó de trabalho ou a coloca em paralelo a vários, depende de onde os dados necessários residem, se 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. Na fragmentação baseada em esquema e na fragmentação baseada em linha, o coordenador decide o que fazer consultando as tabelas de metadados. Essas tabelas acompanham os nomes DNS, a integridade dos nós de trabalho e a distribuição de dados entre nós.

Tipos de tabela

Existem cinco tipos de tabelas em um cluster, cada uma armazenada de forma diferente em nós e usada para finalidades diferentes.

Tipo 1: Tabelas distribuídas

O primeiro tipo são tabelas distribuídas e este é o mais comum. Elas parecem ser tabelas normais para instruções SQL, mas são particionados horizontalmente entre nós de trabalho. Isso significa que as linhas da tabela são armazenadas em nós diferentes, em tabelas de fragmento chamadas de fragmentos.

O Azure Cosmos DB for PostgreSQL executa instruções SQL e DDL em um cluster. Alterar o esquema de uma tabela distribuída em cascata para atualizar todos os fragmentos da tabela entre os trabalhos.

Coluna de distribuição

O Azure Cosmos DB for PostgreSQL usa a fragmentação algorítmica para atribuir linhas a fragmentos. A atribuição é feita de forma determinista com base no valor de uma coluna de tabela chamada coluna de distribuição. O administrador de cluster deve designar esta coluna ao distribuir uma tabela. É importante fazer a escolha certa por questões de desempenho e funcionalidade.

Tipo 2: tabelas de referência

Uma tabela de referência é um tipo de tabela distribuída cujo conteúdo inteiro está concentrado em um único fragmento. O fragmento é replicado em todos os trabalhos. As consultas em um trabalho podem acessar as informações de referência localmente, sem a sobrecarga de rede de solicitar linhas de outro nó. Tabelas de referência não têm nenhuma coluna de distribuição porque não há necessidade de distinguir fragmentos separados por linha.

As tabelas de referência em geral são pequenas e usadas para armazenar dados relevantes para consultas em execução em outros nós de trabalho. Um exemplo são valores enumerados, como status de pedidos ou categorias de produtos.

Tipo 3: tabelas locais

Quando você usa o Azure Cosmos DB for PostgreSQL, o nó coordenador ao qual você se conecta é um banco de dados PostgreSQL comum. Você pode criar tabelas comuns no coordenador e optar por não fragmentá-las.

Um bom candidato para tabelas locais seria as tabelas administrativas pequenas que não participam de consultas de junção. Um exemplo é uma tabela users para entrada e autenticação do aplicativo.

Tipo 4: tabelas locais gerenciadas

O Azure Cosmos DB for PostgreSQL pode adicionar tabelas locais automaticamente aos metadados, se houver uma referência de chave estrangeira entre uma tabela local e uma tabela de referência. Além disso, as tabelas gerenciadas localmente podem ser criadas manualmente executando a função create_reference_table citus_add_local_table_to_metadata em tabelas locais regulares. As tabelas presentes nos metadados são consideradas tabelas gerenciadas e podem ser consultadas em qualquer nó. O Citus sabe encaminhar para o coordenador para obter dados da tabela local gerenciada. Essas tabelas são exibidas como locais no modo de exibição citus_tables.

Tipo 5: tabelas de esquema

Com a fragmentação baseada em esquema introduzida no Citus 12.0, os esquemas distribuídos são automaticamente associados a grupos de colocação individuais. As tabelas criadas nesses esquemas são convertidas automaticamente em tabelas distribuídas colocadas sem uma chave de fragmento. Essas tabelas são consideradas tabelas de esquema e são exibidas como esquema no modo de exibição citus_tables.

Fragmentos

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

A pg_dist_shard tabela de metadados no coordenador contém uma linha para cada fragmento de cada tabela distribuída no sistema. A linha corresponde a uma ID de fragmento 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ó de coordenador deseja determinar qual fragmento contém uma linha 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. Em qual trabalho? Isso é totalmente determinado pelas tabelas de metadados. O mapeamento do fragmento para o trabalho é conhecido como posicionamento do fragmento.

O nó coordenador 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 a ID de fragmento 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 │
└─────────┴───────────┴──────────┘

Próximas etapas

Determinar o tipo do aplicativo para preparar a modelagem de dados
Inspecione fragmentos e posicionamentos com consultas de diagnóstico úteis.

Compartilhar via