Tabele i widoki systemowe usługi Azure Cosmos DB for PostgreSQL
DOTYCZY: 
Usługa Azure Cosmos DB for PostgreSQL (obsługiwana przez rozszerzenie bazy danych Citus do bazy danych PostgreSQL)
Usługa Azure Cosmos DB for PostgreSQL tworzy i utrzymuje specjalne tabele zawierające informacje o danych rozproszonych w klastrze. Węzeł koordynacji sprawdza te tabele podczas planowania sposobu uruchamiania zapytań w węzłach procesu roboczego.
Metadane koordynatora
Usługa Azure Cosmos DB for PostgreSQL dzieli każdą tabelę rozproszoną na wiele logicznych fragmentów na podstawie kolumny dystrybucji. Następnie koordynator utrzymuje tabele metadanych w celu śledzenia statystyk i informacji o kondycji i lokalizacji tych fragmentów.
W tej sekcji opisano każdą z tych tabel metadanych i ich schemat. Te tabele można wyświetlać i wykonywać względem nich zapytania przy użyciu języka SQL po zalogowaniu się do węzła koordynatora.
Uwaga
klastry z starszymi wersjami aparatu Citus mogą nie oferować wszystkich tabel wymienionych poniżej.
Tabela partycji
Tabela pg_dist_partition przechowuje metadane dotyczące tabel w bazie danych. Dla każdej tabeli rozproszonej przechowuje również informacje o metodzie dystrybucji i szczegółowe informacje o kolumnie dystrybucji.
| Nazwisko | Pisz | Opis |
|---|---|---|
| logicalrelid | regclass | Tabela rozproszona, do której odpowiada ten wiersz. Ta wartość odwołuje się do kolumny relfilenode w tabeli katalogu systemu pg_class. |
| partmethod | char | Metoda używana do partycjonowania/dystrybucji. Wartości tej kolumny odpowiadającej różnym metodom dystrybucji są dołączane: "a", skrót: "h", tabela referencyjna: "n" |
| partkey | text | Szczegółowe informacje o kolumnie dystrybucji, w tym numer kolumny, typ i inne istotne informacje. |
| kolokacja | integer | Grupa kolokacji, do której należy ta tabela. Tabele w tej samej grupie umożliwiają współlokowane sprzężenia i rozproszone zestawienia między innymi optymalizacjami. Ta wartość odwołuje się do kolumny kolokacji w tabeli pg_dist_colocation. |
| repmodel | char | Metoda używana do replikacji danych. Wartości tej kolumny odpowiadające różnym metodom replikacji to: replikacja oparta na instrukcji Citus: "c", replikacja strumieniowa postgresql: "s", dwufazowe zatwierdzenie (dla tabel referencyjnych): "t" |
SELECT * from pg_dist_partition;
logicalrelid | partmethod | partkey | colocationid | repmodel
---------------+------------+------------------------------------------------------------------------------------------------------------------------+--------------+----------
github_events | h | {VAR :varno 1 :varattno 4 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 4 :location -1} | 2 | c
(1 row)
Tabela fragmentów
Tabela pg_dist_shard przechowuje metadane dotyczące poszczególnych fragmentów tabeli. Pg_dist_shard zawiera informacje o tym, do których należą fragmenty tabeli rozproszonej, oraz statystyki dotyczące kolumny dystrybucji dla fragmentów. W przypadku dołączanych tabel rozproszonych te statystyki odpowiadają minimalnym/maksymalnym wartościom kolumny dystrybucji. W przypadku tabel rozproszonych skrótów są one zakresami tokenów skrótów przypisanymi do tego fragmentu. Te statystyki są używane do oczyszczania niepowiązanych fragmentów podczas zapytań SELECT.
| Nazwisko | Pisz | Opis |
|---|---|---|
| logicalrelid | regclass | Tabela rozproszona, do której odpowiada ten wiersz. Ta wartość odwołuje się do kolumny relfilenode w tabeli katalogu systemu pg_class. |
| shardid | bigint | Unikatowy identyfikator globalny przypisany do tego fragmentu. |
| shardstorage | char | Typ magazynu używanego dla tego fragmentu. W poniższej tabeli omówiono różne typy magazynów. |
| shardminvalue | text | W przypadku dołączania tabel rozproszonych minimalna wartość kolumny dystrybucji w tym fragmentu (włącznie). W przypadku tabel rozproszonych skrótów minimalna wartość tokenu skrótu przypisana do tego fragmentu (włącznie). |
| shardmaxvalue | text | W przypadku dołączanych tabel rozproszonych maksymalna wartość kolumny dystrybucji w tym fragmentie (włącznie). W przypadku tabel rozproszonych skrótów maksymalna wartość tokenu skrótu przypisana do tego fragmentu (włącznie). |
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)
Typy magazynów fragmentów
Kolumna shardstorage w pg_dist_shard wskazuje typ magazynu używanego dla fragmentu. Poniżej przedstawiono krótkie omówienie różnych typów magazynów fragmentów i ich reprezentacji.
| Typ magazynu | Wartość fragmentów | opis |
|---|---|---|
| TABELA | 't' | Wskazuje, że fragment przechowuje dane należące do regularnej tabeli rozproszonej. |
| KOLUMNOWY | "c" | Wskazuje, że fragment przechowuje dane kolumnowe. (Używane przez rozproszone tabele cstore_fdw) |
| ZAGRANICZNY | "f" | Wskazuje, że fragment przechowuje obce dane. (Używane przez rozproszone tabele file_fdw) |
Widok informacji o fragmentach
Oprócz powyższej tabeli metadanych fragmentów niskiego poziomu usługa Azure Cosmos DB for PostgreSQL udostępnia citus_shards widok umożliwiający łatwe sprawdzanie:
- Gdzie każdy fragment to (węzeł i port),
- Jakiego rodzaju tabela należy do i
- Jego rozmiar
Ten widok ułatwia inspekcję fragmentów w celu znalezienia między innymi wszelkich dysproporcji rozmiaru w węzłach.
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 odnosi się do grupy kolokacji.
Tabela umieszczania fragmentów
Tabela pg_dist_placement śledzi lokalizację replik fragmentów w węzłach roboczych. Każda replika fragmentu przypisanego do określonego węzła jest nazywana rozmieszczeniem fragmentów. Ta tabela zawiera informacje o kondycji i lokalizacji każdego umieszczania fragmentów.
| Nazwisko | Pisz | Opis |
|---|---|---|
| shardid | bigint | Identyfikator fragmentu skojarzony z tym umieszczaniem. Ta wartość odwołuje się do kolumny shardid w tabeli wykazu pg_dist_shard. |
| shardstate | int | Opisuje stan tego umieszczania. W poniższej sekcji omówiono różne stany fragmentów. |
| fragmentowanie | bigint | W przypadku dołączanych tabel rozproszonych rozmiar umieszczania fragmentów w węźle procesu roboczego w bajtach. W przypadku tabel rozproszonych skrótów zero. |
| identyfikator umieszczania | bigint | Unikatowy automatycznie wygenerowany identyfikator dla każdego indywidualnego umieszczania. |
| groupid | int | Określa grupę jednego serwera podstawowego i zero lub więcej serwerów pomocniczych, gdy jest używany model replikacji przesyłania strumieniowego. |
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
Stany umieszczania fragmentów
Usługa Azure Cosmos DB for PostgreSQL zarządza kondycją fragmentów na podstawie poszczególnych miejsc. Jeśli umieszczanie umieszcza system w stanie niespójnym, usługa Azure Cosmos DB for PostgreSQL automatycznie oznacza go jako niedostępną. Stan umieszczania jest rejestrowany w tabeli pg_dist_shard_placement w kolumnie shardstate. Poniżej przedstawiono krótkie omówienie różnych stanów umieszczania fragmentów:
| State name | Wartość Shardstate | opis |
|---|---|---|
| SFINALIZOWANA | 1 | W programie są tworzone nowe fragmenty. Umieszczanie fragmentów w tym stanie jest uznawane za aktualne i używane w planowaniu i wykonywaniu zapytań. |
| NIEAKTYWNY | 3 | Umieszczanie fragmentów w tym stanie jest uznawane za nieaktywne z powodu braku synchronizacji z innymi replikami tego samego fragmentu. Stan może wystąpić, gdy dołączanie, modyfikowanie (INSERT, UPDATE, DELETE) lub operacja DDL kończy się niepowodzeniem dla tego umieszczania. Planista zapytań zignoruje umieszczanie w tym stanie podczas planowania i wykonywania. Użytkownicy mogą synchronizować dane w tych fragmentach z finalizowaną repliką jako działanie w tle. |
| TO_DELETE | 100 | Jeśli usługa Azure Cosmos DB for PostgreSQL próbuje usunąć umieszczanie fragmentów w odpowiedzi na wywołanie master_apply_delete_command i zakończy się niepowodzeniem, umieszczanie zostanie przeniesione do tego stanu. Użytkownicy mogą następnie usuwać te fragmenty jako kolejne działanie w tle. |
Tabela węzłów procesu roboczego
Tabela pg_dist_node zawiera informacje o węzłach procesu roboczego w klastrze.
| Nazwisko | Pisz | Opis |
|---|---|---|
| nodeid | int | Automatycznie wygenerowany identyfikator dla pojedynczego węzła. |
| groupid | int | Identyfikator używany do oznaczania grupy jednego serwera podstawowego i zera lub większej liczby serwerów pomocniczych, gdy jest używany model replikacji przesyłania strumieniowego. Domyślnie jest to samo co nodeid. |
| nodename | text | Nazwa hosta lub adres IP węzła procesu roboczego PostgreSQL. |
| nodeport | int | Numer portu, na którym nasłuchuje węzeł roboczy postgreSQL. |
| noderack | text | (Opcjonalnie) Informacje o umieszczaniu stojaka dla węzła roboczego. |
| hasmetadata | boolean | Zarezerwowane do użytku wewnętrznego. |
| isactive | boolean | Czy węzeł jest aktywny akceptujący umieszczanie fragmentów. |
| noderole | text | Czy węzeł jest podstawowym, czy pomocniczym |
| nodecluster | text | Nazwa klastra zawierającego ten węzeł |
| powinnyhaveshards | boolean | Jeśli wartość false, fragmenty zostaną przeniesione poza węzeł (opróżniony) podczas ponownego równoważenia, a fragmenty z nowych tabel rozproszonych zostaną umieszczone w węźle, chyba że zostaną przeniesione z fragmentami już tam |
SELECT * from pg_dist_node;
nodeid | groupid | nodename | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | shouldhaveshards
--------+---------+-----------+----------+----------+-------------+----------+----------+-------------+------------------
1 | 1 | localhost | 12345 | default | f | t | primary | default | t
2 | 2 | localhost | 12346 | default | f | t | primary | default | t
3 | 3 | localhost | 12347 | default | f | t | primary | default | t
(3 rows)
Tabela obiektów rozproszonych
Tabela citus.pg_dist_object zawiera listę obiektów, takich jak typy i funkcje utworzone w węźle koordynacji i propagowane do węzłów roboczych. Gdy administrator dodaje nowe węzły procesu roboczego do klastra, usługa Azure Cosmos DB for PostgreSQL automatycznie tworzy kopie obiektów rozproszonych w nowych węzłach (w odpowiedniej kolejności, aby spełnić zależności obiektów).
| Nazwisko | Pisz | Opis |
|---|---|---|
| classid | Oid | Klasa obiektu rozproszonego |
| objid | Oid | Identyfikator obiektu rozproszonego |
| objsubid | integer | Identyfikator podrzędny obiektu rozproszonego, na przykład attnum |
| type | text | Część stabilnego adresu używanego podczas uaktualniania pg |
| object_names | text[] | Część stabilnego adresu używanego podczas uaktualniania pg |
| object_args | text[] | Część stabilnego adresu używanego podczas uaktualniania pg |
| distribution_argument_index | integer | Tylko prawidłowe w przypadku funkcji/procedur rozproszonych |
| kolokacja | integer | Tylko prawidłowe w przypadku funkcji/procedur rozproszonych |
"Stabilne adresy" jednoznacznie identyfikują obiekty niezależnie od określonego serwera. Usługa Azure Cosmos DB for PostgreSQL śledzi obiekty podczas uaktualniania bazy danych PostgreSQL przy użyciu stabilnych adresów utworzonych za pomocą funkcji pg_identify_object_as_address().
Oto przykład dodawania create_distributed_function() wpisów do citus.pg_dist_object tabeli:
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 |
Widok schematów rozproszonych
Citus 12.0 wprowadził koncepcję fragmentowania opartego na schemacie oraz widoku "citus_schemas", który pokazuje, które schematy zostały rozproszone w systemie. Widok wyświetla tylko schematy rozproszone, schematy lokalne nie są wyświetlane.
| Nazwisko | Pisz | Opis |
|---|---|---|
| schema_name | regnamespace | Nazwa schematu rozproszonego |
| colocation_id | integer | Identyfikator kolokacji schematu rozproszonego |
| schema_size | text | Podsumowanie rozmiaru czytelnego dla człowieka wszystkich obiektów w schemacie |
| schema_owner | name | Rola będąca właścicielem schematu |
Oto przykład:
schema_name | colocation_id | schema_size | schema_owner
-------------+---------------+-------------+--------------
userservice | 1 | 0 bytes | userservice
timeservice | 2 | 0 bytes | timeservice
pingservice | 3 | 632 kB | pingservice
Widok tabel rozproszonych
Widok citus_tables przedstawia podsumowanie wszystkich tabel zarządzanych przez usługę Azure Cosmos DB for PostgreSQL (tabele rozproszone i referencyjne). Widok łączy informacje z tabel metadanych usługi Azure Cosmos DB for PostgreSQL w celu łatwego i czytelnego dla człowieka przeglądu tych właściwości tabeli:
- Typ tabeli
- Kolumna dystrybucji
- Identyfikator grupy kolokacji
- Rozmiar czytelny dla człowieka
- Liczba fragmentów
- Właściciel (użytkownik bazy danych)
- Metoda dostępu (sterta lub kolumna)
Oto przykład:
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 │
└────────────┴──────────────────┴─────────────────────┴───────────────┴────────────┴─────────────┴─────────────┴───────────────┘
Widok partycji czasowych
Usługa Azure Cosmos DB for PostgreSQL udostępnia funkcje zdefiniowane przez użytkownika do zarządzania partycjami dla przypadku użycia danych timeseries. Obsługuje time_partitions również widok inspekcji zarządzanych partycji.
Kolumny:
- parent_table tabeli podzielonej na partycje
- partition_column kolumnę, w której jest partycjonowana tabela nadrzędna
- partycjonowanie nazwy tabeli partycji
- from_value dolną granicę w czasie dla wierszy w tej partycji
- to_value górną granicę w czasie dla wierszy w tej partycji
- access_method sterta magazynu opartego na wierszach i kolumnowego magazynu kolumnowego
SELECT * FROM time_partitions;
┌────────────────────────┬──────────────────┬─────────────────────────────────────────┬─────────────────────┬─────────────────────┬───────────────┐
│ parent_table │ partition_column │ partition │ from_value │ to_value │ access_method │
├────────────────────────┼──────────────────┼─────────────────────────────────────────┼─────────────────────┼─────────────────────┼───────────────┤
│ github_columnar_events │ created_at │ github_columnar_events_p2015_01_01_0000 │ 2015-01-01 00:00:00 │ 2015-01-01 02:00:00 │ columnar │
│ github_columnar_events │ created_at │ github_columnar_events_p2015_01_01_0200 │ 2015-01-01 02:00:00 │ 2015-01-01 04:00:00 │ columnar │
│ github_columnar_events │ created_at │ github_columnar_events_p2015_01_01_0400 │ 2015-01-01 04:00:00 │ 2015-01-01 06:00:00 │ columnar │
│ github_columnar_events │ created_at │ github_columnar_events_p2015_01_01_0600 │ 2015-01-01 06:00:00 │ 2015-01-01 08:00:00 │ heap │
└────────────────────────┴──────────────────┴─────────────────────────────────────────┴─────────────────────┴─────────────────────┴───────────────┘
Tabela grupy kolokacji
Tabela pg_dist_colocation zawiera informacje o tym, które fragmenty tabel powinny być umieszczone razem lub kolokowane. Gdy dwie tabele znajdują się w tej samej grupie kolokacji, usługa Azure Cosmos DB for PostgreSQL zapewnia, że fragmenty z tymi samymi wartościami kolumn dystrybucji zostaną umieszczone w tych samych węzłach roboczych. Kolokacja umożliwia optymalizacje sprzężenia, niektóre rozproszone pakiety zbiorcze i obsługę kluczy obcych. Kolokacja fragmentów jest wnioskowana, gdy liczba fragmentów, czynniki replikacji i typy kolumn partycji są zgodne między dwiema tabelami; można jednak określić niestandardową grupę kolokacji podczas tworzenia tabeli rozproszonej, jeśli jest to konieczne.
| Nazwisko | Pisz | Opis |
|---|---|---|
| kolokacja | int | Unikatowy identyfikator grupy kolokacji odpowiada temu wierszowi. |
| shardcount | int | Liczba fragmentów dla wszystkich tabel w tej grupie kolokacji |
| replicationfactor | int | Współczynnik replikacji dla wszystkich tabel w tej grupie kolokacji. |
| typ rozkładu kolumny | Oid | Typ kolumny dystrybucji dla wszystkich tabel w tej grupie kolokacji. |
SELECT * from pg_dist_colocation;
colocationid | shardcount | replicationfactor | distributioncolumntype
--------------+------------+-------------------+------------------------
2 | 32 | 2 | 20
(1 row)
Tabela strategii ponownego równoważenia
W tej tabeli zdefiniowano strategie, które rebalance_table_shards mogą służyć do określania miejsca przenoszenia fragmentów.
| Nazwisko | Pisz | Opis |
|---|---|---|
| default_strategy | boolean | Czy rebalance_table_shards domyślnie wybrać tę strategię. Użyj citus_set_default_rebalance_strategy, aby zaktualizować tę kolumnę |
| shard_cost_function | regproc | Identyfikator funkcji kosztu, która musi przyjmować identyfikator shardid jako bigint i zwracać jego pojęcie kosztu jako rzeczywistego typu |
| node_capacity_function | regproc | Identyfikator funkcji pojemności, która musi przyjmować identyfikator nodeid jako int i zwracać jego pojęcie pojemności węzła jako rzeczywistego typu |
| shard_allowed_on_node_function | regproc | Identyfikator funkcji, która ma określony element bigint shardid i nodeidarg int, zwraca wartość logiczną dla tego, czy usługa Azure Cosmos DB for PostgreSQL może przechowywać fragment w węźle |
| default_threshold | float4 | Próg dla uznania węzła za zbyt pełny lub zbyt pusty, który określa, kiedy rebalance_table_shards powinien spróbować przenieść fragmenty |
| minimum_threshold | float4 | Zabezpieczenie uniemożliwiające ustawienie zbyt małej wartości argumentu progowego rebalance_table_shards() |
Domyślnie usługa Cosmos DB for PostgreSQL jest dostarczana z tymi strategiami w tabeli:
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 Strategia przypisuje każdemu fragmentowi ten sam koszt. Jej efektem jest wyrównanie liczby fragmentów między węzłami. Domyślna strategia , by_disk_sizeprzypisuje koszt każdemu fragmentowi odpowiadającemu rozmiarowi dysku w bajtach oraz fragmentom, które są z nim współlokowane. Rozmiar dysku jest obliczany przy użyciu metody pg_total_relation_size, więc zawiera indeksy. Ta strategia próbuje osiągnąć to samo miejsce na dysku w każdym węźle. Zwróć uwagę na wartość progową 0.1, która zapobiega niepotrzebnemu ruchowi fragmentów spowodowanego nieznacznymi różnicami w miejscu na dysku.
Tworzenie niestandardowych strategii ponownego równoważenia
Poniżej przedstawiono przykłady funkcji, które mogą być używane w ramach nowych strategii ponownego równoważenia fragmentów i zarejestrowanych w pg_dist_rebalance_strategy za pomocą funkcji citus_add_rebalance_strategy.
Ustawianie wyjątku pojemności węzła według wzorca nazwy hosta:
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;Ponowne równoważenie według liczby zapytań przechodzących do fragmentu mierzonego przez 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;Izolowanie określonego fragmentu (10000) w węźle (adres '10.0.0.1'):
-- example of shard_allowed_on_node_function CREATE FUNCTION isolate_shard_10000_on_10_0_0_1(shardid bigint, nodeidarg int) RETURNS boolean AS $$ SELECT (CASE WHEN nodename = '10.0.0.1' THEN shardid = 10000 ELSE shardid != 10000 END) FROM pg_dist_node where nodeid = nodeidarg $$ LANGUAGE sql; -- The next two definitions are recommended in combination with the above function. -- This way the average utilization of nodes is not impacted by the isolated shard. CREATE FUNCTION no_capacity_for_10_0_0_1(nodeidarg int) RETURNS real AS $$ SELECT (CASE WHEN nodename = '10.0.0.1' THEN 0 ELSE 1 END)::real FROM pg_dist_node where nodeid = nodeidarg $$ LANGUAGE sql; CREATE FUNCTION no_cost_for_10000(shardid bigint) RETURNS real AS $$ SELECT (CASE WHEN shardid = 10000 THEN 0 ELSE 1 END)::real $$ LANGUAGE sql;
Tabela statystyk zapytań
Usługa Azure Cosmos DB for PostgreSQL udostępnia citus_stat_statements statystyki dotyczące sposobu wykonywania zapytań i dla kogo. Jest ona analogiczna do widoku pg_stat_statements w usłudze PostgreSQL, który śledzi statystyki dotyczące szybkości zapytań.
Ten widok umożliwia śledzenie zapytań do dzierżaw pochodzących z aplikacji wielodostępnej, co ułatwia podjęcie decyzji o tym, kiedy należy przeprowadzić izolację dzierżawy.
| Nazwisko | Pisz | Opis |
|---|---|---|
| queryid | bigint | identyfikator (dobry dla sprzężeń pg_stat_statements) |
| userid | Oid | użytkownik, który uruchomił zapytanie |
| dbid | Oid | wystąpienie bazy danych koordynatora |
| zapytanie | text | anonimizowany ciąg zapytania |
| wykonawca | text | Użyto funkcji wykonawczej Citus: adaptacyjne, w czasie rzeczywistym, tracker zadań, router lub wybór wstawiania |
| partition_key | text | wartość kolumny dystrybucji w zapytaniach wykonywanych przez router, a w przeciwnym razie wartość NULL |
| Wywołania | bigint | liczba uruchomień zapytania |
-- 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;
Wyniki:
-[ 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
Zastrzeżenia:
- Dane statystyczne nie są replikowane i nie przetrwa awarii bazy danych ani trybu failover
- Śledzi ograniczoną liczbę zapytań ustawionych przez
pg_stat_statements.maxGUC (domyślnie 5000) - Aby obcinać tabelę, użyj
citus_stat_statements_reset()funkcji
Działanie zapytania rozproszonego
Usługa Azure Cosmos DB for PostgreSQL udostępnia specjalne widoki do oglądania zapytań i blokad w całym klastrze, w tym zapytań specyficznych dla fragmentów używanych wewnętrznie do tworzenia wyników zapytań rozproszonych.
- citus_dist_stat_activity: pokazuje rozproszone zapytania wykonywane na wszystkich węzłach. Nadzbiór ,
pg_stat_activitymożna używać wszędzie tam, gdzie jest ten ostatni. - citus_worker_stat_activity: pokazuje zapytania dotyczące procesów roboczych, w tym zapytania fragmentów względem poszczególnych fragmentów.
- citus_lock_waits: Zablokowane zapytania w całym klastrze.
Dwa pierwsze widoki obejmują wszystkie kolumny pg_stat_activity oraz host/port hosta procesu roboczego, który zainicjował zapytanie i host/port węzła koordynacji klastra.
Rozważ na przykład zliczanie wierszy w tabeli rozproszonej:
-- run from worker on localhost:9701
SELECT count(*) FROM users_table;
Widzimy, że zapytanie jest wyświetlane w pliku 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
To zapytanie wymaga informacji ze wszystkich fragmentów. Niektóre informacje znajdują się w fragmentach users_table_102038, które mają być przechowywane w pliku localhost:9700. Widzimy zapytanie, które uzyskuje dostęp do fragmentu, patrząc na citus_worker_stat_activity widok:
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
Pole query zawiera dane kopiowane z fragmentu do zliczenia.
Uwaga
Jeśli zapytanie routera (np. jednodostępne w aplikacji wielodostępnej, "SELECT"
- Z tabeli WHERE tenant_id = X') jest wykonywany bez bloku transakcji, a następnie master_query_host_name i kolumny master_query_host_port będą mieć wartość NULL w citus_worker_stat_activity.
Oto przykłady przydatnych zapytań, które można utworzyć przy użyciu polecenia 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;
Następny widok to citus_lock_waits. Aby zobaczyć, jak to działa, możemy ręcznie wygenerować sytuację blokującą. Najpierw skonfigurujemy tabelę testową z koordynatora:
CREATE TABLE numbers AS
SELECT i, 0 AS j FROM generate_series(1,10) AS i;
SELECT create_distributed_table('numbers', 'i');
Następnie, korzystając z dwóch sesji koordynatora, możemy uruchomić tę sekwencję instrukcji:
-- session 1 -- session 2
------------------------------------- -------------------------------------
BEGIN;
UPDATE numbers SET j = 2 WHERE i = 1;
BEGIN;
UPDATE numbers SET j = 3 WHERE i = 1;
-- (this blocks)
Widok citus_lock_waits pokazuje sytuację.
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
W tym przykładzie zapytania pochodzą z koordynatora, ale widok może również wyświetlać listę blokad między zapytaniami pochodzącymi z procesów roboczych (wykonywanych za pomocą usługi Azure Cosmos DB for PostgreSQL MX na przykład).