Partager via


Tables et vues système Azure Cosmos DB for PostgreSQL

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

Azure Cosmos DB for PostgreSQL crée et gère des tables spéciales qui contiennent des informations sur les données distribuées dans le cluster. Le nœud coordinateur consulte ces tables lors de la planification de l’exécution de requêtes sur les nœuds Worker.

Métadonnées du coordinateur

Azure Cosmos DB for PostgreSQL divise chaque table distribuée en plusieurs partitions logiques en fonction de la colonne de distribution. Le coordinateur gère ensuite les tables de métadonnées pour effectuer le suivi des statistiques et des informations sur l’intégrité et l’emplacement de ces partitions.

Dans cette section, nous décrivons chacune de ces tables de métadonnées et leur schéma. Vous pouvez afficher et interroger ces tables à l’aide de SQL après vous être connecté au nœud coordinateur.

Notes

Il se peut que des clusters exécutant des versions antérieures du Citus Engine ne proposent pas toutes les tables répertoriées ci-dessous.

Table de partition

La table pg_dist_partition stocke les métadonnées sur les tables de la base de données qui sont distribuées. Pour chaque table distribuée, elle stocke également des informations sur la méthode de distribution et des informations détaillées sur la colonne de distribution.

Nom Type Description
logicalrelid regclass Table distribuée à laquelle cette ligne correspond. Cette valeur fait référence à la colonne relfilenode de la table du catalogue système pg_class.
partmethod char Méthode utilisée pour le partitionnement/la distribution. Les valeurs de cette colonne correspondant aux différentes méthodes de distribution sont Append : « a », Hash : « h », table de référence : « n »
partkey text Informations détaillées sur la colonne de distribution, y compris le numéro de colonne, le type et d’autres informations pertinentes.
colocationid entier Groupe de colocation auquel cette table appartient. Les tables dans le même groupe autorisent les jointures colocalisées et les cumuls distribués entre autres optimisations. Cette valeur fait référence à la colonne colocationid de la table pg_dist_colocation.
repmodel char Méthode utilisée pour la réplication des données. Les valeurs de cette colonne correspondant aux différentes méthodes de réplication sont les suivantes : Réplication basée sur une instruction Citus : « c », réplication de streaming PostgreSQL : « s », validation en deux phases (pour les tables de référence) : « 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)

Table partition

La table pg_dist_shard stocke les métadonnées relatives aux partitions individuelles d’une table. Pg_dist_shard contient des informations sur la table distribuée à laquelle appartiennent les partitions et des statistiques sur la colonne de distribution pour partitions. Pour des tables distribuées append, ces statistiques correspondent aux valeurs min/max de la colonne de distribution. Pour des tables distribuées par hachage, il s’agit de plages de jetons de hachage affectées à cette partition. Ces statistiques sont utilisées pour nettoyer les partitions non liés pendant les requêtes SELECT.

Nom Type Description
logicalrelid regclass Table distribuée à laquelle cette ligne correspond. Cette valeur fait référence à la colonne relfilenode de la table du catalogue système pg_class.
shardid bigint Identificateur général unique affecté à la partition.
shardstorage char Type de stockage utilisé pour cette partition. Les différents types de stockage sont décrits dans le tableau ci-dessous.
shardminvalue text Pour les tables distribuées append, valeur minimale de la colonne de distribution dans cette partition (valeur incluse). Pour les tables distribuées hash, il s’agit de la valeur minimale de jetons de hachage affectées à cette partition (valeur incluse).
shardmaxvalue text Pour les tables distribuées append, valeur maximale de la colonne de distribution dans cette partition (valeur incluse). Pour les tables distribuées hash, il s’agit de la valeur maximale de jetons de hachage affectées à cette partition (valeur incluse).
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)

Type de stockage Azure

La colonne shardstorage dans pg_dist_shard indique le type de stockage utilisé pour la partition. Vous trouverez ci-dessous un bref aperçu des différents types de stockage de partition et de leur représentation.

Type de stockage Valeur shardstorage Description
TABLE « t » Indique que shard stocke les données appartenant à une table distribuée normale.
COLUMNAR « c » Indique que shard stocke les données en colonnes. (Utilisé par les tables de cstore_fdw distribuées)
FOREIGN « f » Indique que shard stocke des données étrangères. (Utilisé par les tables de file_fdw distribuées)

Vue des informations sur les partitions

En plus de la table de métadonnées de partition de bas niveau décrite ci-dessus, Azure Cosmos DB for PostgreSQL fournit une vue citus_shards qui permet de vérifier facilement :

  • l’emplacement de chaque partition (nœud et port) ;
  • le type de table auquel elle appartient ;
  • sa taille.

Cette vue vous permet d’examiner les partitions pour trouver, entre autres, tout déséquilibre de taille entre les nœuds.

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

L’identificateur colocation_id fait référence au groupe de colocalisation.

Table de sélection élective de partition

La table pg_dist_placement suit l’emplacement des réplicas de partition sur les nœuds Worker. Chaque réplica d’une partition affectée à un nœud spécifique est appelé une sélection élective de partition. Cette table stocke des informations relatives à l’intégrité et l’emplacement de chaque sélection élective de partition.

Nom Type Description
shardid bigint Identificateur de partition associé à ce sélection élective. Cette valeur fait référence à la colonne shardid de la table du catalogue pg_dist_shard.
shardstate int Décrit l’état de cette sélection élective. Les différents états de partition sont décrits dans la section ci-dessous.
shardlength bigint Pour des tables distribuées append, taille en octets de la sélection élective de partition sur le nœud Worker. Pour les tables de hachage distribuées, zéro.
placementid bigint Identificateur unique généré automatiquement pour chaque sélection élective individuelle.
groupid int Distingue un groupe d’un serveur principal et zéro, un ou plusieurs serveurs secondaires lors de l’utilisation du modèle de réplication de streaming.
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

États de sélection élective de partition

Azure Cosmos DB for PostgreSQL gère l’intégrité des partitions sur la base de leur sélection élective. Si une sélection élective place le système dans un état incohérent, Azure Cosmos DB for PostgreSQL la marque automatiquement comme indisponible. L’état de sélection élective est enregistré dans la table pg_dist_shard_placement, dans la colonne shardstate. Voici un bref aperçu des différents états de sélection élective de partition :

Nom de l’état Valeur shardstate Description
FINALIZED 1 L’état dans lequel les nouvelles partitions sont créées. Les sélections électives de partition dans cet état sont considérées à jour et utilisées dans la planification et l’exécution des requêtes.
INACTIVE 3 Les sélections électives de partition dans cet état sont considérés comme inactifs en raison d’une désynchronisation avec d’autres réplicas de la même partition. L’état peut se produire lorsqu’une opération d’ajout, de modification (INSERT, UPDATE, DELETE) ou de DDL échoue pour cet emplacement. Le planificateur de requêtes ignorera les sélections électives dans cet état au cours de la planification et de l’exécution. Les utilisateurs peuvent synchroniser les données de ces partitions avec un réplica finalisé en tant qu’activité en arrière-plan.
TO_DELETE 4 Si Azure Cosmos DB for PostgreSQL tente de supprimer une sélection élective de partition en réponse à un appel de master_apply_delete_command et échoue, le placement est déplacé vers cet état. Les utilisateurs peuvent ensuite supprimer ces partitions en tant qu’activité d’arrière-plan suivante.

Table de nœud Worker

La table pg_dist_node contient des informations sur les nœuds Worker du cluster.

Nom Type Description
nodeId int Identificateur généré automatiquement pour un nœud individuel.
groupid int Identificateur utilisé pour distinguer un groupe d’un serveur principal et zéro, un ou plusieurs serveurs secondaires lors de l’utilisation du modèle de réplication de streaming. Par défaut, il est identique au nodeid.
nodename text Nom d’hôte ou adresse IP du nœud Worker PostgreSQL.
nodeport int Numéro de port sur lequel le nœud worker PostgreSQL écoute.
noderack text (Facultatif) Informations de sélection élective du rack pour le nœud Worker.
hasmetadata boolean Réservé à un usage interne.
isactive boolean Indique si le nœud est actif et accepte les sélections électives de partition.
noderole text Si le nœud est un nœud principal ou secondaire
nodecluster text Nom du cluster contenant ce nœud
shouldhaveshards boolean Si la valeur est false, les partitions sont déplacées hors du nœud (drainées) lors du rééquilibrage, et les partitions de nouvelles tables distribuées sont placées sur le nœud, sauf s’ils sont colocalisés avec des partitions déjà présentes.
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)

Table d’objet distribuée

La table citus.pg_dist_object contient une liste d’objets tels que les types et les fonctions qui ont été créés sur le nœud coordinateur et propagés aux nœuds Worker. Lorsqu’un administrateur ajoute de nouveaux nœuds Worker au cluster, Azure Cosmos DB for PostgreSQL crée automatiquement des copies des objets distribués sur les nouveaux nœuds (dans le bon ordre pour répondre aux dépendances des objets).

Nom Type Description
classid oid Classe de l’objet distribué
objid oid ID d’objet de l’objet distribué
objsubid entier Sous-ID d’objet de l’objet distribué, par exemple, attnum
type text Partie de l’adresse stable utilisée lors des mises à niveau de pg
object_names text[] Partie de l’adresse stable utilisée lors des mises à niveau de pg
object_args text[] Partie de l’adresse stable utilisée lors des mises à niveau de pg
distribution_argument_index entier Valide uniquement pour les fonctions/procédures distribuées
colocationid entier Valide uniquement pour les fonctions/procédures distribuées

Les adresses stables identifient de manière unique les objets indépendamment d’un serveur spécifique. Azure Cosmos DB for PostgreSQL effectue le suivi des objets au cours d’une mise à niveau PostgreSQL à l’aide d’adresses stables créées avec la fonction pg_identify_object_as_address().

Voici un exemple de comment create_distributed_function() ajoute des entrées à la table 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                |

Vue de schémas distribués

Citus 12.0 a introduit le concept de partitionnement basé sur le schéma, et avec lui la vue « citus_schemas », qui montre quels schémas ont été distribués dans le système. La vue liste uniquement les schémas distribués ; les schémas locaux ne sont pas affichés.

Nom Type Description
schema_name regnamespace Nom du schéma distribué
colocation_id entier ID de colocalisation du schéma distribué
schema_size texte Synthèse de la taille (lisible par l’homme) de tous les objets dans le schéma
schema_owner name Rôle propriétaire du schéma

Voici un exemple :

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

Vue des tables distribuées

La vue citus_tables présente un résumé de toutes les tables gérées par Azure Cosmos DB for PostgreSQL (tables distribuées et de référence). La vue combine les informations des tables de métadonnées Azure Cosmos DB for PostgreSQL pour offrir une vue d’ensemble conviviale des propriétés de table suivantes :

  • Type de la table
  • Colonne de distribution
  • ID de groupe de colocalisation
  • Taille explicite
  • Nombre de partitions
  • Propriétaire (utilisateur de base de données)
  • Méthode d’accès (segment de mémoire ou en colonnes)

Voici un exemple :

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          │
└────────────┴──────────────────┴─────────────────────┴───────────────┴────────────┴─────────────┴─────────────┴───────────────┘

Vue des partitions de temps

Azure Cosmos DB pour PostgreSQL fournit des fonctions définies par l’utilisateur (UDF) permettant de gérer des partitions pour le cas d’utilisation des données de série chronologique. Il tient également à jour une vue time_partitions pour inspecter les partitions qu’il gère.

Colonnes :

  • parent_table : table partitionnée
  • partition_column : colonne sur laquelle la table parente est partitionnée
  • partition : nom d’une table de partition
  • from_value : limite temporelle inférieure pour les lignes de cette partition
  • to_value : limite temporelle supérieure pour les lignes de cette partition
  • access_method : heap pour le stockage basé sur les lignes et columnar pour le stockage en colonnes
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          │
└────────────────────────┴──────────────────┴─────────────────────────────────────────┴─────────────────────┴─────────────────────┴───────────────┘

Table de groupe de colocation

La table pg_dist_colocation contient des informations sur les tables partitions devant être placées ensemble ou colocalisée. Lorsque deux tables se trouvent dans le même groupe de colocalisation, Azure Cosmos DB for PostgreSQL garantit que les partitions avec les mêmes valeurs de colonne de distribution seront placées sur les mêmes nœuds Worker. La colocation active les optimisations de jointure, certains rollups distribués et la prise en charge de clé étrangère. La colocalisation de partition est déduite lorsque le nombre de partitions, les facteurs de réplication et les types de colonne de partition correspondent tous entre deux tables. Toutefois, un groupe de colocalisation personnalisé peut être spécifié lors de la création d’une table distribuée, si vous le souhaitez.

Nom Type Description
colocationid int Identificateur unique du groupe de colocation auquel cette ligne correspond.
shardcount int Nombre de partitions pour toutes les tables de ce groupe de colocation
replicationfactor int Facteur de réplication pour toutes les tables de ce groupe de colocation.
distributioncolumntype oid Type de la colonne de distribution pour toutes les tables de ce groupe de colocation.
SELECT * from pg_dist_colocation;
  colocationid | shardcount | replicationfactor | distributioncolumntype 
 --------------+------------+-------------------+------------------------
			 2 |         32 |                 2 |                     20
  (1 row)

Table de stratégie de rééquilibrage

Ce tableau définit les stratégies que rebalance_table_shards peut utiliser pour déterminer où déplacer les partitions.

Nom Type Description
default_strategy boolean Indique si rebalance_table_shards doit choisir cette stratégie par défaut. Utiliser citus_set_default_rebalance_strategy pour mettre à jour cette colonne
shard_cost_function regproc Identificateur d’une fonction cost, qui doit prendre un shardid en tant que bigint et retourner sa notion de cost comme type réel
node_capacity_function regproc Identificateur d’une fonction capacity, qui doit prendre un nodeid en tant que int et retourner sa notion de node capacity (capacité de nœud) comme type réel
shard_allowed_on_node_function regproc Identificateur pour une fonction qui, avec un shardid bigint et un nodeidarg int donnés, retourne une valeur booléenne indiquant si Azure Cosmos DB for PostgreSQL peut stocker la partition sur le nœud
default_threshold float4 Seuil pour estimer qu’un nœud est trop plein ou trop vide, qui détermine quand le rebalance_table_shards doit essayer de déplacer les partitions
minimum_threshold float4 Protection permettant d’empêcher de définir l’argument du seuil rebalance_table_shards() à un niveau trop bas

Par défaut, Azure Cosmos DB for PostgreSQL est fourni avec les stratégies suivantes dans la table :

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

La stratégie by_disk_size affecte à chaque partition le même coût. Son effet est d’égaliser le nombre de partition entre les nœuds. La stratégie par défaut, by_disk_size, attribue un coût à chaque partition correspondant à sa taille de disque en octets plus celle des partitions colocalisées avec. La taille du disque est calculée à l’aide de pg_total_relation_size, ce qui signifie qu’elle comprend des index. Cette stratégie tente d’obtenir le même espace disque sur chaque nœud. Notez le seuil de 0.1, qui empêche les mouvements de partition inutiles causés par des différences non significatives dans l’espace disque.

Création de stratégies de rééquilibrage personnalisées

Voici des exemples de fonctions qui peuvent être utilisées dans les nouvelles stratégies de rééquilibrage partition et enregistrées dans le pg_dist_rebalance_strategy avec la fonction citus_add_rebalance_strategy.

  • Définition d’une exception de capacité de nœud par modèle de nom d’hôte :

    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;
    
  • Rééquilibrage en fonction du nombre de requêtes qui accèdent à un partition, tel qu’il est mesuré par le 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;
    
  • Isolation d’une partition spécifique (10000) sur un nœud (adresse 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;
    

Table des statistiques sur les requêtes

Azure Cosmos DB for PostgreSQL fournit citus_stat_statements pour des statistiques sur la façon dont les requêtes sont exécutées et pour qui. Elle est analogue à (et peut être joint avec) la vue pg_stat_statements dans PostgreSQL, qui effectue le suivi des statistiques sur la vitesse des requêtes.

Cette vue peut suivre les requêtes jusqu’aux locataires d’origine dans une application multilocataire, ce qui permet de décider quand procéder à l’isolation des locataires.

Nom Type Description
queryid bigint identificateur (correct pour les jointures de pg_stat_statements)
userid oid utilisateur qui a exécuté la requête
dbid oid instance de base de données du coordinateur
query text chaîne de requête anonyme
exécuteur text Citus executor utilisé : adaptatif, en temps réel, suivi des tâches, routeur ou insert-select
partition_key text valeur de la colonne de distribution dans les requêtes exécutées par le routeur, sinon NULL
calls bigint nombre de fois où la requête a été exécutée
-- 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;

Résultats :

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

Avertissements :

  • Les données de statistiques ne sont pas répliquées et ne survivent pas à des pannes de base de données ou à un basculement
  • Effectue le suivi d’un nombre limité de requêtes, défini par le pg_stat_statements.max GUC (par défaut 5000)
  • Pour tronquer la table, utilisez la fonction citus_stat_statements_reset()

Activité des requêtes distribuées

Azure Cosmos DB for PostgreSQL fournit des affichages spéciaux pour surveiller les requêtes et les verrous dans le cluster, y compris les requêtes spécifiques à une partition utilisées en interne pour générer les résultats des requêtes distribuées.

  • citus_dist_stat_activity : affiche les requêtes distribuées qui s’exécutent sur tous les nœuds. Sur-ensemble de pg_stat_activity, utilisable partout où se trouve ce dernier.
  • citus_worker_stat_activity : affiche les requêtes sur les Workers, y compris les requêtes de fragment sur les partitions individuels.
  • citus_lock_waits : Requêtes bloquées dans le cluster.

Les deux premières vues incluent toutes les colonnes de pg_stat_activity plus l’hôte/port hôte du Worker qui a initié la requête et l’hôte/port du nœud coordinateur du cluster.

Par exemple, envisagez de compter les lignes dans une table distribuée :

-- run from worker on localhost:9701

SELECT count(*) FROM users_table;

Nous pouvons voir que la requête apparaît dans 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

Cette requête nécessite des informations de toutes les partitions. Certaines informations se trouvent dans la partition users_table_102038, qui est stockée dans localhost:9700. Nous pouvons voir une requête qui accède à la partition en examinant l’affichage 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

Le champ query affiche les données copiées en dehors de la partition à compter.

Notes

Si une requête de routeur (par exemple, un locataire unique dans une application multi-entité, `SELECT

  • FROM_table_WHERE_tenant_id = X’) est exécutée sans bloc de transaction, alors les colonnes master_query_host_name et master_query_host_port seront NULL dans citus_worker_stat_activity.

Voici des exemples de requêtes utiles que vous pouvez générer à l’aide de 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;

La vue suivante est citus_lock_waits. Pour voir comment elle fonctionne, nous pouvons générer une situation de verrouillage manuellement. Tout d’abord, nous allons configurer une table de test à partir du coordinateur :

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

Ensuite, à l’aide de deux sessions sur le coordinateur, nous pouvons exécuter cette séquence d’instructions :

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

L’affichage citus_lock_waits montre la situation.

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

Dans cet exemple, les requêtes proviennent du coordinateur, mais l’affichage peut également répertorier les verrous entre les requêtes provenant de rôles de travail (exécutées, par exemple, avec Azure Cosmos DB for PostgreSQL MX).

Étapes suivantes