Partilhar via

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

  • Artigo

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.

Nota

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

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.

Nome Tipo Description
Logicalrelid Regclass Tabela distribuída à qual esta linha corresponde. Esse valor faz referência à coluna relfilenode na tabela de catálogo do sistema pg_class.
método de peças char O método utilizado para particionamento / distribuição. São anexados os valores desta coluna correspondentes a diferentes métodos de distribuição: “a”, hash: “h”, tabela de referência: “n”
chave parcial texto Informações detalhadas sobre a coluna de distribuição, incluindo número da coluna, tipo e outras informações relevantes.
ColocationID integer Grupo de colocation ao qual esta tabela pertence. As tabelas no mesmo grupo permitem junções colocalizadas e rollups distribuídos, entre outras otimizações. Esse valor faz referência à coluna colocationid na tabela pg_dist_colocation.
remodelação char O método usado para a replicação de dados. Os valores desta coluna correspondentes a diferentes métodos de replicação são: Citus statement-based replication: 'c', postgresql streaming replication: 's', two-phase commit (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)

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.

Nome Tipo Description
Logicalrelid Regclass Tabela distribuída à qual esta linha corresponde. Esse valor faz referência à coluna relfilenode na tabela de catálogo do sistema pg_class.
Shardid bigint Identificador global exclusivo atribuído a este fragmento.
armazenamento de fragmentos char Tipo de armazenamento utilizado para este fragmento. Diferentes tipos de armazenamento são discutidos na tabela abaixo.
shardminvalue texto Para acrescentar tabelas distribuídas, valor mínimo da coluna de distribuição neste fragmento (inclusive). Para tabelas distribuídas por hash, é o valor mínimo do token hash atribuído a essa extensão (inclusive).
shardmaxvalue texto Para acrescentar tabelas distribuídas, valor máximo da coluna de distribuição neste fragmento (inclusive). Para tabelas distribuídas por hash, é o valor máximo do token hash atribuído a essa extensão (inclusive). 
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.

Tipo de armazenamento Valor do armazenamento de fragmentos Description
TABELA 't' Indica que o estilhaço armazena dados pertencentes a uma tabela distribuída regular.
COLUNAR «c» Indica que o estilhaço armazena dados colunares. (Usado por tabelas de cstore_fdw distribuídas)
ESTRANGEIROS «f» Indica que o fragmento armazena dados estrangeiros. (Usado por tabelas de file_fdw distribuídas)

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.

Nome Tipo Description
Shardid bigint Identificador de estilhaço associado a este posicionamento. Esse valor faz referência à coluna shardid na tabela de catálogo pg_dist_shard.
Shardstate número inteiro Descreve o estado dessa colocação. Diferentes estados de fragmento são discutidos na seção abaixo.
comprimento do fragmento bigint Para tabelas distribuídas de acréscimo, o tamanho do posicionamento do estilhaço no nó de trabalho em bytes. Para tabelas distribuídas com hash, zero.
PlaceID bigint Identificador exclusivo gerado automaticamente para cada posicionamento individual.
groupid número inteiro Indica 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 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:

Nome do estado Valor do Shardstate Description
FINALIZADO 1 O estado novos fragmentos são criados em. Os posicionamentos de estilhaços nesse estado são considerados atualizados e são usados no planejamento e execução de consultas.
INATIVO 3 Os posicionamentos de estilhaços nesse estado são considerados inativos devido a estarem fora de sincronia com outras réplicas do mesmo fragmento. O estado pode ocorrer quando um acréscimo, modificação (INSERT, UPDATE, DELETE) ou uma operação DDL falha para este posicionamento. O planejador de consultas ignorará os 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 descartar 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 pg_dist_node contém informações sobre os nós de trabalho no cluster.

Nome Tipo Description
nodeid número inteiro Identificador gerado automaticamente para um nó individual.
groupid número inteiro Identificador usado para indicar 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, é o mesmo que o nodeid.
nome do nó texto Nome do host ou endereço IP do nó de trabalho do PostgreSQL.
NodePort número inteiro Número da porta na qual o nó de trabalho do PostgreSQL está escutando.
noderack texto (Opcional) Informações de posicionamento do rack para o nó de trabalho.
HASmetadata boolean Reservado para uso interno.
isactive boolean Se o nó está ativo aceitando posicionamentos de estilhaços.
noderole texto Se o nó é primário ou secundário
nodecluster texto O nome do cluster que contém este nó
deveriashards boolean Se falso, os fragmentos serão movidos para fora do nó (drenados) durante o reequilíbrio, nem fragmentos de novas tabelas distribuídas serão colocados no nó, a menos que estejam colocalizados 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 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).

Nome Tipo Description
classid Oide Classe do objeto distribuído
objid Oide ID do objeto distribuído
Objsubid integer Sub ID do objeto distribuído, por exemplo, attnum
tipo texto Parte do endereço estável usado durante as atualizações pg
object_names texto[] Parte do endereço estável usado durante as atualizações pg
object_args texto[] Parte do endereço estável usado durante as atualizações pg
distribution_argument_index integer Válido apenas para funções/procedimentos distribuídos
ColocationID integer Válido apenas para funções/procedimentos distribuídos

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

Nome Tipo Description
schema_name regnamespace Nome do esquema distribuído
colocation_id integer ID de colocation do esquema distribuído
schema_size texto Resumo do tamanho legível por humanos de todos os objetos dentro do esquema
schema_owner nome Função proprietária do esquema

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.

Nome Tipo Description
ColocationID número inteiro Identificador exclusivo para o grupo de colocation ao qual esta linha corresponde.
Contagem de fragmentos número inteiro Contagem de estilhaços para todas as tabelas neste grupo de colocation
fator de replicação número inteiro Fator de replicação para todas as tabelas neste grupo de colocation.
distributionColumnType Oide O tipo da coluna de distribuição para todas as tabelas neste grupo de colocation. 
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.

Nome Tipo Description
default_strategy boolean 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 tomar um shardid como bigint, e retornar sua noção de um custo, como tipo real
node_capacity_function Regproc Identificador para uma função de capacidade, que deve tomar 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 dada shardid bigint, e nodeidarg int, retorna boolean para saber se o Azure Cosmos DB para PostgreSQL pode armazenar o fragmento no nó
default_threshold flutuação4 Limite para considerar um nó muito cheio ou muito vazio, que determina quando o rebalance_table_shards deve tentar mover fragmentos
minimum_threshold flutuação4 Uma salvaguarda para evitar que o argumento limiar de rebalance_table_shards() seja definido como demasiado baixo

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.

Nome Tipo Description
queryid bigint identificador (bom para pg_stat_statements junções)
userid Oide usuário que executou a consulta
Dbid Oide instância de banco de dados do coordenador
query texto seqüência de caracteres de consulta anonimizada
Executor texto Executor Citus usado: adaptativo, em tempo real, task-tracker, roteador ou insert-select
partition_key texto valor da coluna de distribuição em consultas executadas pelo router, caso contrário NULL
Convocatórias 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

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.

Nota

Se uma consulta de roteador (por exemplo, inquilino único em um aplicativo multilocatário, 'SELECT

  • FROM table onde tenant_id = X') é executado sem um bloco de transação, então master_query_host_name e master_query_host_port colunas serão NULL em citus_worker_stat_activity.

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