Системные таблицы и представления Azure Cosmos DB для PostgreSQL
Область применения: Azure Cosmos DB для PostgreSQL (на базе расширения базы данных Citus до PostgreSQL)
Azure Cosmos DB для PostgreSQL создает и поддерживает специальные таблицы, содержащие сведения о распределенных данных в кластере. Узел координатора обращается к этим таблицам, когда планирует выполнение запросов между рабочими узлами.
Метаданные координатора
Azure Cosmos DB для PostgreSQL делит каждую распределенную таблицу на несколько логических сегментов на основе столбца распространения. Затем координатор обслуживает таблицы метаданных для сбора статистики и сведений о работоспособности и расположении этих сегментов.
В этом разделе мы рассмотрим каждую из этих таблиц метаданных и их схему. Вы можете просматривать эти таблицы и запрашивать из них данные с помощью SQL после входа на узел-координатор.
Примечание.
Кластеры под управлением более ранних версий подсистемы Citus могут не предлагать все таблицы, перечисленные ниже.
Таблица разделов
В таблице pg_dist_partition хранятся метаданные о том, какие таблицы распределены в базе данных. Для каждой распределенной таблицы также хранятся сведения о методе распределения и подробная информация о столбце распределения.
Имя. | Тип | Описание |
---|---|---|
logicalrelid | regclass | Распределенная таблица, которой соответствует эта строка. Это значение ссылается на столбец relfilenode в таблице системного каталога pg_class. |
partmethod | char | Метод, используемый для секционирования и распределения. Значения этого столбца, соответствующие разным методам распределения: добавление — "a", хэш — "h", ссылочная таблица — "n". |
partkey | text | Подробные сведения о столбце распределения, включая номер столбца, тип и другие сведения. |
colocationid | integer | Группа совместного размещения, к которой принадлежит данная таблица. Таблицы в одной группе, помимо прочих вариантов оптимизации, поддерживают совместные объединения и распределенные свертки. Это значение ссылается на столбец colocationid в таблице pg_dist_colocation. |
repmodel | char | Метод, используемый для репликации данных. Значения этого столбца, соответствующие разным методам репликации: репликация Citus на основе инструкций — "c", репликация потоковой передачи postgresql — "s", двухфазной фиксация (для ссылочных таблиц) — "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)
Таблица сегментов
В таблице сегментов pg_dist_shard хранятся метаданные об отдельных сегментах таблицы. pg_dist_shard содержит сведения о том, к каким сегментам распределенных таблиц относятся данные, и статистику по столбцу распределения для сегментов. Для распределенных таблиц с добавлением эти статистические данные соответствуют минимальным и максимальным значениям столбца распределения. Для распределенных таблиц с хэшем они являются диапазонами хэш-токенов, назначенными этому сегменту. Эти статистические данные используются для удаления несвязанных сегментов во время запросов SELECT.
Имя. | Тип | Описание |
---|---|---|
logicalrelid | regclass | Распределенная таблица, которой соответствует эта строка. Это значение ссылается на столбец relfilenode в таблице системного каталога pg_class. |
shardid | bigint | Глобальный уникальный идентификатор, назначенный этому сегменту. |
shardstorage | char | Тип хранилища, используемый для этого сегмента. В таблице ниже описаны различные типы хранилищ. |
shardminvalue | text | Для распределенных таблиц с добавлением — минимальное значение столбца распределения в этом сегменте (включительно). Для распределенных таблиц с хэшем — значение минимального хэш-токена, назначенного этому сегменту (включительно). |
shardmaxvalue | text | Для распределенных таблиц с добавлением — максимальное значение столбца распределения в этом сегменте (включительно). Для распределенных таблиц с хэшем — значение максимального хэш-токена, назначенного этому сегменту (включительно). |
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)
Типы хранилища сегментов
Столбец shardstorage в таблице pg_dist_shard обозначает тип хранилища, используемого для сегмента. Ниже приведен краткий обзор различных типов хранилищ для сегментов и их представлений.
Тип хранилища | Значение shardstorage | Description |
---|---|---|
TABLE | "t" | Указывает, что сегмент хранит данные, относящиеся к обычной распределенной таблице. |
COLUMNAR | "c" | Указывает, что сегмент хранит данные столбцов. (Используется распределенными таблицами distributed cstore_fdw.) |
FOREIGN | "f" | Указывает, что сегмент хранит внешние данные. (Используется распределенными таблицами file_fdw.) |
Представление сведений о сегментах
Помимо таблицы метаданных сегментов низкого уровня, описанной citus_shards
выше, Azure Cosmos DB для PostgreSQL предоставляет представление, чтобы легко проверить:
- Расположение каждого сегмента (узел и порт)
- Тип таблицы, к которой он относится
- Его размер
Это представление помогает изучать сегменты, позволяя, среди прочего, находить дисбаланс по размеру между узлами.
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 ссылается на группу совместного размещения.
Таблица размещения сегментов
Таблица pg_dist_placement отслеживает расположение реплик сегментов на рабочих узлах. Каждая реплика сегмента, назначенного определенному узлу, называется размещением сегментов. В этой таблице хранятся сведения о работоспособности и расположении каждого размещения сегментов.
Имя. | Тип | Описание |
---|---|---|
shardid | bigint | Идентификатор сегмента, связанный с этим размещением. Это значение ссылается на столбец shardid в таблице каталога pg_dist_shard. |
shardstate | INT | Описывает состояние этого размещения. Различные состояния сегментов рассматриваются в разделе ниже. |
shardlength | bigint | Для распределенных таблиц с добавлением — размер размещения сегментов на рабочем узле в байтах. Для распределенных таблиц с хэшем — ноль. |
placementid | bigint | Уникальный автоматически сформированный идентификатор каждого отдельного размещения. |
groupid | INT | Обозначает группу из одного основного сервера и ноля или большего числа серверов-получателей при использовании потоковой модели репликации. |
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
Состояния размещения сегментов
Azure Cosmos DB для PostgreSQL управляет работоспособностью сегментов на основе размещения. Если размещение помещает систему в несогласованное состояние, Azure Cosmos DB для PostgreSQL автоматически помечает ее как недоступную. Состояние размещения заносится в таблицу pg_dist_shard_placement в столбец shardstate. Ниже приведен краткий обзор различных состояний размещения сегментов.
Название штата | Значение Shardstate | Description |
---|---|---|
FINALIZED | 1 | Состояние, в котором создаются новые сегменты. Размещения сегментов в этом состоянии считаются актуальными и используются при планировании и выполнении запросов. |
НЕАКТИВНЫЙ | 3 | Размещения сегментов в этом состоянии считаются неактивными из-за отсутствия синхронизации с другими репликами того же сегмента. Это состояние может возникать при сбое операций добавления, изменения (вставки, обновления, удаления) или операции DDL для этого размещения. Планировщик запросов будет игнорировать размещения в этом состоянии во время планирования и выполнения. Пользователи могут синхронизировать данные в этих сегментах с конечной репликой с помощью фонового действия. |
TO_DELETE | 4 | Если Azure Cosmos DB для PostgreSQL пытается удалить размещение сегментов в ответ на вызов master_apply_delete_command и завершится сбоем, размещение перемещается в это состояние. Затем пользователь может удалить такой сегмент с помощью фонового действия. |
Таблица рабочих узлов
Таблица pg_dist_node содержит сведения о рабочих узлах в кластере.
Имя. | Тип | Описание |
---|---|---|
nodeid | INT | Автоматически сформированный идентификатор для отдельного узла. |
groupid | INT | Идентификатор обозначает группу из одного основного сервера и серверов-получателей (в количестве ноль или более) при использовании потоковой модели репликации. По умолчанию совпадает с nodeid. |
nodename | text | Имя узла или IP-адрес рабочего узла PostgreSQL. |
nodeport | INT | Номер порта, на котором выполняет прослушивание рабочий узел PostgreSQL. |
noderack | text | Необязательно: сведения о размещении в стойке для рабочего узла. |
hasmetadata | boolean | Зарезервировано для внутреннего использования. |
isactive | boolean | Является ли узел активным и принимает ли он размещения сегментов. |
noderole | text | Является ли узел первичным или вторичным. |
nodecluster | text | Имя кластера, содержащего данный узел. |
shouldhaveshards | boolean | Если задано значение false, при повторной балансировке сегменты будут перемещены из узла (очищены), а сегменты из новых распределенных таблиц не будут помещены на узел, если только они не расположены вместе с уже находящимися там сегментами. |
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)
Таблица распределенных объектов
Таблица citus.pg_dist_object содержит список объектов, таких как типы и функции, которые были созданы на узле-координаторе и распространены на рабочие узлы. Когда администратор добавляет новые рабочие узлы в кластер, Azure Cosmos DB для PostgreSQL автоматически создает копии распределенных объектов на новых узлах (в правильном порядке для удовлетворения зависимостей объектов).
Имя. | Тип | Описание |
---|---|---|
classid | oid | Класс распределенного объекта |
objid | oid | Идентификатор распределенного объекта |
objsubid | integer | Подчиненный идентификатор распределенного объекта, например attnum |
type | text | Часть стабильного адреса, используемого во время обновления pg |
object_names | text[] | Часть стабильного адреса, используемого во время обновления pg |
object_args | text[] | Часть стабильного адреса, используемого во время обновления pg |
distribution_argument_index | integer | Действительно только для распределенных функций и процедур |
colocationid | integer | Действительно только для распределенных функций и процедур |
"Стабильные адреса" однозначным образом идентифицируют объекты независимо от конкретного сервера. Azure Cosmos DB для PostgreSQL отслеживает объекты во время обновления PostgreSQL с использованием стабильных адресов, созданных с помощью функции pg_identify_object_as_address().
Ниже приведен пример того, как create_distributed_function()
добавляет записи в таблицу 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 |
Представление распределенных схем
Citus 12.0 представил концепцию сегментирования на основе схемы и с ним представление "citus_schemas", показывающее, какие схемы были распределены в системе. В представлении перечислены только распределенные схемы, локальные схемы не отображаются.
Имя. | Тип | Описание |
---|---|---|
schema_name | regnamespace | Имя распределенной схемы |
colocation_id | integer | Идентификатор размещения распределенной схемы |
schema_size | text | Сводка по размеру для чтения всех объектов в схеме |
schema_owner | name | Роль, которая владеет схемой |
Ниже приведен пример.
schema_name | colocation_id | schema_size | schema_owner
-------------+---------------+-------------+--------------
userservice | 1 | 0 bytes | userservice
timeservice | 2 | 0 bytes | timeservice
pingservice | 3 | 632 kB | pingservice
Представление распределенных таблиц
В citus_tables
представлении показана сводка всех таблиц, управляемых Azure Cosmos DB для PostgreSQL (распределенных и ссылочных таблиц). Представление объединяет сведения из таблиц метаданных Azure Cosmos DB для PostgreSQL для простого и читаемого пользователем обзора этих свойств таблицы:
- Тип таблицы
- Столбец распределения
- Идентификатор группы совместного размещения
- Удобочитаемый размер
- Число сегментов
- Владелец (пользователь базы данных)
- Метод доступа (куча или по столбцам)
Ниже приведен пример.
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 │
└────────────┴──────────────────┴─────────────────────┴───────────────┴────────────┴─────────────┴─────────────┴───────────────┘
Представление временных секций
Azure Cosmos DB для PostgreSQL предоставляет определяемые пользователем функции для управления секциями для варианта использования данных Timeseries. Оно также поддерживает представление time_partitions
для проверки управляемых им секций.
Столбец
- parent_table — секционируемая таблица.
- partition_column — столбец, по которому секционируется родительская таблица
- partition — имя таблицы разделов
- from_value — нижняя граница по времени для строк в этой секции
- to_value — верхняя граница по времени для строк в этой секции
- access_method — куча для хранилища на основе строк и столбцы для хранилища на основе столбцов
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 │
└────────────────────────┴──────────────────┴─────────────────────────────────────────┴─────────────────────┴─────────────────────┴───────────────┘
Таблица групп совместного размещения
Таблица pg_dist_colocation содержит сведения о том, какие сегменты таблиц должны находиться в совместном размещении. Если две таблицы находятся в одной группе совместного размещения, Azure Cosmos DB для PostgreSQL гарантирует, что сегменты с одинаковыми значениями столбцов распространения будут помещены на одни и те же рабочие узлы. Совместное размещение позволяет оптимизировать соединения, определенные распределенные сводки и поддержку внешних ключей. Совместное размещение сегментов определяется, когда количество сегментов, факторы репликации и типы столбцов секций соответствуют двум таблицам; однако при создании распределенной таблицы можно указать настраиваемую группу совместного размещения, если это необходимо.
Имя. | Тип | Описание |
---|---|---|
colocationid | INT | Уникальный идентификатор группы совместного размещения, которой соответствует эта строка. |
shardcount | INT | Число сегментов для всех таблиц в этой группе совместного размещения. |
replicationfactor | INT | Коэффициент репликации для всех таблиц в этой группе совместного размещения. |
distributioncolumntype | oid | Тип столбца распределения для всех таблиц в этой группе совместного размещения. |
SELECT * from pg_dist_colocation;
colocationid | shardcount | replicationfactor | distributioncolumntype
--------------+------------+-------------------+------------------------
2 | 32 | 2 | 20
(1 row)
Таблица стратегии перераспределения
В этой таблице определяются стратегии, с помощью которых rebalance_table_shards определяют место перемещения сегментов.
Имя. | Тип | Описание |
---|---|---|
default_strategy | boolean | Следует ли rebalance_table_shards выбирать эту стратегию по умолчанию. Для обновления этого столбца используйте citus_set_default_rebalance_strategy. |
shard_cost_function | regproc | Идентификатор для функции затрат, который должен принимать shardid в качестве bigint и возвращать соответствующее значение стоимости типа real. |
node_capacity_function | regproc | Идентификатор для функции емкости, который должен принимать nodeid в качестве nodeid и возвращать соответствующее значение емкости узла типа real. |
shard_allowed_on_node_function | regproc | Идентификатор функции, заданной shardid bigint и nodeidarg int, возвращает логическое значение для того, может ли Azure Cosmos DB для PostgreSQL хранить сегмент на узле. |
default_threshold | float4 | Пороговое значение для определения заполненности или пустоты узла (от этого зависит, когда rebalance_table_shards пытается переместить сегменты). |
minimum_threshold | float4 | Механизм защиты, позволяющий избежать слишком низкого значения аргумента порогового значения rebalance_table_shards(). |
По умолчанию Cosmos DB для PostgreSQL поставляется с этими стратегиями в таблице:
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
Стратегия by_disk_size
назначает каждому сегменту одну и ту же стоимость. Она выравнивает число сегментов между узлами. Стратегия по умолчанию by_disk_size
назначает затраты на каждый сегмент, соответствующий размеру диска в байтах, а также сегменты, которые совместно используются вместе с ним. Размер диска вычисляется с использованием pg_total_relation_size
, поэтому включает индексы. Эта стратегия пытается уровнять дисковое пространство на узлах. Обратите внимание, что пороговое значение 0.1
не позволяет предотвратить ненужное перемещение сегментов, вызванное незначительными различиями в пространстве диска.
Создание пользовательских стратегий перераспределения
Ниже приведены примеры функций, которые можно использовать в новых стратегиях перераспределения сегментов и которые регистрируются в pg_dist_rebalance_strategy с помощью функции citus_add_rebalance_strategy.
Настройка исключения емкости узла по шаблону имени узла:
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;
Перераспределение по числу запросов, которые поступают в сегмент, согласно измерениям 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;
Изоляция определенного сегмента (10000) на узле (адрес 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;
Таблица статистики запросов
Azure Cosmos DB для PostgreSQL предоставляет citus_stat_statements
статистику о выполнении запросов и о том, для кого они выполняются. Она аналогична представлению pg_stat_statements в PostgreSQL, которое отслеживает статистику скорости запросов, и может соединяться с ним.
Это представление может трассировать запросы к исходному клиенту в мультитенантном приложении, которое помогает решить, когда нужно выполнить изоляцию клиента.
Имя. | Тип | Описание |
---|---|---|
queryid | bigint | Идентификатор (используется для соединений pg_stat_statements) |
userid | oid | Пользователь, выполнивший запрос |
dbid | oid | Экземпляр базы данных координатора |
query | text | Анонимизированная строка запроса |
executor | text | Исполнитель Citus: адаптивный, режим реального времени, отслеживание задач, маршрутизатор или вставка-выборка |
partition_key | text | Значение столбца распределения в запросах, выполненных маршрутизатором, иначе — NULL |
вызывает | bigint | Количество запусков запроса |
-- 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;
Результаты.
-[ 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
Предупреждения:
- Статистические данные не реплицируются и не сохраняются при сбоях базы данных или отработке отказа.
- Отслеживается ограниченное количество запросов, задаваемое параметром
pg_stat_statements.max
GUC (по умолчанию — 5000). - Чтобы усечь таблицу, используйте функцию
citus_stat_statements_reset()
.
Обработка распределенных запросов
Azure Cosmos DB для PostgreSQL предоставляет специальные представления для просмотра запросов и блокировок во всем кластере, включая запросы, относящиеся к сегменту, используемые внутренне для создания результатов для распределенных запросов.
- citus_dist_stat_activity: показывает распределенные запросы, выполняемые на всех узлах. Надмножество
pg_stat_activity
, доступное в той же области. - citus_worker_stat_activity: показывает запросы от рабочих ролей, включая фрагментные запросы к отдельным сегментам.
- citus_lock_waits: заблокированные запросы в кластере.
Первые два представления включают все столбцы pg_stat_activity, а также узел и порт рабочей роли, которая инициировала запрос, и узел и порт узла-координатора кластера.
Например, можно подсчитать число строк в распределенной таблице:
-- run from worker on localhost:9701
SELECT count(*) FROM users_table;
Можно увидеть, что запрос отображается в 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
Для этого запроса требуются данные из всех сегментов. Часть сведений находится в сегменте users_table_102038
, который хранится на узле localhost:9700
. Увидеть, как этот запрос обращается к сегменту, можно в представлении 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
В поле query
отображаются данные, которые копируются из сегмента для подсчета.
Примечание.
Если запрос маршрутизатора (например, один арендатор в мультитенантном приложении, SELECT
- FROM table WHERE tenant_id = X`) выполняется без блока транзакции, то столбцы master_query_host_name и master_query_host_port в таблице citus_worker_stat_activity будут иметь значение NULL.
Ниже приведены примеры полезных запросов, которые можно создать с помощью 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;
Следующее представление — citus_lock_waits
. Чтобы увидеть, как оно работает, можно создать ситуацию блокировки вручную. Сначала мы настроим тестовую таблицу с координатора:
CREATE TABLE numbers AS
SELECT i, 0 AS j FROM generate_series(1,10) AS i;
SELECT create_distributed_table('numbers', 'i');
Затем с помощью двух сеансов на координаторе можно выполнить следующую последовательность инструкций:
-- session 1 -- session 2
------------------------------------- -------------------------------------
BEGIN;
UPDATE numbers SET j = 2 WHERE i = 1;
BEGIN;
UPDATE numbers SET j = 3 WHERE i = 1;
-- (this blocks)
Эта ситуация отражена в представлении citus_lock_waits
.
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
В этом примере запросы, возникшие на координаторе, но представление также может перечислять блокировки между запросами, поступающими от рабочих ролей (выполняется с помощью Azure Cosmos DB для PostgreSQL MX для экземпляра).
Следующие шаги
- Узнайте, как некоторые функции Azure Cosmos DB для PostgreSQL изменяют системные таблицы
- Основные понятия узлов и таблиц