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

APLICA-SE AO: Azure Cosmos DB for PostgreSQL (da plataforma da extensão 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. O coordenador mantém as tabelas de metadados para acompanhar as estatísticas e as 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.

Observação

clusters que executam versões mais antigas do mecanismo Citus podem não oferecer todas as tabelas listadas abaixo.

Tabela de partição

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

Nome	Digitar	Descrição
logicalrelid	regclass	Tabela distribuída à qual essa linha corresponde. Esse valor faz referência à coluna relfilenode na tabela do catálogo do sistema pg_class.
partmethod	char	O método usado para particionamento/distribuição. Os valores desta coluna correspondentes a métodos de distribuição diferentes são acrescentar: ‘a’, hash: ‘h’, tabela de referência: ‘n’
partkey	text	Informações detalhadas sobre a coluna de distribuição, incluindo número de coluna, tipo e outras informações relevantes.
colocationid	Número inteiro	Grupo de colocação ao qual essa tabela pertence. As tabelas no mesmo grupo permitem junções colocadas e rollups distribuídos, entre outras otimizações. Esse valor faz referência à coluna colocationid na tabela pg_dist_colocation.
repmodel	char	O método usado para replicação de dados. Os valores desta coluna correspondentes a métodos de replicação diferentes são: replicação baseada em instrução Citus: ‘c’, replicação de streaming postgresql: ‘s’, protocolo 2PC (para tabelas de referência): ‘t’

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)

Tabela de fragmentos

A tabela de fragmentos pg_dist_shard armazena metadados sobre fragmentos individuais de uma tabela. Pg_dist_shard tem informações sobre a quais fragmentos de tabela distribuída pertencem e estatísticas sobre a coluna de distribuição para fragmentos. Para acrescentar tabelas distribuídas, essas estatísticas correspondem aos valores mín./máx. da coluna de distribuição. Para tabelas hash distribuídas, 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.

Nome	Digitar	Descrição
logicalrelid	regclass	Tabela distribuída à qual essa linha corresponde. Esse valor faz referência à coluna relfilenode na tabela do catálogo do sistema pg_class.
shardid	BIGINT	Identificador globalmente exclusivo atribuído a este fragmento.
shardstorage	char	Tipo de armazenamento usado para esse fragmento. Os diferentes tipos de armazenamento são discutidos na tabela a seguir.
shardminvalue	text	Para acrescentar tabelas distribuídas, o valor mínimo da coluna de distribuição neste fragmento (inclusivo). Para tabelas hash distribuídas, o valor de token de hash mínimo atribuído a esse fragmento (inclusivo).
shardmaxvalue	text	Para acrescentar tabelas distribuídas, o valor mínimo da coluna de distribuição neste fragmento (inclusivo). Para tabelas hash distribuídas, o valor de token de hash máximo atribuído a esse fragmento (inclusivo).

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 fragmentos

A coluna shardstorage no fragmento pg_dist_shard indica o tipo de armazenamento usado para o fragmento. Veja, abaixo, uma breve visão geral dos diferentes tipos de armazenamento de fragmento e sua representação.

Tipo de armazenamento	Valor de shardstorage	Descrição
TABLE	't'	Indica que o fragmento armazena dados pertencentes a uma tabela distribuída regular.
COLUMNAR	'c'	Indica que o fragmento armazena dados de coluna. (Usado por tabelas cstore_fdw distribuídas)
FOREIGN	'f'	Indica que o fragmento armazena dados externos. (Usado por tabelas file_fdw distribuídas)

Exibição de informações de fragmento

Além da tabela de metadados de fragmento de baixo nível descrita acima, o Azure Cosmos DB para PostgreSQL fornece uma visualização citus_shards para verificar com facilidade:

• Onde está cada fragmento (nó e porta),
• A qual tipo de tabela ele pertence, e
• O tamanho dele

Essa visualização ajuda a inspecionar os fragmentos para localizar, entre outras coisas, qualquer desequilíbrio de tamanho entre os 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 se refere ao grupo de colocação.

Tabela de posicionamento de fragmento

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

Nome	Digitar	Descrição
shardid	BIGINT	Identificador de fragmento associado a este posicionamento. Esse valor faz referência à coluna shardid na tabela do catálogo pg_dist_shard.
shardstate	INT	Descreve o estado desse posicionamento. Os diferentes estados de fragmento são discutidos na seção abaixo.
shardlength	BIGINT	Para acrescentar tabelas distribuídas, o tamanho do posicionamento do fragmento no nó de trabalho em bytes. Para tabelas hash distribuídas, zero.
placementid	BIGINT	Identificador exclusivo gerado automaticamente para cada posicionamento individual.
groupid	INT	Denota um grupo de um servidor primário e zero ou mais servidores secundários quando o modelo de replicação de streaming é usado.

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 posicionamento do fragmento

O Azure Cosmos DB para PostgreSQL gerencia a integridade do fragmento 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. Veja aqui uma breve visão geral dos diferentes estados de posicionamento do fragmento:

Nome do estado	Valor de shardstate	Descrição
FINALIZED	1	O estado em que os novos fragmentos são criados. Os posicionamentos de fragmentos nesse estado são considerados atualizados e usados no planejamento e na execução de consultas.
INACTIVE	3	Os posicionamentos de fragmentos nesse estado são considerados inativos porque estão fora de sincronia com outras réplicas do mesmo fragmento. O estado pode ocorrer quando uma operação de acréscimo, modificação (INSERÇÃO, ATUALIZAÇÃO, EXCLUSÃO) ou DDL falha para esse posicionamento. O planejador de consulta ignorará posicionamentos nesse estado durante o planejamento e a execução. Os usuários podem sincronizar os dados nesses fragmentos com uma réplica finalizada como uma atividade em segundo plano.
TO_DELETE	4	Se o Azure Cosmos DB para PostgreSQL tentar remover um posicionamento de fragmento em resposta a uma chamada de master_apply_delete_command e falhar, o posicionamento será movido para esse estado. Os usuários podem excluir esses fragmentos como uma atividade em segundo plano subsequente.

Tabela de nó de trabalho

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

Nome	Digitar	Descrição
nodeid	INT	Identificador gerado automaticamente para um nó individual.
groupid	INT	Identificador usado para denotar um grupo de um servidor primário e zero ou mais servidores secundários quando o modelo de replicação de streaming é usado. Por padrão, ele é o mesmo que o nodeid.
nodename	text	Nome do host ou endereço IP do nó de trabalho do PostgreSQL.
nodeport	INT	Número da porta na qual o nó de trabalho do PostgreSQL está escutando.
noderack	text	(Opcional) Informações de posicionamento do rack para o nó de trabalho.
hasmetadata	booleano	Reservado para uso interno.
isactive	booleano	Se o nó está ativo aceitando posicionamentos de fragmento.
noderole	text	Se o nó é um primário ou secundário
nodecluster	text	O nome do cluster que contém este nó
shouldhaveshards	booleano	Se for falso, os fragmentos serão movidos para fora do nó (drenados) durante o rebalanceamento, e os fragmentos das novas tabelas distribuídas não serão colocados no nó, a menos que sejam colocados com fragmentos já existentes

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 objeto distribuído

A tabela de objeto 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 de objeto).

Nome	Digitar	Descrição
classid	oid	Classe do objeto distribuído
objid	oid	ID do objeto distribuído
objsubid	Número inteiro	Subid do objeto distribuído, por exemplo, attnum
type	text	Parte do endereço estável usado durante as atualizações de pg
object_names	text[]	Parte do endereço estável usado durante as atualizações de pg
object_args	text[]	Parte do endereço estável usado durante as atualizações de pg
distribution_argument_index	Número inteiro	Válido somente para funções/procedimentos distribuídos
colocationid	Número inteiro	Válido somente para funções/procedimentos distribuídos

Os "endereços estáveis" identificam exclusivamente objetos de forma independente 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().

Veja aqui um exemplo de como create_distributed_function() adiciona entradas à tabela citus.pg_dist_object:

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                |

Exibição de esquemas distribuídos

O Citus 12.0 introduziu o conceito de fragmentação baseada em esquema e com ela a exibiçã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.

Nome	Digitar	Descrição
schema_name	regnamespace	Nome do esquema distribuído
colocation_id	Número inteiro	ID de colocação do esquema distribuído
schema_size	text	Resumo de tamanho legível de todos os objetos dentro do esquema
schema_owner	name	A função que possui o esquema

Aqui está um exemplo:

 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 exibição citus_tables 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 das tabelas de metadados do Azure Cosmos DB para PostgreSQL para obter uma visão geral simples e legível por humanos das propriedades dessas tabelas:

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

Aqui está um exemplo:

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 por partições de tempo

O Azure Cosmos DB para PostgreSQL fornece UDFs para gerenciar partições para o caso de uso de Dados do Timeseries. Ela também mantém uma exibição time_partitions para inspecionar as partições que gerencia.

Colunas:

• parent_table corresponde à tabela particionada
• partition_column corresponde à coluna sobre a qual a tabela pai é particionada
• partition corresponde ao nome de uma tabela de partição
• from_value corresponde ao limite inferior de tempo para as linhas desta partição
• to_value corresponde ao limite superior de tempo para as linhas desta partição
• access_method corresponde a heap para armazenamento baseado em linha e colunas para armazenamento por colunas

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 grupos de colocação

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

Nome	Digitar	Descrição
colocationid	INT	Identificador exclusivo para o grupo de colocação ao qual esta linha corresponde.
shardcount	INT	Contagem de fragmentos para todas as tabelas neste grupo de colocação
replicationfactor	INT	Fator de replicação para todas as tabelas neste grupo de colocação.
distributioncolumntype	oid	O tipo da coluna de distribuição para todas as tabelas neste grupo de colocação.

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

Tabela de estratégias de rebalanceador

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

Nome	Digitar	Descrição
default_strategy	booleano	Se rebalance_table_shards deve escolher essa estratégia por padrão. Use citus_set_default_rebalance_strategy para atualizar esta coluna
shard_cost_function	regproc	Identificador para uma função de custo, que deve usar um shardid como bigint e retornar sua noção de um custo, como o tipo real
node_capacity_function	regproc	Identificador para uma função de capacidade, que deve usar um nodeid como int e retornar sua noção de capacidade de nó como tipo real
shard_allowed_on_node_function	regproc	Identificador para uma função que, dado shardid bigint, e nodeidarg int, retorna booliano para saber se o Azure Cosmos DB for PostgreSQL pode armazenar o fragmento no nó
default_threshold	float4	Limite para considerar um nó muito cheio ou muito vazio, que determina quando o rebalance_table_shards deve tentar mover os fragmentos
minimum_threshold	float4	Uma proteção para impedir que o argumento de limite de rebalance_table_shards() seja definido muito baixo

Por padrão, o Cosmos DB para PostgreSQL é fornecido com essas 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 é igualar a contagem de fragmentos entre nós. A estratégia padrão, by_disk_size, atribui um custo a cada fragmento que corresponde a seu tamanho de disco em bytes, além dos fragmentos que estão colocados com ele. O tamanho do disco é calculado usando pg_total_relation_size, portanto, inclui índices. Essa estratégia tenta atingir o mesmo espaço em disco em cada nó. Observe que o limite de 0.1 impede a movimentação desnecessária de fragmentos causada por diferenças insignificantes no espaço em disco.

Criando estratégias de rebalanceador personalizado

Veja aqui exemplos de funções que podem ser usadas em novas estratégias de rebalanceador de fragmento 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 do 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 consultas

O Azure Cosmos DB para PostgreSQL fornece citus_stat_statements para estatísticas sobre como e para quem as consultas estão sendo executadas. É análoga (e pode ser unida) à exibição de 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.

Nome	Digitar	Descrição
queryid	BIGINT	identificador (bom para junções de pg_stat_statements)
userid	oid	usuário que executou a consulta
dbid	oid	instância de banco de dados do coordenador
Consulta	text	cadeia de caracteres de consulta anônima
executor	text	Executor Citus usado: adaptável, em tempo real, rastreador de tarefas, roteador ou inserção-seleção
partition_key	text	valor da coluna de distribuição em consultas executadas pelo roteador, senão NULO
chamadas	BIGINT	número de vezes que a consulta foi executada

-- 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

Restrições:

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

Atividade de consulta distribuída

O Azure Cosmos DB para PostgreSQL fornece exibições especiais para inspecionar consultas e bloqueios em todo o cluster, incluindo consultas específicas de fragmentos 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 esse último esteja.
• citus_worker_stat_activity: mostra consultas em trabalhos, 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 além do host/porta do trabalho que iniciou a consulta e o host/porta do nó coordenador do cluster.

Por exemplo, considere a possibilidade de 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

Essa consulta requer informações de todos os fragmentos. Algumas das informações estão no fragmento users_table_102038, que são armazenadas no localhost:9700. Podemos ver uma consulta acessando o fragmento, examinando a exibição citus_worker_stat_activity:

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 campo query mostra os dados sendo copiados do fragmento a ser contado.

Observação

Se uma consulta de roteador (por exemplo, um único locatário em um aplicativo multilocatário, `SELECIONE

• DA tabela ONDE tenant_id = X`) for executada sem um bloco de transação, as colunas master_query_host_name e master_query_host_port columns serão NULAS em citus_worker_stat_activity.

Aqui estão exemplos de consultas úteis que você pode criar usandocitus_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 exibição é citus_lock_waits. Para ver como funciona, podemos gerar uma situação de bloqueio manualmente. Primeiro, vamos configurar uma tabela de teste a partir 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 exibição citus_lock_waits 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 são provenientes do coordenador, mas a exibição também pode listar os bloqueios entre as consultas provenientes de trabalhos (executados com o Azure Cosmos DB para PostgreSQL MX por exemplo).

Próximas etapas

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