Nodos e tabelas no Azure Cosmos DB para PostgreSQL

APLICA-SE A: Azure Cosmos DB para PostgreSQL (alimentado pela extensão de banco de dados Citus para PostgreSQL)

Nós

O Azure Cosmos DB para PostgreSQL permite que os servidores PostgreSQL (chamados nós) se coordenem entre si em uma arquitetura de "nada compartilhado". Os nós em um cluster armazenam coletivamente mais dados e usam mais núcleos de CPU do que seria possível em um único servidor. A arquitetura também permite que o banco de dados seja dimensionado adicionando mais nós ao cluster.

Coordenador e trabalhadores

Cada cluster tem um nó coordenador e vários trabalhadores. As aplicações enviam as suas consultas para o nó coordenador, que as encaminha aos trabalhadores relevantes e acumula os resultados.

O Azure Cosmos DB para PostgreSQL permite que o administrador do banco de dados distribua tabelas e/ou esquemas, armazenando linhas diferentes em diferentes nós de trabalho. Tabelas e/ou esquemas distribuídos são a chave para o desempenho do Azure Cosmos DB for PostgreSQL. A falha na distribuição de tabelas e/ou esquemas os deixa inteiramente no nó coordenador e não pode tirar proveito do paralelismo entre máquinas.

Para cada consulta em tabelas distribuídas, o coordenador a encaminha para um único nó de trabalho ou a paraleliza em vários, dependendo 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. Tanto na fragmentação baseada em esquema quanto na fragmentação baseada em linha, o coordenador decide o que fazer consultando tabelas de metadados. Essas tabelas monitorizam os nomes DNS e a integridade dos nós de trabalho, bem como a distribuição de dados nos nós.

Tipos de tabela

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

Tipo 1: Tabelas distribuídas

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

O Azure Cosmos DB para PostgreSQL executa não apenas instruções SQL, mas DDL em todo um cluster. A alteração do esquema de uma tabela distribuída é propagada em cascata para atualizar todos os fragmentos da tabela entre os trabalhadores.

Coluna de distribuição

O Azure Cosmos DB para PostgreSQL usa fragmentação algorítmica para atribuir linhas a fragmentos. A atribuição é feita deterministicamente com base no valor de uma coluna de tabela chamada coluna de distribuição. O administrador do cluster deve designar essa coluna ao distribuir uma tabela. Fazer a escolha certa é importante para o desempenho e a funcionalidade.

Tipo 2: Quadros 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 estilhaço é replicado em todos os trabalhadores. As consultas em qualquer trabalhador podem acessar as informações de referência localmente, sem a sobrecarga de rede de solicitar linhas de outro nó. As tabelas de referência não têm coluna de distribuição porque não há necessidade de distinguir fragmentos separados por linha.

As tabelas de referência geralmente são pequenas e são usadas para armazenar dados relevantes para consultas em execução em qualquer nó 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 para PostgreSQL, o nó coordenador ao qual você se conecta é um banco de dados PostgreSQL regular. Pode criar tabelas normais no coordenador e optar por não as fragmentar.

Um bom candidato para tabelas locais seria pequenas tabelas administrativas que não participam em consultas de ligação. Um exemplo é uma users tabela para entrada e autenticação de aplicativos.

Tipo 4: Tabelas gerenciadas localmente

O Azure Cosmos DB para PostgreSQL pode adicionar automaticamente tabelas locais aos metadados se existir 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 create_reference_table função citus_add_local_table_to_metadata em tabelas locais regulares. As tabelas presentes nos metadados são consideradas tabelas geridas e podem ser consultadas a partir de qualquer nó, o Citus sabe redirecionar para o coordenador para obter dados da tabela gerida localmente. Essas tabelas são exibidas como locais na vista citus_tables.

Tipo 5: Tabelas de esquema

Com fragmentação por esquema introduzida no Citus 12.0, os esquemas distribuídos são automaticamente associados a grupos de colocalização individuais. As tabelas criadas nesses esquemas são automaticamente convertidas em tabelas distribuídas sem uma chave de fragmento. Essas tabelas são consideradas tabelas de esquema e são exibidas como esquema na vista 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 discute 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 um ID de fragmento com um intervalo de inteiros num 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 coordenação quiser determinar qual fragmento detém uma linha de github_events, calcula o hash do 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 disjunta.

Posicionamentos de estilhaços

Suponha que o estilhaço 102027 esteja associado à linha em questão. A linha é lida ou escrita em uma tabela chamada github_events_102027 em um dos trabalhadores. Que trabalhador? Isso é determinado inteiramente pelas tabelas de metadados. O mapeamento de fragmento para trabalhador é conhecido como colocação de fragmento.

O nó coordenador 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 em segundo plano para encontrar o nó que contém o ID do 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óximos passos

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