Funkcje 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)
Ta sekcja zawiera informacje referencyjne dotyczące funkcji zdefiniowanych przez użytkownika udostępnianych przez usługę Azure Cosmos DB for PostgreSQL. Te funkcje pomagają w dostarczaniu funkcji rozproszonych do usługi Azure Cosmos DB for PostgreSQL.
Uwaga
klastry z starszymi wersjami aparatu Citus mogą nie oferować wszystkich funkcji wymienionych na tej stronie.
Tabela i Shard DDL
citus_schema_distribute
Konwertuje istniejące schematy regularne na schematy rozproszone. Schematy rozproszone są automatycznie skojarzone z poszczególnymi grupami kolokacji. Tabele utworzone w tych schematach są konwertowane na kolokowane tabele rozproszone bez klucza fragmentu. Proces dystrybucji schematu jest automatycznie przypisywany i przenosi go do istniejącego węzła w klastrze.
Argumenty
schemaname: nazwa schematu, który musi być dystrybuowany.
Wartość zwracana
Nie dotyczy
Przykład
SELECT citus_schema_distribute('tenant_a');
SELECT citus_schema_distribute('tenant_b');
SELECT citus_schema_distribute('tenant_c');
Aby uzyskać więcej przykładów, zobacz jak zaprojektować mikrousługi.
citus_schema_undistribute
Konwertuje istniejący schemat rozproszony z powrotem na zwykły schemat. Proces powoduje przeniesienie tabel i danych z bieżącego węzła z powrotem do węzła koordynacji w klastrze.
Argumenty
schemaname: nazwa schematu, który musi być dystrybuowany.
Wartość zwracana
Nie dotyczy
Przykład
SELECT citus_schema_undistribute('tenant_a');
SELECT citus_schema_undistribute('tenant_b');
SELECT citus_schema_undistribute('tenant_c');
Aby uzyskać więcej przykładów, zobacz jak zaprojektować mikrousługi.
create_distributed_table
Funkcja create_distributed_table() służy do definiowania tabeli rozproszonej i tworzenia fragmentów, jeśli jest to tabela rozproszona przy użyciu skrótu. Ta funkcja przyjmuje nazwę tabeli, kolumnę dystrybucji i opcjonalną metodę dystrybucji oraz wstawia odpowiednie metadane, aby oznaczyć tabelę jako rozproszoną. Funkcja jest domyślnie ustawiona na dystrybucję skrótu, jeśli nie określono żadnej metody dystrybucji. Jeśli tabela jest dystrybuowana przy użyciu skrótu, funkcja tworzy również fragmenty procesów roboczych na podstawie liczby fragmentów i wartości konfiguracji współczynnika replikacji fragmentów. Jeśli tabela zawiera jakiekolwiek wiersze, są one automatycznie dystrybuowane do węzłów roboczych.
Ta funkcja zastępuje użycie master_create_distributed_table(), a następnie master_create_worker_shards().
Argumenty
table_name: nazwa tabeli, która musi być dystrybuowana.
distribution_column: kolumna, w której ma być dystrybuowana tabela.
distribution_type: (Opcjonalnie) Metoda, zgodnie z którą tabela ma być dystrybuowana. Dopuszczalne wartości to dołączanie lub skrót z wartością domyślną "skrót".
colocate_with: (Opcjonalnie) dołącz bieżącą tabelę do grupy kolokacji innej tabeli. Domyślnie tabele są kolokowane, gdy są dystrybuowane według kolumn tego samego typu, mają tę samą liczbę fragmentów i mają ten sam współczynnik replikacji. Możliwe wartości colocate_with
to default
, none
aby uruchomić nową grupę kolokacji lub nazwę innej tabeli do przeniesienia z tą tabelą. (Zobacz kolokację tabeli).
Należy pamiętać, że wartość domyślna colocate_with
funkcji wykonuje niejawną kolokację. Kolokacja może być świetną rzeczą, gdy tabele są powiązane lub zostaną połączone. Jednak jeśli dwie tabele są niepowiązane, ale mają miejsce użycie tego samego typu danych dla kolumn dystrybucji, przypadkowe przeniesienie ich może zmniejszyć wydajność podczas ponownego równoważenia fragmentu. Fragmenty tabeli zostaną niepotrzebnie przeniesione w kaskadę.
Jeśli nowa tabela rozproszona nie jest powiązana z innymi tabelami, najlepiej określić wartość colocate_with => 'none'
.
shard_count: (Opcjonalnie) liczba fragmentów do utworzenia dla nowej tabeli rozproszonej. Podczas określania shard_count
nie można określić wartości innej colocate_with
niż żadna. Aby zmienić liczbę fragmentów istniejącej tabeli lub grupy kolokacji, użyj funkcji alter_distributed_table .
Możliwe wartości to shard_count
od 1 do 64000. Aby uzyskać wskazówki dotyczące wybierania optymalnej wartości, zobacz Liczba fragmentów.
Wartość zwracana
Nie dotyczy
Przykład
Ten przykład informuje bazę danych, że tabela github_events powinna być dystrybuowana przez skrót w kolumnie repo_id.
SELECT create_distributed_table('github_events', 'repo_id');
-- alternatively, to be more explicit:
SELECT create_distributed_table('github_events', 'repo_id',
colocate_with => 'github_repo');
create_distributed_table_concurrently
Ta funkcja ma ten sam interfejs i przeznaczenie co create_distributed_function, ale nie blokuje zapisów podczas dystrybucji tabel.
Jednak create_distributed_table_concurrently
ma kilka ograniczeń:
- Nie można użyć funkcji w bloku transakcji, co oznacza, że można dystrybuować tylko jedną tabelę naraz. (Można jednak użyć funkcji w tabelach podzielonych na partycje czasowe).
- Nie można użyć
create_distributed_table_concurrently
, gdy tabela jest przywołynięta przez klucz obcy lub odwołuje się do innej tabeli lokalnej. Jednak klucze obce do tabel odwołań działają i można utworzyć klucze obce w innych tabelach rozproszonych po zakończeniu dystrybucji tabel. - Jeśli nie masz klucza podstawowego ani tożsamości repliki w tabeli, aktualizacja i usunięcie poleceń zakończy się niepowodzeniem podczas dystrybucji tabel z powodu ograniczeń związanych z replikacją logiczną.
truncate_local_data_after_distributing_table
Obcinaj wszystkie wiersze lokalne po dystrybucji tabeli i zapobiegaj awarii ograniczeń z powodu nieaktualnych rekordów lokalnych. Kaskadowe obcinanie tabel o obcym kluczu do wyznaczonej tabeli. Jeśli tabele odwołujące się nie są rozproszone, obcinanie jest zabronione do czasu ich uzyskania, aby chronić integralność referencyjną:
ERROR: cannot truncate a table referenced in a foreign key constraint by a local table
Obcinanie lokalnych danych tabeli węzłów koordynacji jest bezpieczne dla tabel rozproszonych, ponieważ ich wiersze, jeśli istnieją, są kopiowane do węzłów roboczych podczas dystrybucji.
Argumenty
table_name: nazwa tabeli rozproszonej, której lokalny odpowiednik w węźle koordynacji powinien zostać obcięty.
Wartość zwracana
Nie dotyczy
Przykład
-- requires that argument is a distributed table
SELECT truncate_local_data_after_distributing_table('public.github_events');
create_reference_table
Funkcja create_reference_table() służy do definiowania małej tabeli odwołań lub wymiarów. Ta funkcja przyjmuje nazwę tabeli i tworzy tabelę rozproszoną z tylko jednym fragmentem replikowanym do każdego węzła roboczego.
Argumenty
table_name: nazwa małej tabeli wymiarowej lub referencyjnej, która musi być dystrybuowana.
Wartość zwracana
Nie dotyczy
Przykład
Ten przykład informuje bazę danych, że tabela nation powinna być zdefiniowana jako tabela referencyjna
SELECT create_reference_table('nation');
citus_add_local_table_to_metadata
Dodaje lokalną tabelę Postgres do metadanych Citus. Głównym przypadkiem użycia tej funkcji jest udostępnienie tabel lokalnych w koordynatorze z dowolnego węzła w klastrze. Dane skojarzone z tabelą lokalną pozostają na koordynatorze — do procesów roboczych są wysyłane tylko jego schemat i metadane.
Dodanie tabel lokalnych do metadanych wiąże się z niewielkimi kosztami. Po dodaniu tabeli Citus musi ją śledzić w tabeli partycji. Tabele lokalne dodawane do metadanych dziedziczą te same ograniczenia co tabele odwołań.
Po cofnięciu dystrybucji tabeli Citus usuwa wynikowe tabele lokalne z metadanych, co eliminuje takie ograniczenia w tych tabelach.
Argumenty
table_name: nazwa tabeli koordynatora, która ma zostać dodana do metadanych Citus.
cascade_via_foreign_keys: (Opcjonalnie) Jeśli ten argument ma wartość "true", citus_add_local_table_to_metadata dodaje inne tabele, które znajdują się w relacji klucza obcego z daną tabelą do metadanych automatycznie. Należy zachować ostrożność w przypadku tego parametru, ponieważ może to potencjalnie mieć wpływ na wiele tabel.
Wartość zwracana
Nie dotyczy
Przykład
Ten przykład informuje bazę danych, że tabela narodu powinna być zdefiniowana jako tabela lokalna koordynatora, dostępna z dowolnego węzła:
SELECT citus_add_local_table_to_metadata('nation');
alter_distributed_table
Funkcja alter_distributed_table() może służyć do zmiany kolumny dystrybucji, liczby fragmentów lub właściwości kolokacji tabeli rozproszonej.
Argumenty
table_name: nazwa tabeli, która zostanie zmieniona.
distribution_column: (Opcjonalnie) Nazwa nowej kolumny dystrybucji.
shard_count: (Opcjonalnie) Nowa liczba fragmentów.
colocate_with: (Opcjonalnie) Tabela, z którą zostanie przeniesiona bieżąca tabela rozproszona. Możliwe wartości to default
, none
aby uruchomić nową grupę kolokacji lub nazwę innej tabeli, z którą ma być kolokacja. (Zobacz kolokację tabeli).
cascade_to_colocated: (Opcjonalnie) Jeśli ten argument jest ustawiony na wartość "true", shard_count
a colocate_with
zmiany zostaną również zastosowane do wszystkich tabel, które zostały wcześniej przeniesione do tabeli, a kolokacja zostanie zachowana. Jeśli jest to wartość "false", bieżąca kolokacja tej tabeli zostanie przerwana.
Wartość zwracana
Nie dotyczy
Przykład
-- change distribution column
SELECT alter_distributed_table('github_events', distribution_column:='event_id');
-- change shard count of all tables in colocation group
SELECT alter_distributed_table('github_events', shard_count:=6, cascade_to_colocated:=true);
-- change colocation
SELECT alter_distributed_table('github_events', colocate_with:='another_table');
update_distributed_table_colocation
Funkcja update_distributed_table_colocation() służy do aktualizowania kolokacji tabeli rozproszonej. Ta funkcja może również służyć do przerywania kolokacji tabeli rozproszonej. Usługa Azure Cosmos DB for PostgreSQL niejawnie kolokuje dwie tabele, jeśli kolumna dystrybucji jest tego samego typu, może to być przydatne, jeśli tabele są powiązane i będą wykonywać pewne sprzężenia. Jeśli tabele A i B są kolokowane, a tabela A zostanie ponownie zrównoważona, tabela B również zostanie ponownie zrównoważona. Jeśli tabela B nie ma tożsamości repliki, ponowne równoważenie zakończy się niepowodzeniem. W związku z tym ta funkcja może być przydatna, powodując niezgodność niejawnej kolokacji w tym przypadku.
Ta funkcja nie przenosi żadnych danych w sposób fizyczny.
Argumenty
table_name: nazwa kolokacji tabeli, która zostanie zaktualizowana.
colocate_with: tabela, z którą powinna zostać przeniesiona tabela.
Jeśli chcesz przerwać kolokację tabeli, należy określić wartość colocate_with => 'none'
.
Wartość zwracana
Nie dotyczy
Przykład
W tym przykładzie pokazano, że kolokacja tabeli A jest aktualizowana jako kolokacja tabeli B.
SELECT update_distributed_table_colocation('A', colocate_with => 'B');
Załóżmy, że tabela A i tabela B są kolokowane (prawdopodobnie niejawnie), jeśli chcesz przerwać kolokację:
SELECT update_distributed_table_colocation('A', colocate_with => 'none');
Teraz załóżmy, że tabela A, tabela B, tabela C i tabela D są kolokowane i chcesz kolokować tabelę A i tabelę B razem, a tabelę C i tabelę D razem:
SELECT update_distributed_table_colocation('C', colocate_with => 'none');
SELECT update_distributed_table_colocation('D', colocate_with => 'C');
Jeśli masz tabelę rozproszoną skrótu o nazwie none i chcesz zaktualizować jej kolokację, możesz wykonać następujące czynności:
SELECT update_distributed_table_colocation('"none"', colocate_with => 'some_other_hash_distributed_table');
undistribute_table
Funkcja undistribute_table() cofa akcję create_distributed_table lub create_reference_table. Cofanie dystrybucji przenosi wszystkie dane z fragmentów z powrotem do tabeli lokalnej w węźle koordynacji (przy założeniu, że dane mogą pasować), a następnie usuwa fragmenty.
Usługa Azure Cosmos DB for PostgreSQL nie będzie odwoływała tabel, do których odwołują się klucze obce, chyba że argument cascade_via_foreign_keys ma wartość true. Jeśli ten argument jest fałszywy (lub pominięty), przed cofnięciem należy ręcznie usunąć naruszenia ograniczeń klucza obcego.
Argumenty
table_name: nazwa tabeli rozproszonej lub referencyjnej, która ma być niezakłócona.
cascade_via_foreign_keys: (Opcjonalnie) Jeśli ten argument ma wartość "true", undistribute_table również nie rozdziela wszystkich tabel powiązanych z table_name za pomocą kluczy obcych. Należy zachować ostrożność w przypadku tego parametru, ponieważ może to potencjalnie mieć wpływ na wiele tabel.
Wartość zwracana
Nie dotyczy
Przykład
Ten przykład dystrybuuje tabelę github_events
, a następnie ją nie rozdziela.
-- first distribute the table
SELECT create_distributed_table('github_events', 'repo_id');
-- undo that and make it local again
SELECT undistribute_table('github_events');
create_distributed_function
Propaguje funkcję z węzła koordynatora do procesów roboczych i oznacza ją do wykonywania rozproszonego. Gdy funkcja rozproszona jest wywoływana na koordynatorze, usługa Azure Cosmos DB for PostgreSQL używa wartości "argumentu dystrybucji", aby wybrać węzeł procesu roboczego do uruchomienia funkcji. Wykonywanie funkcji dla procesów roboczych zwiększa równoległość i może przybliżyć kod do danych w fragmentach w celu uzyskania mniejszego opóźnienia.
Ścieżka wyszukiwania Postgres nie jest propagowana z koordynatora do procesów roboczych podczas wykonywania funkcji rozproszonej, dlatego kod funkcji rozproszonej powinien w pełni kwalifikować nazwy obiektów bazy danych. Ponadto powiadomienia emitowane przez funkcje nie będą wyświetlane użytkownikowi.
Argumenty
function_name: nazwa funkcji, która ma być dystrybuowana. Nazwa musi zawierać typy parametrów funkcji w nawiasach, ponieważ wiele funkcji może mieć taką samą nazwę w usłudze PostgreSQL. Na przykład 'foo(int)'
różni się od 'foo(int, text)'
.
distribution_arg_name: (Opcjonalnie) Nazwa argumentu, za pomocą którego ma być dystrybuowana. Dla wygody (lub jeśli argumenty funkcji nie mają nazw), symbol zastępczy pozycyjny jest dozwolony, taki jak '$1'
. Jeśli ten parametr nie jest określony, funkcja o nazwie by function_name
jest tworzona tylko dla procesów roboczych. Jeśli węzły procesu roboczego zostaną dodane w przyszłości, funkcja zostanie również automatycznie utworzona.
colocate_with: (Opcjonalnie) Gdy funkcja rozproszona odczytuje lub zapisuje w tabeli rozproszonej (lub ogólniej, w grupie kolokacji), pamiętaj, aby nazwać tę tabelę przy użyciu parametru colocate_with
. Następnie każde wywołanie funkcji zostanie uruchomione w węźle roboczym zawierającym odpowiednie fragmenty.
Wartość zwracana
Nie dotyczy
Przykład
-- an example function which updates a hypothetical
-- event_responses table which itself is distributed by event_id
CREATE OR REPLACE FUNCTION
register_for_event(p_event_id int, p_user_id int)
RETURNS void LANGUAGE plpgsql AS $fn$
BEGIN
INSERT INTO event_responses VALUES ($1, $2, 'yes')
ON CONFLICT (event_id, user_id)
DO UPDATE SET response = EXCLUDED.response;
END;
$fn$;
-- distribute the function to workers, using the p_event_id argument
-- to determine which shard each invocation affects, and explicitly
-- colocating with event_responses which the function updates
SELECT create_distributed_function(
'register_for_event(int, int)', 'p_event_id',
colocate_with := 'event_responses'
);
alter_columnar_table_set
Funkcja alter_columnar_table_set() zmienia ustawienia w tabeli kolumnowej. Wywołanie tej funkcji w tabeli niekolumnanej powoduje wystąpienie błędu. Wszystkie argumenty z wyjątkiem nazwy tabeli są opcjonalne.
Aby wyświetlić bieżące opcje dla wszystkich tabel kolumnowych, zapoznaj się z tą tabelą:
SELECT * FROM columnar.options;
Wartości domyślne dla ustawień kolumnowych dla nowo utworzonych tabel można zastąpić następującymi interfejsami GUCs:
- columnar.compression
- columnar.compression_level
- columnar.stripe_row_count
- columnar.chunk_row_count
Argumenty
table_name: nazwa tabeli kolumnowej.
chunk_row_count: (Opcjonalnie) Maksymalna liczba wierszy na fragment dla nowo wstawionych danych. Istniejące fragmenty danych nie zostaną zmienione i mogą zawierać więcej wierszy niż ta maksymalna wartość. Wartość domyślna to 10000.
stripe_row_count: (Opcjonalnie) Maksymalna liczba wierszy na paski dla nowo wstawionych danych. Istniejące paski danych nie zostaną zmienione i mogą mieć więcej wierszy niż ta maksymalna wartość. Wartość domyślna to 150000.
kompresja: (Opcjonalnie) [none|pglz|zstd|lz4|lz4hc]
Typ kompresji dla nowo wstawionych danych. Istniejące dane nie będą rekompresowane ani dekompresowane. Wartość domyślna i sugerowana to zstd (jeśli obsługa została skompilowana w pliku).
compression_level: (Opcjonalnie) Prawidłowe ustawienia to od 1 do 19. Jeśli metoda kompresji nie obsługuje wybranego poziomu, zostanie wybrany najbliższy poziom.
Wartość zwracana
Nie dotyczy
Przykład
SELECT alter_columnar_table_set(
'my_columnar_table',
compression => 'none',
stripe_row_count => 10000);
alter_table_set_access_method
Funkcja alter_table_set_access_method() zmienia metodę dostępu tabeli (na przykład stertę lub kolumnę).
Argumenty
table_name: nazwa tabeli, której metoda dostępu ulegnie zmianie.
access_method: nazwa nowej metody dostępu.
Wartość zwracana
Nie dotyczy
Przykład
SELECT alter_table_set_access_method('github_events', 'columnar');
create_time_partitions
Funkcja create_time_partitions() tworzy partycje danego interwału w celu pokrycia danego zakresu czasu.
Argumenty
table_name: (regclass) tabela, dla której mają zostać utworzone nowe partycje. Tabela musi być podzielona na partycje w jednej kolumnie, typu data, sygnatura czasowa lub sygnatura czasowa.
partition_interval: interwał czasu, taki jak '2 hours'
, lub '1 month'
, do użycia podczas ustawiania zakresów na nowych partycjach.
end_at: (timestamptz) utwórz partycje do tej pory. Ostatnia partycja będzie zawierać punkt end_at i nie zostaną utworzone żadne późniejsze partycje.
start_from: (sygnatura czasowa, opcjonalnie) wybierz pierwszą partycję, aby zawierała start_from punktów. Domyślna wartość to now()
.
Wartość zwracana
Wartość True, jeśli jest to konieczne do utworzenia nowych partycji, wartość false, jeśli wszystkie już istniały.
Przykład
-- create a year's worth of monthly partitions
-- in table foo, starting from the current time
SELECT create_time_partitions(
table_name := 'foo',
partition_interval := '1 month',
end_at := now() + '12 months'
);
drop_old_time_partitions
Funkcja drop_old_time_partitions() usuwa wszystkie partycje, których interwały spadną przed danym znacznikiem czasu. Oprócz korzystania z tej funkcji można rozważyć alter_old_partitions_set_access_method kompresować stare partycje z magazynem kolumnowym.
Argumenty
table_name: (regclass) tabela, dla której mają być usuwane partycje. Tabela musi być podzielona na partycje w jednej kolumnie, typu data, sygnatura czasowa lub sygnatura czasowa.
older_than: (timestamptz) upuść partycje, których górny zakres jest mniejszy lub równy older_than.
Wartość zwracana
Nie dotyczy
Przykład
-- drop partitions that are over a year old
CALL drop_old_time_partitions('foo', now() - interval '12 months');
alter_old_partitions_set_access_method
W przypadku użycia czasowych tabele są często partycjonowane według czasu, a stare partycje są kompresowane do magazynu kolumnowego tylko do odczytu.
Argumenty
parent_table_name: (regclass) tabela, dla której mają być zmieniane partycje. Tabela musi być podzielona na partycje w jednej kolumnie, typu data, sygnatura czasowa lub sygnatura czasowa.
older_than: (sygnatura czasowa) zmienia partycje, których górny zakres jest mniejszy lub równy older_than.
new_access_method: (nazwa) "sterta" dla magazynu opartego na wierszach lub "columnar" dla magazynu kolumnowego.
Wartość zwracana
Nie dotyczy
Przykład
CALL alter_old_partitions_set_access_method(
'foo', now() - interval '6 months',
'columnar'
);
Metadane/informacje o konfiguracji
get_shard_id_for_distribution_column
Usługa Azure Cosmos DB for PostgreSQL przypisuje każdy wiersz tabeli rozproszonej do fragmentu na podstawie wartości kolumny dystrybucji wiersza i metody rozkładu tabeli. W większości przypadków dokładne mapowanie to szczegóły niskiego poziomu, które administrator bazy danych może zignorować. Jednak może to być przydatne do określenia fragmentu wiersza, zarówno w przypadku ręcznych zadań konserwacji bazy danych, jak i po prostu w celu zaspokojenia ciekawości. Funkcja get_shard_id_for_distribution_column
udostępnia te informacje dla tabel rozproszonych przy użyciu skrótów, rozproszonych zakresów i odwołań. Nie działa w przypadku dystrybucji dołączania.
Argumenty
table_name: tabela rozproszona.
distribution_value: wartość kolumny dystrybucji.
Wartość zwracana
Identyfikator fragmentu usługi Azure Cosmos DB for PostgreSQL kojarzy się z wartością kolumny dystrybucji dla danej tabeli.
Przykład
SELECT get_shard_id_for_distribution_column('my_table', 4);
get_shard_id_for_distribution_column
--------------------------------------
540007
(1 row)
column_to_column_name
Tłumaczy kolumnę partkey
pg_dist_partition
na tekstową nazwę kolumny. Tłumaczenie jest przydatne do określenia kolumny rozkładu tabeli rozproszonej.
Aby uzyskać bardziej szczegółową dyskusję, zobacz wybieranie kolumny dystrybucji.
Argumenty
table_name: tabela rozproszona.
column_var_text: wartość partkey
w pg_dist_partition
tabeli.
Wartość zwracana
Nazwa table_name
kolumny dystrybucji.
Przykład
-- get distribution column name for products table
SELECT column_to_column_name(logicalrelid, partkey) AS dist_col_name
FROM pg_dist_partition
WHERE logicalrelid='products'::regclass;
Wyjście:
┌───────────────┐
│ dist_col_name │
├───────────────┤
│ company_id │
└───────────────┘
citus_relation_size
Pobierz miejsce na dysku używane przez wszystkie fragmenty określonej tabeli rozproszonej. Miejsce na dysku obejmuje rozmiar "głównego rozwidlenia", ale wyklucza mapę widoczności i mapę wolnego miejsca dla fragmentów.
Argumenty
logicalrelid: nazwa tabeli rozproszonej.
Wartość zwracana
Rozmiar w bajtach jako bigint.
Przykład
SELECT pg_size_pretty(citus_relation_size('github_events'));
pg_size_pretty
--------------
23 MB
citus_table_size
Pobierz miejsce na dysku używane przez wszystkie fragmenty określonej tabeli rozproszonej, z wyłączeniem indeksów (ale w tym TOAST, wolna mapa miejsca i mapa widoczności).
Argumenty
logicalrelid: nazwa tabeli rozproszonej.
Wartość zwracana
Rozmiar w bajtach jako bigint.
Przykład
SELECT pg_size_pretty(citus_table_size('github_events'));
pg_size_pretty
--------------
37 MB
citus_total_relation_size
Pobierz łączną ilość miejsca na dysku używanego przez wszystkie fragmenty określonej tabeli rozproszonej, w tym wszystkie indeksy i dane TOAST.
Argumenty
logicalrelid: nazwa tabeli rozproszonej.
Wartość zwracana
Rozmiar w bajtach jako bigint.
Przykład
SELECT pg_size_pretty(citus_total_relation_size('github_events'));
pg_size_pretty
--------------
73 MB
citus_stat_statements_reset
Usuwa wszystkie wiersze z citus_stat_statements.
Ta funkcja działa niezależnie od pg_stat_statements_reset()
. Aby zresetować wszystkie statystyki, wywołaj obie funkcje.
Argumenty
Nie dotyczy
Wartość zwracana
Brak
citus_get_active_worker_nodes
Funkcja citus_get_active_worker_nodes() zwraca listę aktywnych nazw hostów procesu roboczego i numerów portów.
Argumenty
Nie dotyczy
Wartość zwracana
Lista krotki, w których każda krotka zawiera następujące informacje:
node_name: nazwa DNS węzła roboczego
node_port: Port w węźle roboczym, na którym nasłuchuje serwer bazy danych
Przykład
SELECT * from citus_get_active_worker_nodes();
node_name | node_port
-----------+-----------
localhost | 9700
localhost | 9702
localhost | 9701
(3 rows)
Zarządzanie klastrem i naprawianie
master_copy_shard_placement
Jeśli nie można zaktualizować umieszczania fragmentów podczas polecenia modyfikacji lub operacji DDL, zostanie ona oznaczona jako nieaktywna. Następnie można wywołać funkcję master_copy_shard_placement w celu naprawienia nieaktywnego umieszczania fragmentów przy użyciu danych z umieszczania w dobrej kondycji.
Aby naprawić fragment, funkcja najpierw usuwa umieszczanie fragmentów w złej kondycji i tworzy je ponownie przy użyciu schematu koordynatora. Po utworzeniu umieszczania fragmentów funkcja kopiuje dane z umieszczania w dobrej kondycji i aktualizuje metadane, aby oznaczyć nowe rozmieszczenie fragmentów jako w dobrej kondycji. Ta funkcja gwarantuje, że fragment będzie chroniony przed wszelkimi współbieżnych modyfikacjami podczas naprawy.
Argumenty
shard_id: identyfikator fragmentu, który ma zostać naprawiony.
source_node_name: nazwa DNS węzła, w którym znajduje się umieszczanie fragmentów w dobrej kondycji ("węzeł źródłowy").
source_node_port: port w źródłowym węźle roboczym, na którym nasłuchuje serwer bazy danych.
target_node_name: nazwa DNS węzła, w którym znajduje się nieprawidłowe rozmieszczenie fragmentów ("węzeł docelowy").
target_node_port: port w docelowym węźle roboczym, na którym nasłuchuje serwer bazy danych.
Wartość zwracana
Nie dotyczy
Przykład
W poniższym przykładzie naprawiono nieaktywne rozmieszczenie fragmentu 12345, który znajduje się na serwerze bazy danych uruchomionym na "bad_host" na porcie 5432. Aby go naprawić, będzie używać danych z umieszczania fragmentów w dobrej kondycji na serwerze uruchomionym na "good_host" na porcie 5432.
SELECT master_copy_shard_placement(12345, 'good_host', 5432, 'bad_host', 5432);
master_move_shard_placement
Ta funkcja przenosi dany fragment (i fragmenty kolokowane z nim) z jednego węzła do drugiego. Jest on zwykle używany pośrednio podczas ponownego równoważenia fragmentu, a nie wywoływany bezpośrednio przez administratora bazy danych.
Istnieją dwa sposoby przenoszenia danych: blokowanie lub blokowanie. Podejście blokujące oznacza, że podczas przenoszenia wszystkie modyfikacje fragmentu są wstrzymane. Drugi sposób, który unika blokowania zapisów fragmentów, opiera się na replikacji logicznej Postgres 10.
Po pomyślnej operacji przenoszenia fragmenty w węźle źródłowym zostaną usunięte. Jeśli przeniesienie zakończy się niepowodzeniem w dowolnym momencie, ta funkcja zgłasza błąd i pozostawia węzły źródłowe i docelowe bez zmian.
Argumenty
shard_id: identyfikator fragmentu do przeniesienia.
source_node_name: nazwa DNS węzła, w którym znajduje się umieszczanie fragmentów w dobrej kondycji ("węzeł źródłowy").
source_node_port: port w źródłowym węźle roboczym, na którym nasłuchuje serwer bazy danych.
target_node_name: nazwa DNS węzła, w którym znajduje się nieprawidłowe rozmieszczenie fragmentów ("węzeł docelowy").
target_node_port: port w docelowym węźle roboczym, na którym nasłuchuje serwer bazy danych.
shard_transfer_mode: (opcjonalnie) Określ metodę replikacji, niezależnie od tego, czy używać replikacji logicznej PostgreSQL, czy polecenia COPY między procesami roboczymi. Możliwe wartości to:
auto
: Wymagaj tożsamości repliki, jeśli jest możliwa replikacja logiczna, w przeciwnym razie użyj starszego zachowania (np. do naprawy fragmentów, PostgreSQL 9.6). Jest to wartość domyślna.force_logical
: Użyj replikacji logicznej, nawet jeśli tabela nie ma tożsamości repliki. Wszystkie współbieżne instrukcje aktualizacji/usuwania do tabeli nie powiedzą się podczas replikacji.block_writes
: Użyj funkcji COPY (blokujących zapisy) dla tabel, w których brakuje klucza podstawowego lub tożsamości repliki.
Wartość zwracana
Nie dotyczy
Przykład
SELECT master_move_shard_placement(12345, 'from_host', 5432, 'to_host', 5432);
rebalance_table_shards
Funkcja rebalance_table_shards() przenosi fragmenty danej tabeli, aby równomiernie rozłożyć je między procesami roboczymi. Funkcja najpierw oblicza listę ruchów, które musi wykonać, aby upewnić się, że klaster jest zrównoważony w ramach danego progu. Następnie przenosi umieszczanie fragmentów jeden po jednym z węzła źródłowego do węzła docelowego i aktualizuje odpowiednie metadane fragmentu w celu odzwierciedlenia przeniesienia.
Każdy fragment jest przypisywany koszt podczas określania, czy fragmenty są "równomiernie rozproszone". Domyślnie każdy fragment ma ten sam koszt (wartość 1), więc dystrybucja w celu wyrównania kosztów między procesami roboczymi jest taka sama jak równanie liczby fragmentów na każdym z nich. Strategia stałego kosztu jest nazywana "by_shard_count" i jest domyślną strategią ponownego równoważenia.
Strategia "by_shard_count" jest odpowiednia w następujących okolicznościach:
- Fragmenty mają mniej więcej taki sam rozmiar
- Fragmenty uzyskują mniej więcej taką samą ilość ruchu
- Węzły procesu roboczego mają ten sam rozmiar/typ
- Fragmenty nie zostały przypięte do określonych procesów roboczych
Jeśli którekolwiek z tych założeń nie zostanie wstrzymane, ponowne równoważenie "by_shard_count" może spowodować zły plan.
Domyślna strategia ponownego równoważenia to "by_disk_size". Zawsze możesz dostosować strategię przy użyciu parametru rebalance_strategy
.
Zaleca się wywołanie get_rebalance_table_shards_plan przed uruchomieniem rebalance_table_shards, aby zobaczyć i zweryfikować akcje do wykonania.
Argumenty
table_name: (Opcjonalnie) Nazwa tabeli, której fragmenty muszą zostać ponownie zrównoważone. Jeśli wartość NULL, należy ponownie zrównoważyć wszystkie istniejące grupy kolokacji.
próg: (Opcjonalnie) Liczba zmiennoprzecinkowa z zakresu od 0,0 do 1,0, która wskazuje maksymalny współczynnik wykorzystania węzła ze średniego wykorzystania. Na przykład określenie wartości 0,1 spowoduje ponowne równoważenie fragmentów, aby spróbować zrównoważyć wszystkie węzły do przechowywania tej samej liczby fragmentów ±10%. W szczególności moduł ponownego równoważenia fragmentu spróbuje zrównoważyć wykorzystanie wszystkich węzłów procesu roboczego do wartości (1 - próg) * average_utilization ... (1
- próg) * zakres average_utilization.
max_shard_moves: (Opcjonalnie) Maksymalna liczba fragmentów do przeniesienia.
excluded_shard_list: (opcjonalnie) Identyfikatory fragmentów, które nie powinny być przenoszone podczas operacji ponownego równoważenia.
shard_transfer_mode: (opcjonalnie) Określ metodę replikacji, niezależnie od tego, czy używać replikacji logicznej PostgreSQL, czy polecenia COPY między procesami roboczymi. Możliwe wartości to:
auto
: Wymagaj tożsamości repliki, jeśli jest możliwa replikacja logiczna, w przeciwnym razie użyj starszego zachowania (np. do naprawy fragmentów, PostgreSQL 9.6). Jest to wartość domyślna.force_logical
: Użyj replikacji logicznej, nawet jeśli tabela nie ma tożsamości repliki. Wszystkie współbieżne instrukcje aktualizacji/usuwania do tabeli nie powiedzą się podczas replikacji.block_writes
: Użyj funkcji COPY (blokujących zapisy) dla tabel, w których brakuje klucza podstawowego lub tożsamości repliki.
drain_only: (Opcjonalnie) Jeśli wartość true, przenieś fragmenty z węzłów roboczych, które zostały shouldhaveshards
ustawione na wartość false w pg_dist_node; nie przenieś żadnych innych fragmentów.
rebalance_strategy: (Opcjonalnie) nazwa strategii w pg_dist_rebalance_strategy. Jeśli ten argument zostanie pominięty, funkcja wybierze strategię domyślną, jak wskazano w tabeli.
Wartość zwracana
Nie dotyczy
Przykład
Poniższy przykład spróbuje ponownie zrównoważyć fragmenty tabeli github_events w ramach domyślnego progu.
SELECT rebalance_table_shards('github_events');
To przykładowe użycie spróbuje ponownie zrównoważyć tabelę github_events bez przenoszenia fragmentów o identyfikatorze 1 i 2.
SELECT rebalance_table_shards('github_events', excluded_shard_list:='{1,2}');
get_rebalance_table_shards_plan
Wyprowadź planowane ruchy fragmentów rebalance_table_shards bez ich wykonywania. Chociaż jest mało prawdopodobne, get_rebalance_table_shards_plan może uzyskać nieco inny plan niż wywołanie rebalance_table_shards z tymi samymi argumentami. Nie są one wykonywane w tym samym czasie, więc fakty dotyczące klastra — na przykład miejsce na dysku — mogą się różnić między wywołaniami.
Argumenty
Te same argumenty co rebalance_table_shards: relacja, próg, max_shard_moves, excluded_shard_list i drain_only. Zapoznaj się z dokumentacją tej funkcji, aby zapoznać się z znaczeniem argumentów.
Wartość zwracana
Krotki zawierające następujące kolumny:
- table_name: Tabela, której fragmenty zostaną przeniesione
- shardid: Fragment, o którym mowa
- shard_size: rozmiar w bajtach
- sourcename: Nazwa hosta węzła źródłowego
- sourceport: port węzła źródłowego
- targetname: nazwa hosta węzła docelowego
- targetport: port węzła docelowego
get_rebalance_progress
Po rozpoczęciu get_rebalance_progress()
ponownego równoważenia fragmentu funkcja wyświetla postęp każdego zaangażowanego fragmentu. Monitoruje planowane i wykonywane rebalance_table_shards()
przez program ruchy .
Argumenty
Nie dotyczy
Wartość zwracana
Krotki zawierające następujące kolumny:
- sessionid: Postgres PID monitora ponownego równoważenia
- table_name: Tabela, której fragmenty są przenoszone
- shardid: Fragment, o którym mowa
- shard_size: rozmiar w bajtach
- sourcename: Nazwa hosta węzła źródłowego
- sourceport: port węzła źródłowego
- targetname: nazwa hosta węzła docelowego
- targetport: port węzła docelowego
- postęp: 0 = oczekiwanie na przeniesienie; 1 = przenoszenie; 2 = ukończone
Przykład
SELECT * FROM get_rebalance_progress();
┌───────────┬────────────┬─────────┬────────────┬───────────────┬────────────┬───────────────┬────────────┬──────────┐
│ sessionid │ table_name │ shardid │ shard_size │ sourcename │ sourceport │ targetname │ targetport │ progress │
├───────────┼────────────┼─────────┼────────────┼───────────────┼────────────┼───────────────┼────────────┼──────────┤
│ 7083 │ foo │ 102008 │ 1204224 │ n1.foobar.com │ 5432 │ n4.foobar.com │ 5432 │ 0 │
│ 7083 │ foo │ 102009 │ 1802240 │ n1.foobar.com │ 5432 │ n4.foobar.com │ 5432 │ 0 │
│ 7083 │ foo │ 102018 │ 614400 │ n2.foobar.com │ 5432 │ n4.foobar.com │ 5432 │ 1 │
│ 7083 │ foo │ 102019 │ 8192 │ n3.foobar.com │ 5432 │ n4.foobar.com │ 5432 │ 2 │
└───────────┴────────────┴─────────┴────────────┴───────────────┴────────────┴───────────────┴────────────┴──────────┘
citus_add_rebalance_strategy
Dołącz wiersz do pg_dist_rebalance_strategy .
Argumenty
Aby uzyskać więcej informacji na temat tych argumentów, zobacz odpowiednie wartości kolumn w pliku pg_dist_rebalance_strategy
.
name: identyfikator nowej strategii
shard_cost_function: identyfikuje funkcję używaną do określania "kosztu" każdego fragmentu
node_capacity_function: identyfikuje funkcję do mierzenia pojemności węzła
shard_allowed_on_node_function: identyfikuje funkcję, która określa, które fragmenty można umieścić w których węzłach
default_threshold: próg zmiennoprzecinkowa, który dostraja, jak dokładnie skumulowany koszt fragmentu powinien być zrównoważony między węzłami
minimum_threshold: (Opcjonalnie) kolumna ochrony zawierająca minimalną wartość dozwoloną dla argumentu progu rebalance_table_shards(). Jego wartość domyślna to 0
Wartość zwracana
Nie dotyczy
citus_set_default_rebalance_strategy
Zaktualizuj tabelę pg_dist_rebalance_strategy , zmieniając strategię o nazwie według jej argumentu na wartość domyślną wybraną podczas ponownego równoważenia fragmentów.
Argumenty
name: nazwa strategii w pg_dist_rebalance_strategy
Wartość zwracana
Nie dotyczy
Przykład
SELECT citus_set_default_rebalance_strategy('by_disk_size');
citus_remote_connection_stats
Funkcja citus_remote_connection_stats() pokazuje liczbę aktywnych połączeń z każdym węzłem zdalnym.
Argumenty
Nie dotyczy
Przykład
SELECT * from citus_remote_connection_stats();
hostname | port | database_name | connection_count_to_node
----------------+------+---------------+--------------------------
citus_worker_1 | 5432 | postgres | 3
(1 row)
isolate_tenant_to_new_shard
Ta funkcja tworzy nowy fragment do przechowywania wierszy z określoną pojedynczą wartością w kolumnie dystrybucji. Jest to szczególnie przydatne w przypadku wielodostępnego użycia, w którym duża dzierżawa może zostać umieszczona samodzielnie na własnym fragmentie i ostatecznie własnym węźle fizycznym.
Argumenty
table_name: nazwa tabeli w celu pobrania nowego fragmentu.
tenant_id: wartość kolumny dystrybucji, która zostanie przypisana do nowego fragmentu.
cascade_option: (Opcjonalnie) Po ustawieniu wartości "CASCADE" również izoluje fragment ze wszystkich tabel w grupie kolokacji bieżącej tabeli.
Wartość zwracana
shard_id: funkcja zwraca unikatowy identyfikator przypisany do nowo utworzonego fragmentu.
Przykłady
Utwórz nowy fragment do przechowywania elementów lineitem dla dzierżawy 135:
SELECT isolate_tenant_to_new_shard('lineitem', 135);
┌─────────────────────────────┐
│ isolate_tenant_to_new_shard │
├─────────────────────────────┤
│ 102240 │
└─────────────────────────────┘
Następne kroki
- Wiele funkcji w tym artykule modyfikuje tabele metadanych systemu
- Parametry serwera dostosują zachowanie niektórych funkcji