Tabelas e exibições do sistema Azure Cosmos DB para PostgreSQL

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

O Azure Cosmos DB para PostgreSQL cria e mantém tabelas especiais que contêm informações sobre dados distribuídos no cluster. O nó coordenador consulta essas tabelas ao planejar como executar consultas nos nós de trabalho.

Metadados do Coordenador

O Azure Cosmos DB para PostgreSQL divide cada tabela distribuída em vários fragmentos lógicos com base na coluna de distribuição. Em seguida, o coordenador mantém tabelas de metadados para rastrear estatísticas e informações sobre a integridade e a localização desses fragmentos.

Nesta seção, descrevemos cada uma dessas tabelas de metadados e seu esquema. Você pode exibir e consultar essas tabelas usando SQL depois de fazer login no nó coordenador.

Tabela de partições

A tabela pg_dist_partition armazena metadados sobre quais tabelas no banco de dados são distribuídas. Para cada tabela distribuída, ele também armazena informações sobre o método de distribuição e informações detalhadas sobre a coluna de distribuição.

SELECT * from pg_dist_partition;
 logicalrelid  | partmethod |                                                        partkey                                                         | colocationid | repmodel 
---------------+------------+------------------------------------------------------------------------------------------------------------------------+--------------+----------
 github_events | h          | {VAR :varno 1 :varattno 4 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 4 :location -1} |            2 | c
 (1 row)

Mesa de estilhaços

A tabela pg_dist_shard armazena metadados sobre fragmentos individuais de uma tabela. Pg_dist_shard tem informações sobre a qual fragmentos de tabela distribuídos pertencem e estatísticas sobre a coluna de distribuição para fragmentos. Para acrescentar tabelas distribuídas, essas estatísticas correspondem aos valores min / max da coluna de distribuição. Para tabelas distribuídas por hash, elas são intervalos de token de hash atribuídos a esse fragmento. Essas estatísticas são usadas para remover fragmentos não relacionados durante consultas SELECT.

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)

Tipos de armazenamento de estilhaços

A coluna shardstorage no pg_dist_shard indica o tipo de armazenamento usado para o fragmento. Uma breve visão geral dos diferentes tipos de armazenamento de estilhaços e sua representação está abaixo.

Visualização de informações de estilhaços

Além da tabela de metadados de estilhaços de baixo nível descrita acima, o Azure Cosmos DB para PostgreSQL fornece uma citus_shards exibição para verificar facilmente:

• Onde está cada fragmento (nó e porta),
• A que tipo de mesa pertence, e
• O seu tamanho

Esta vista ajuda-o a inspecionar fragmentos para encontrar, entre outras coisas, desequilíbrios de qualquer tamanho entre nós.

SELECT * FROM citus_shards;
.
 table_name | shardid | shard_name   | citus_table_type | colocation_id | nodename  | nodeport | shard_size
------------+---------+--------------+------------------+---------------+-----------+----------+------------
 dist       |  102170 | dist_102170  | distributed      |            34 | localhost |     9701 |   90677248
 dist       |  102171 | dist_102171  | distributed      |            34 | localhost |     9702 |   90619904
 dist       |  102172 | dist_102172  | distributed      |            34 | localhost |     9701 |   90701824
 dist       |  102173 | dist_102173  | distributed      |            34 | localhost |     9702 |   90693632
 ref        |  102174 | ref_102174   | reference        |             2 | localhost |     9701 |       8192
 ref        |  102174 | ref_102174   | reference        |             2 | localhost |     9702 |       8192
 dist2      |  102175 | dist2_102175 | distributed      |            34 | localhost |     9701 |     933888
 dist2      |  102176 | dist2_102176 | distributed      |            34 | localhost |     9702 |     950272
 dist2      |  102177 | dist2_102177 | distributed      |            34 | localhost |     9701 |     942080
 dist2      |  102178 | dist2_102178 | distributed      |            34 | localhost |     9702 |     933888

O colocation_id refere-se ao grupo de colocation.

Mesa de colocação de estilhaços

A tabela pg_dist_placement rastreia a localização de réplicas de estilhaços em nós de trabalho. Cada réplica de um fragmento atribuído a um nó específico é chamada de posicionamento de estilhaço. Esta tabela armazena informações sobre a integridade e a localização de cada colocação de estilhaços.

SELECT * from pg_dist_placement;
  shardid | shardstate | shardlength | placementid | groupid
 ---------+------------+-------------+-------------+---------
   102008 |          1 |           0 |           1 |       1
   102008 |          1 |           0 |           2 |       2
   102009 |          1 |           0 |           3 |       2
   102009 |          1 |           0 |           4 |       3
   102010 |          1 |           0 |           5 |       3
   102010 |          1 |           0 |           6 |       4
   102011 |          1 |           0 |           7 |       4

Estados de Colocação de Estilhaços

O Azure Cosmos DB para PostgreSQL gerencia a integridade do estilhaço por posicionamento. Se um posicionamento colocar o sistema em um estado inconsistente, o Azure Cosmos DB para PostgreSQL o marcará automaticamente como indisponível. O estado de posicionamento é registrado na tabela pg_dist_shard_placement, dentro da coluna shardstate. Aqui está uma breve visão geral dos diferentes estados de colocação de estilhaços:

Tabela de nó de trabalho

A tabela pg_dist_node contém informações sobre os nós de trabalho no cluster.

SELECT * from pg_dist_node;
 nodeid | groupid | nodename  | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | shouldhaveshards
--------+---------+-----------+----------+----------+-------------+----------+----------+-------------+------------------
      1 |       1 | localhost |    12345 | default  | f           | t        | primary  | default     | t
      2 |       2 | localhost |    12346 | default  | f           | t        | primary  | default     | t
      3 |       3 | localhost |    12347 | default  | f           | t        | primary  | default     | t
(3 rows)

Tabela de objetos distribuídos

A tabela citus.pg_dist_object contém uma lista de objetos, como tipos e funções, que foram criados no nó coordenador e propagados para nós de trabalho. Quando um administrador adiciona novos nós de trabalho ao cluster, o Azure Cosmos DB para PostgreSQL cria automaticamente cópias dos objetos distribuídos nos novos nós (na ordem correta para satisfazer as dependências do objeto).

"Endereços estáveis" identificam exclusivamente objetos independentemente de um servidor específico. O Azure Cosmos DB para PostgreSQL rastreia objetos durante uma atualização do PostgreSQL usando endereços estáveis criados com a função pg_identify_object_as_address( ).

Aqui está um exemplo de como create_distributed_function() adiciona entradas à citus.pg_dist_object tabela:

CREATE TYPE stoplight AS enum ('green', 'yellow', 'red');

CREATE OR REPLACE FUNCTION intersection()
RETURNS stoplight AS $$
DECLARE
        color stoplight;
BEGIN
        SELECT *
          FROM unnest(enum_range(NULL::stoplight)) INTO color
         ORDER BY random() LIMIT 1;
        RETURN color;
END;
$$ LANGUAGE plpgsql VOLATILE;

SELECT create_distributed_function('intersection()');

-- will have two rows, one for the TYPE and one for the FUNCTION
TABLE citus.pg_dist_object;

-[ RECORD 1 ]---------------+------
classid                     | 1247
objid                       | 16780
objsubid                    | 0
type                        |
object_names                |
object_args                 |
distribution_argument_index |
colocationid                |
-[ RECORD 2 ]---------------+------
classid                     | 1255
objid                       | 16788
objsubid                    | 0
type                        |
object_names                |
object_args                 |
distribution_argument_index |
colocationid                |

Visualização de esquemas distribuídos

O Citus 12.0 introduziu o conceito de fragmentação baseada em esquema e, com ele, a visualização 'citus_schemas'', que mostra quais esquemas foram distribuídos no sistema. A exibição lista apenas esquemas distribuídos, esquemas locais não são exibidos.

Veja o exemplo a seguir:

 schema_name | colocation_id | schema_size | schema_owner
-------------+---------------+-------------+--------------
 userservice |             1 | 0 bytes     | userservice
 timeservice |             2 | 0 bytes     | timeservice
 pingservice |             3 | 632 kB      | pingservice

Visualização de tabelas distribuídas

A citus_tables exibição mostra um resumo de todas as tabelas gerenciadas pelo Azure Cosmos DB para PostgreSQL (tabelas distribuídas e de referência). A exibição combina informações do Azure Cosmos DB para tabelas de metadados PostgreSQL para obter uma visão geral fácil e legível por humanos dessas propriedades de tabela:

• Tipo de tabela
• Coluna de distribuição
• ID do grupo de colocation
• Tamanho legível por humanos
• Contagem de estilhaços
• Proprietário (usuário do banco de dados)
• Método de acesso (heap ou colunar)

Veja o exemplo a seguir:

SELECT * FROM citus_tables;
┌────────────┬──────────────────┬─────────────────────┬───────────────┬────────────┬─────────────┬─────────────┬───────────────┐
│ table_name │ citus_table_type │ distribution_column │ colocation_id │ table_size │ shard_count │ table_owner │ access_method │
├────────────┼──────────────────┼─────────────────────┼───────────────┼────────────┼─────────────┼─────────────┼───────────────┤
│ foo.test   │ distributed      │ test_column         │             1 │ 0 bytes    │          32 │ citus       │ heap          │
│ ref        │ reference        │ <none>              │             2 │ 24 GB      │           1 │ citus       │ heap          │
│ test       │ distributed      │ id                  │             1 │ 248 TB     │          32 │ citus       │ heap          │
└────────────┴──────────────────┴─────────────────────┴───────────────┴────────────┴─────────────┴─────────────┴───────────────┘

Visualização de partições de tempo

O Azure Cosmos DB para PostgreSQL fornece UDFs para gerenciar partições para o caso de uso de Dados de Série Temporal. Ele também mantém uma time_partitions visão para inspecionar as partições que gerencia.

Colunas:

• parent_table a tabela particionada
• partition_column a coluna na qual a tabela pai é particionada
• particionar o nome de uma tabela de partições
• from_value limite inferior no tempo para linhas nesta partição
• to_value limite superior no tempo para linhas nesta partição
• access_method heap para armazenamento baseado em linha e colunar para armazenamento colunar

SELECT * FROM time_partitions;
┌────────────────────────┬──────────────────┬─────────────────────────────────────────┬─────────────────────┬─────────────────────┬───────────────┐
│      parent_table      │ partition_column │                partition                │     from_value      │      to_value       │ access_method │
├────────────────────────┼──────────────────┼─────────────────────────────────────────┼─────────────────────┼─────────────────────┼───────────────┤
│ github_columnar_events │ created_at       │ github_columnar_events_p2015_01_01_0000 │ 2015-01-01 00:00:00 │ 2015-01-01 02:00:00 │ columnar      │
│ github_columnar_events │ created_at       │ github_columnar_events_p2015_01_01_0200 │ 2015-01-01 02:00:00 │ 2015-01-01 04:00:00 │ columnar      │
│ github_columnar_events │ created_at       │ github_columnar_events_p2015_01_01_0400 │ 2015-01-01 04:00:00 │ 2015-01-01 06:00:00 │ columnar      │
│ github_columnar_events │ created_at       │ github_columnar_events_p2015_01_01_0600 │ 2015-01-01 06:00:00 │ 2015-01-01 08:00:00 │ heap          │
└────────────────────────┴──────────────────┴─────────────────────────────────────────┴─────────────────────┴─────────────────────┴───────────────┘

Tabela de grupo de colocation

A tabela pg_dist_colocation contém informações sobre quais fragmentos de tabelas devem ser colocados juntos ou colocalizados. Quando duas tabelas estão no mesmo grupo de colocation, o Azure Cosmos DB para PostgreSQL garante que fragmentos com os mesmos valores de coluna de distribuição serão colocados nos mesmos nós de trabalho. O colocation permite otimizações de junção, certos pacotes cumulativos distribuídos e suporte a chaves estrangeiras. A colocalização de estilhaços é inferida quando as contagens de estilhaços, os fatores de replicação e os tipos de coluna de partição correspondem entre duas tabelas; no entanto, um grupo de colocation personalizado pode ser especificado ao criar uma tabela distribuída, se desejado.

SELECT * from pg_dist_colocation;
  colocationid | shardcount | replicationfactor | distributioncolumntype 
 --------------+------------+-------------------+------------------------
			 2 |         32 |                 2 |                     20
  (1 row)

Tabela de estratégia do rebalanceador

Esta tabela define estratégias que rebalance_table_shards pode usar para determinar para onde mover fragmentos.

Por padrão, o Cosmos DB para PostgreSQL é fornecido com estas estratégias na tabela:

SELECT * FROM pg_dist_rebalance_strategy;

-[ RECORD 1 ]-------------------+-----------------------------------
Name                            | by_shard_count
default_strategy                | false
shard_cost_function             | citus_shard_cost_1
node_capacity_function          | citus_node_capacity_1
shard_allowed_on_node_function  | citus_shard_allowed_on_node_true
default_threshold               | 0
minimum_threshold               | 0
-[ RECORD 2 ]-------------------+-----------------------------------
Name                            | by_disk_size
default_strategy                | true
shard_cost_function             | citus_shard_cost_by_disk_size
node_capacity_function          | citus_node_capacity_1
shard_allowed_on_node_function  | citus_shard_allowed_on_node_true
default_threshold               | 0.1
minimum_threshold               | 0.01

A estratégia by_disk_size atribui a cada fragmento o mesmo custo. Seu efeito é equalizar a contagem de estilhaços entre nós. A estratégia padrão, by_disk_size, atribui um custo a cada estilhaço correspondente ao tamanho do disco em bytes mais o dos fragmentos que estão colocalizados com ele. O tamanho do disco é calculado usando pg_total_relation_size, por isso inclui índices. Esta estratégia tenta obter o mesmo espaço em disco em cada nó. Observe o limite de , ele evita o movimento desnecessário de 0.1estilhaços causados por diferenças insignificantes no espaço em disco.

Criação de estratégias de rebalanceamento personalizadas

Aqui estão exemplos de funções que podem ser usadas dentro de novas estratégias de rebalanceador de estilhaços e registradas no pg_dist_rebalance_strategy com a função citus_add_rebalance_strategy.

• Definindo uma exceção de capacidade de nó por padrão de nome de host:

  CREATE FUNCTION v2_node_double_capacity(nodeidarg int)
      RETURNS boolean AS $$
      SELECT
          (CASE WHEN nodename LIKE '%.v2.worker.citusdata.com' THEN 2 ELSE 1 END)
      FROM pg_dist_node where nodeid = nodeidarg
      $$ LANGUAGE sql;
  

• Rebalanceamento por número de consultas que vão para um fragmento, conforme medido pelo citus_stat_statements:

  -- example of shard_cost_function
  
  CREATE FUNCTION cost_of_shard_by_number_of_queries(shardid bigint)
      RETURNS real AS $$
      SELECT coalesce(sum(calls)::real, 0.001) as shard_total_queries
      FROM citus_stat_statements
      WHERE partition_key is not null
          AND get_shard_id_for_distribution_column('tab', partition_key) = shardid;
  $$ LANGUAGE sql;
  

• Isolando um fragmento específico (10000) em um nó (endereço '10.0.0.1'):

  -- example of shard_allowed_on_node_function
  
  CREATE FUNCTION isolate_shard_10000_on_10_0_0_1(shardid bigint, nodeidarg int)
      RETURNS boolean AS $$
      SELECT
          (CASE WHEN nodename = '10.0.0.1' THEN shardid = 10000 ELSE shardid != 10000 END)
      FROM pg_dist_node where nodeid = nodeidarg
      $$ LANGUAGE sql;
  
  -- The next two definitions are recommended in combination with the above function.
  -- This way the average utilization of nodes is not impacted by the isolated shard.
  CREATE FUNCTION no_capacity_for_10_0_0_1(nodeidarg int)
      RETURNS real AS $$
      SELECT
          (CASE WHEN nodename = '10.0.0.1' THEN 0 ELSE 1 END)::real
      FROM pg_dist_node where nodeid = nodeidarg
      $$ LANGUAGE sql;
  CREATE FUNCTION no_cost_for_10000(shardid bigint)
      RETURNS real AS $$
      SELECT
          (CASE WHEN shardid = 10000 THEN 0 ELSE 1 END)::real
      $$ LANGUAGE sql;
  

Tabela de estatísticas de consulta

O Azure Cosmos DB para PostgreSQL fornece citus_stat_statements estatísticas sobre como as consultas estão sendo executadas e para quem. É análogo (e pode ser unido com) a visualização pg_stat_statements no PostgreSQL, que rastreia estatísticas sobre a velocidade da consulta.

Essa exibição pode rastrear consultas para locatários de origem em um aplicativo multilocatário, o que ajuda a decidir quando fazer o isolamento do locatário.

-- create and populate distributed table
create table foo ( id int );
select create_distributed_table('foo', 'id');
insert into foo select generate_series(1,100);

-- enable stats
-- pg_stat_statements must be in shared_preload libraries
create extension pg_stat_statements;

select count(*) from foo;
select * from foo where id = 42;

select * from citus_stat_statements;

Resultados:

-[ RECORD 1 ]-+----------------------------------------------
queryid       | -909556869173432820
userid        | 10
dbid          | 13340
query         | insert into foo select generate_series($1,$2)
executor      | insert-select
partition_key |
calls         | 1
-[ RECORD 2 ]-+----------------------------------------------
queryid       | 3919808845681956665
userid        | 10
dbid          | 13340
query         | select count(*) from foo;
executor      | adaptive
partition_key |
calls         | 1
-[ RECORD 3 ]-+----------------------------------------------
queryid       | 5351346905785208738
userid        | 10
dbid          | 13340
query         | select * from foo where id = $1
executor      | adaptive
partition_key | 42
calls         | 1

Advertências:

• Os dados de estatísticas não são replicados e não sobreviverão a falhas de banco de dados ou failover
• Rastreia um número limitado de consultas, definidas pelo pg_stat_statements.max GUC (padrão 5000)
• Para truncar a tabela, use a citus_stat_statements_reset() função

Atividade de consulta distribuída

O Azure Cosmos DB para PostgreSQL fornece exibições especiais para observar consultas e bloqueios em todo o cluster, incluindo consultas específicas de estilhaços usadas internamente para criar resultados para consultas distribuídas.

• citus_dist_stat_activity: mostra as consultas distribuídas que estão sendo executadas em todos os nós. Um superconjunto de pg_stat_activity, utilizável onde quer que este último esteja.
• citus_worker_stat_activity: mostra consultas sobre trabalhadores, incluindo consultas de fragmentos em fragmentos individuais.
• citus_lock_waits: Consultas bloqueadas em todo o cluster.

As duas primeiras exibições incluem todas as colunas de pg_stat_activity mais o host/porta do host do trabalhador que iniciou a consulta e o host/porta do nó coordenador do cluster.

Por exemplo, considere contar as linhas em uma tabela distribuída:

-- run from worker on localhost:9701

SELECT count(*) FROM users_table;

Podemos ver que a consulta aparece em citus_dist_stat_activity:

SELECT * FROM citus_dist_stat_activity;

-[ RECORD 1 ]----------+----------------------------------
query_hostname         | localhost
query_hostport         | 9701
master_query_host_name | localhost
master_query_host_port | 9701
transaction_number     | 1
transaction_stamp      | 2018-10-05 13:27:20.691907+03
datid                  | 12630
datname                | postgres
pid                    | 23723
usesysid               | 10
usename                | citus
application\_name      | psql
client\_addr           | 
client\_hostname       | 
client\_port           | -1
backend\_start         | 2018-10-05 13:27:14.419905+03
xact\_start            | 2018-10-05 13:27:16.362887+03
query\_start           | 2018-10-05 13:27:20.682452+03
state\_change          | 2018-10-05 13:27:20.896546+03
wait\_event_type       | Client
wait\_event            | ClientRead
state                  | idle in transaction
backend\_xid           | 
backend\_xmin          | 
query                  | SELECT count(*) FROM users_table;
backend\_type          | client backend

Esta consulta requer informações de todos os fragmentos. Algumas das informações estão em estilhaços users_table_102038, que por acaso são armazenados em localhost:9700. Podemos ver uma consulta acessando o fragmento observando a citus_worker_stat_activity exibição:

SELECT * FROM citus_worker_stat_activity;

-[ RECORD 1 ]----------+-----------------------------------------------------------------------------------------
query_hostname         | localhost
query_hostport         | 9700
master_query_host_name | localhost
master_query_host_port | 9701
transaction_number     | 1
transaction_stamp      | 2018-10-05 13:27:20.691907+03
datid                  | 12630
datname                | postgres
pid                    | 23781
usesysid               | 10
usename                | citus
application\_name      | citus
client\_addr           | ::1
client\_hostname       | 
client\_port           | 51773
backend\_start         | 2018-10-05 13:27:20.75839+03
xact\_start            | 2018-10-05 13:27:20.84112+03
query\_start           | 2018-10-05 13:27:20.867446+03
state\_change          | 2018-10-05 13:27:20.869889+03
wait\_event_type       | Client
wait\_event            | ClientRead
state                  | idle in transaction
backend\_xid           | 
backend\_xmin          | 
query                  | COPY (SELECT count(*) AS count FROM users_table_102038 users_table WHERE true) TO STDOUT
backend\_type          | client backend

O query campo mostra os dados que estão sendo copiados do fragmento a ser contado.

Aqui estão exemplos de consultas úteis que você pode criar usando citus_worker_stat_activity:

-- active queries' wait events on a certain node

SELECT query, wait_event_type, wait_event
  FROM citus_worker_stat_activity
 WHERE query_hostname = 'xxxx' and state='active';

-- active queries' top wait events

SELECT wait_event, wait_event_type, count(*)
  FROM citus_worker_stat_activity
 WHERE state='active'
 GROUP BY wait_event, wait_event_type
 ORDER BY count(*) desc;

-- total internal connections generated per node by Azure Cosmos DB for PostgreSQL

SELECT query_hostname, count(*)
  FROM citus_worker_stat_activity
 GROUP BY query_hostname;

-- total internal active connections generated per node by Azure Cosmos DB for PostgreSQL

SELECT query_hostname, count(*)
  FROM citus_worker_stat_activity
 WHERE state='active'
 GROUP BY query_hostname;

A próxima vista é citus_lock_waits. Para ver como funciona, podemos gerar uma situação de bloqueio manualmente. Primeiro, vamos configurar uma tabela de teste do coordenador:

CREATE TABLE numbers AS
  SELECT i, 0 AS j FROM generate_series(1,10) AS i;
SELECT create_distributed_table('numbers', 'i');

Em seguida, usando duas sessões no coordenador, podemos executar esta sequência de instruções:

-- session 1                           -- session 2
-------------------------------------  -------------------------------------
BEGIN;
UPDATE numbers SET j = 2 WHERE i = 1;
                                       BEGIN;
                                       UPDATE numbers SET j = 3 WHERE i = 1;
                                       -- (this blocks)

A citus_lock_waits vista mostra a situação.

SELECT * FROM citus_lock_waits;

-[ RECORD 1 ]-------------------------+----------------------------------------
waiting_pid                           | 88624
blocking_pid                          | 88615
blocked_statement                     | UPDATE numbers SET j = 3 WHERE i = 1;
current_statement_in_blocking_process | UPDATE numbers SET j = 2 WHERE i = 1;
waiting_node_id                       | 0
blocking_node_id                      | 0
waiting_node_name                     | coordinator_host
blocking_node_name                    | coordinator_host
waiting_node_port                     | 5432
blocking_node_port                    | 5432

Neste exemplo, as consultas se originaram no coordenador, mas a exibição também pode listar bloqueios entre consultas originadas em workers (executadas com o Azure Cosmos DB para PostgreSQL MX, por exemplo).

Próximos passos

• Saiba como algumas funções do Azure Cosmos DB para PostgreSQL alteram tabelas do sistema
• Analise os conceitos de nós e tabelas