Azure Cosmos DB für PostgreSQL-Systemtabellen und Ansichten

GILT FÜR: Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)

Azure Cosmos DB für PostgreSQL erstellt und verwaltet spezielle Tabellen, die Informationen über verteilte Daten im Cluster enthalten. Der Koordinatorknoten zieht diese Tabellen zu Rate, wenn er plant, wie Abfragen auf den Workerknoten ausgeführt werden sollen.

Koordinatormetadaten

Azure Cosmos DB für PostgreSQL unterteilt jede verteilte Tabelle in mehrere logische Blöcke auf der Grundlage der Verteilungsspalte. Der Koordinator verwaltet dann Metadatentabellen, um Statistiken und Informationen zur Integrität und zum Speicherort dieser Shards nachzuverfolgen.

In diesem Abschnitt wird jede dieser Metadatentabellen sowie das jeweils zugehörige Schema beschrieben. Sie können diese Tabellen nach der Anmeldung beim Koordinatorknoten mithilfe von SQL anzeigen und abfragen.

Partitionstabelle

Die pg_dist_partition-Tabelle speichert Metadaten dazu, welche Tabellen in der Datenbank verteilte Tabellen sind. Für jede verteilte Tabelle speichert sie auch Informationen zur Verteilungsmethode und detaillierte Informationen zur Verteilungsspalte.

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)

Shardtabelle

In der pg_dist_shard-Tabelle werden Metadaten zu einzelnen Shards einer Tabelle gespeichert. Pg_dist_shard enthält Informationen dazu, zu welcher verteilten Tabelle Sards gehören, sowie Statistiken zur Verteilungsspalte für Shards. Für verteilte Tabellen vom Typ „Anfügen“ entsprechen diese Statistiken den Minimal-/Maximalwerten der Verteilungsspalte. Bei Tabellen mit Hashverteilung handelt es sich um Hashtokenbereiche, die diesem Shard zugewiesen sind. Diese Statistiken werden zum Bereinigen nicht verknüpfter Shards während SELECT-Abfragen verwendet.

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)

Shardspeichertypen

Die shardstorage-Spalte in pg_dist_shard gibt den Typ des für den Shard verwendeten Speichers an. Eine kurze Übersicht über die verschiedenen Shardspeichertypen und deren Darstellung finden Sie unten.

Ansicht für Shardinformationen

Zusätzlich zu der oben beschriebenen Metadaten-Tabelle für Blöcke auf niedriger Ebene bietet Azure Cosmos DB für PostgreSQL eine citus_shards-Ansicht zur einfachen Überprüfung:

• Position der einzelnen Shards (Knoten und Port)
• Art der zugehörigen Tabelle
• Größe

Mit dieser Ansicht können Sie Shards untersuchen, um u. a. Ungleichheiten in Bezug auf die Größe in allen Knoten zu ermitteln.

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

„colocation_id“ bezieht sich auf die Zusammenstellungsgruppe.

Shardplatzierungstabelle

Die pg_dist_placement-Tabelle verfolgt den Speicherort von Shardreplikaten auf Workerknoten nach. Jedes Replikat eines Shards, das einem bestimmten Knoten zugewiesen ist, wird als Shardplatzierung bezeichnet. In dieser Tabelle werden Informationen zur Integrität und zum Speicherort der einzelnen Shardplatzierungen gespeichert.

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

Shardplatzierungszustände

Azure Cosmos DB für PostgreSQL verwaltet die Integrität der Blöcke auf einer Basis pro Standort. Wenn eine Platzierung das System in einen inkonsistenten Zustand versetzt, markiert Azure Cosmos DB für PostgreSQL sie automatisch als nicht verfügbar. Der Platzierungszustand wird in der pg_dist_shard_placement-Tabelle innerhalb der shardstate-Spalte aufgezeichnet. Im Folgenden finden Sie eine kurze Übersicht über die verschiedenen Shardplatzierungszustände:

Workerknotentabelle

Die pg_dist_node-Tabelle enthält Informationen zu den Workerknoten im Cluster.

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

Tabelle verteilter Objekte

Die Citus.pg_dist_object-Tabelle enthält eine Liste von Objekten, z. B. von Typen und Funktionen, die auf dem Koordinatorknoten erstellt und an Workerknoten weitergegeben wurden. Wenn ein Administrator dem Cluster neue Workerknoten hinzufügt, erstellt Azure Cosmos DB für PostgreSQL automatisch Kopien der verteilten Objekte auf den neuen Knoten (in der richtigen Reihenfolge, um Objektabhängigkeiten zu erfüllen).

„Stabile Adressen“ identifizieren Objekte unabhängig von einem bestimmten Server eindeutig. Azure Cosmos DB für PostgreSQL verfolgt Objekte während eines PostgreSQL-Upgrades mithilfe stabiler Adressen nach, die mit der pg_identify_object_as_address()-Funktion erstellt werden.

Hier sehen Sie ein Beispiel dafür, wie create_distributed_function() der citus.pg_dist_object-Tabelle Einträge hinzufügt:

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                |

Ansicht für verteilte Schemas

Citus 12.0 hat das Konzept des schemabasierten Shardings und damit die Ansicht „citus_schemas“ eingeführt, die zeigt, welche Schemas im System verteilt wurden. In der Ansicht werden nur verteilte Schemas aufgelistet, lokale Schemas werden nicht angezeigt.

Hier ist ein Beispiel angegeben:

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

Ansicht für verteilte Tabellen

Die Ansicht citus_tables zeigt eine Zusammenfassung aller Tabellen, die von Azure Cosmos DB für PostgreSQL verwaltet werden (verteilte Tabellen und Verweistabellen). Die Ansicht kombiniert Informationen aus Metadatentabellen von Azure Cosmos DB für PostgreSQL, um eine einfache, lesbare Übersicht über diese Tabelleneigenschaften zu erhalten:

• Tabellentyp
• Verteilungsspalte
• ID der Zusammenstellungsgruppe
• Lesbare Größe
• Shardanzahl
• Besitzer (Datenbankbenutzer)
• Zugriffsmethode (Heap oder Spalte)

Hier ist ein Beispiel angegeben:

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

Ansicht für Zeitpartitionen

Azure Cosmos DB für PostgreSQL bietet UDFs zur Verwaltung von Partitionen für den Anwendungsfall Zeitreihendaten. Außerdem wird eine time_partitions-Ansicht zur Überprüfung der verwalteten Partitionen bereitgestellt.

Spalten:

• parent_table: Die Tabelle, die partitioniert wird
• partition_column: Die Spalte, nach der die übergeordnete Tabelle partitioniert wird
• partition: Der Name einer Partitionstabelle
• from_value: Untere Zeitgrenze für Zeilen in dieser Partition
• to_value: Obere Zeitgrenze für Zeilen in dieser Partition
• access_method: „heap“ für zeilenbasierten Speicher und „columnar“ für spaltenbasierten Speicher

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

Tabelle der Colocationsgruppe

Die pg_dist_colocation-Tabelle enthält Informationen dazu, in welchen Tabellen Shards zusammen platziert werden sollen (Colocation). Wenn sich zwei Tabellen in derselben Zusammenstellungsgruppe befinden, stellt Azure Cosmos DB für PostgreSQL sicher, dass Blöcke mit denselben Verteilungsspaltenwerten in denselben Workerknoten platziert werden. Colocation ermöglicht Joinoptimierungen, bestimmte verteilte Rollups und Fremdschlüsselunterstützung. Shardzusammenstellung wird eingeleitet, wenn die Shardanzahl, Replikationsfaktoren und Partitionsspaltentypen zwischen zwei Tabellen insgesamt übereinstimmen. Wenn dies gewünscht wird, kann jedoch eine benutzerdefinierte Zusammenstellungsgruppe angegeben werden, wenn eine verteilte Tabelle erstellt wird.

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

Rebalancer-Strategietabelle

Diese Tabelle definiert Strategien, die rebalance_table_shards verwenden kann, um zu bestimmen, wohin Shards verschoben werden sollen.

Standardmäßig wird Cosmos DB für PostgreSQL mit diesen Strategien in der Tabelle ausgeliefert:

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

Die Strategie by_disk_size weist jedem Shard dieselben Kosten zu. Ihre Auswirkung besteht darin, die Anzahl der Shards knotenübergreifend auszugleichen. Mit der Standardstrategie by_disk_size werden jedem Shard entsprechend seiner Datenträgergröße in Bytes zuzüglich der Datenträgergröße der Shards, für die Colocation vorliegt, Kosten zugewiesen. Die Datenträgergröße wird mit pg_total_relation_sizeberechnet, sodass Indizes enthalten sind. Diese Strategie versucht, den gleichen Speicherplatz auf jedem Knoten zu erzielen. Beachten Sie den Schwellenwert von 0.1: Er verhindert unnötige Shardverschiebungen aufgrund unbedeutender Unterschiede im Speicherplatz.

Erstellen von benutzerdefinierten Rebalancerstrategien

Im folgenden finden Sie Beispiele für Funktionen, die in neuen Shardrebalancerstrategien verwendet und in pg_dist_rebalance_strategy mit der citus_add_rebalance_strategy-Funktion registriert werden.

• Festlegen einer Knotenkapazitätsausnahme nach dem hostname-Muster:

  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;
  

• Neuzuordnung nach Anzahl von Abfragen für einen Shard, gemessen durch 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;
  

• Isolieren eines bestimmten Shards (10000) auf einem Knoten (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;
  

Abfragen der Statistiktabelle

Azure Cosmos DB für PostgreSQL bietet citus_stat_statements für Statistiken zur Ausführung von Abfragen und zum Abfrageziel. Das Element ist analog zur pg_stat_statements-Sicht in PostgreSQL (und kann mit ihr verknüpft werden), die Statistiken zur Abfragegeschwindigkeit nachverfolgt.

In dieser Sicht können Abfragen von Ursprungsmandanten in einer mehrinstanzenfähigen Anwendung überwacht werden. Dies hilft bei der Entscheidung, wann Mandantenisolation ausgeführt werden sollte.

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

Ergebnisse:

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

Zu beachten:

• Die Statistikdaten werden nicht repliziert und überstehen keine Datenbankabstürze oder Failovervorgänge.
• Verfolgt eine begrenzte Anzahl von Abfragen nach, die vom pg_stat_statements.max-GUC (Standardwert 5.000) festgelegt werden.
• Verwenden Sie die citus_stat_statements_reset()-Funktion, um die Tabelle abzuschneiden.

Aktivität verteilter Abfragen

Azure Cosmos DB für PostgreSQL bietet spezielle Ansichten zum Überwachen von Abfragen und Sperren im gesamten Cluster, einschließlich blockspezifischer Abfragen, die intern zum Erstellen von Ergebnissen für verteilte Abfragen verwendet werden.

• citus_dist_stat_activity: Zeigt die verteilten Abfragen an, die auf allen Knoten ausgeführt werden. Eine Obermenge von pg_stat_activity, die überall dort verwendet werden kann, wo sich dieses Element befindet.
• citus_worker_stat_activity: Zeigt Abfragen für Worker an, einschließlich Fragmentabfragen für einzelne Shards.
• citus_lock_waits: Blockierte Abfragen im gesamten Cluster.

Die ersten beiden Sichten enthalten alle Spalten von pg_stat_activity sowie den Host Host/Port des Workers, der die Abfrage initiiert hat, und den Host/Port des Koordinatorknotens des Clusters.

Zählen Sie beispielsweise die Zeilen in einer verteilten Tabelle:

-- run from worker on localhost:9701

SELECT count(*) FROM users_table;

Sie sehen, dass die Abfrage in citus_dist_stat_activity angezeigt wird:

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

Diese Abfrage erfordert Informationen aus allen Shards. Einige der Informationen befinden sich in Shard users_table_102038, der in localhost:9700 gespeichert wird. Eine Abfrage, die auf den Shard zugreift, wird in der citus_worker_stat_activity-Sicht angezeigt:

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

Im Feld query werden Daten angezeigt, die aus dem Shard kopiert werden, um gezählt zu werden.

Im Folgenden sind Beispiele für nützliche Abfragen aufgeführt, die Sie mit citus_worker_stat_activity erstellen können:

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

Die nächste Ansicht ist citus_lock_waits. Um zu sehen, wie diese Ansicht funktioniert, können Sie manuell eine Sperrsituation generieren. Hierzu richten Sie zunächst über den Koordinator eine Testtabelle ein:

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

Anschließend können Sie mit zwei Sitzungen für den Koordinator diese Sequenz von Anweisungen ausführen:

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

Die citus_lock_waits-Sicht zeigt die 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

In diesem Beispiel stammen die Abfragen vom Koordinator, aber die Ansicht kann auch Sperren zwischen Abfragen auflisten, die von Workern stammen (z. B. mit Azure Cosmos DB für PostgreSQL MX).

Nächste Schritte

• Erfahren Sie, wie einige Azure Cosmos DB für PostgreSQL-Funktionen Systemtabellen ändern
• Machen Sie sich mit den Konzepten von Knoten und Tabellen vertraut.