Nós 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 candidaturas enviam as suas consultas para o nó coordenador, que as transmite aos trabalhadores relevantes e acumula os seus 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 rastreiam os nomes DNS e a integridade dos nós de trabalho, bem como a distribuição de dados entre 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 de fragmentos chamadas fragmentos.

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 é feita 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. Você pode criar tabelas comuns no coordenador e optar por não fragmentá-las.

Um bom candidato para mesas locais seriam pequenas mesas administrativas que não participam de consultas de junçã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 gerenciadas e podem ser consultadas a partir de qualquer nó, o Citus sabe encaminhar para o coordenador para obter dados da tabela gerenciada local. Essas tabelas são exibidas como locais em citus_tables exibição.

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 colocation individuais. As tabelas criadas nesses esquemas são convertidas automaticamente em tabelas distribuídas colocalizadas sem uma chave de estilhaço. Essas tabelas são consideradas tabelas de esquema e são exibidas como esquema em citus_tables exibiçã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.

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 da extensão com um intervalo de números inteiros num espaço 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 a extensão que detém uma linha de github_events, criará 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 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. Que trabalhador? Isso é determinado inteiramente pelas tabelas de metadados. O mapeamento de fragmento para trabalhador é conhecido como colocação de estilhaço.

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 nos bastidores para encontrar o nó que contém o ID do estilhaço 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.