Węzły i tabele w usłudze Azure Cosmos DB for PostgreSQL

Artykuł
10/27/2023

DOTYCZY: Usługa Azure Cosmos DB for PostgreSQL (obsługiwana przez rozszerzenie bazy danych Citus do bazy danych PostgreSQL)

Węzły

Usługa Azure Cosmos DB for PostgreSQL umożliwia serwerom PostgreSQL (nazywanym węzłom) koordynowanie się ze sobą w architekturze "udostępnionego nic". Węzły w klastrze łącznie przechowują więcej danych i używają większej liczby rdzeni procesora CPU niż byłoby to możliwe na jednym serwerze. Architektura umożliwia również skalowanie bazy danych przez dodanie kolejnych węzłów do klastra.

Koordynator i pracownicy

Każdy klaster ma węzeł koordynacji i wiele procesów roboczych. Aplikacje wysyłają swoje zapytania do węzła koordynatora, który przekazuje je do odpowiednich pracowników i gromadzi wyniki.

Usługa Azure Cosmos DB for PostgreSQL umożliwia administratorowi bazy danych dystrybuowanie tabel i/lub schematów, przechowywanie różnych wierszy w różnych węzłach procesu roboczego. Tabele rozproszone i/lub schematy są kluczem do wydajności usługi Azure Cosmos DB for PostgreSQL. Nie można dystrybuować tabel i/lub schematów całkowicie w węźle koordynacji i nie może korzystać z równoległości między maszynami.

Dla każdego zapytania w tabelach rozproszonych koordynator kieruje go do jednego węzła roboczego lub równoległie na kilka w zależności od tego, czy wymagane dane są przechowywane w jednym węźle, czy wielu. W przypadku fragmentowania opartego na schemacie koordynator kieruje zapytania bezpośrednio do węzła, który hostuje schemat. W przypadku fragmentowania opartego na schemacie i fragmentowania na podstawie wierszy koordynator decyduje, co zrobić, konsultując tabele metadanych. Te tabele śledzą nazwy DNS i kondycję węzłów roboczych oraz rozkład danych między węzłami.

Typy tabel

Istnieje pięć typów tabel w klastrze, z których każdy jest przechowywany inaczej w węzłach i używany do różnych celów.

Typ 1. Tabele rozproszone

Pierwszy typ i najbardziej typowy to tabele rozproszone. Wydają się być normalnymi tabelami instrukcji SQL, ale są one partycjonowane w poziomie między węzłami roboczymi. Oznacza to, że wiersze tabeli są przechowywane w różnych węzłach w tabelach fragmentów nazywanych fragmentami.

Usługa Azure Cosmos DB for PostgreSQL uruchamia nie tylko instrukcje SQL, ale DDL w całym klastrze. Zmiana schematu kaskadowej tabeli rozproszonej w celu zaktualizowania wszystkich fragmentów tabeli między procesami roboczymi.

Kolumna dystrybucji

Usługa Azure Cosmos DB for PostgreSQL używa fragmentowania algorytmicznego w celu przypisania wierszy do fragmentów. Przypisanie jest określane w sposób deterministyczny na podstawie wartości kolumny tabeli nazywanej kolumną dystrybucji. Administrator klastra musi wyznaczyć tę kolumnę podczas dystrybucji tabeli. Wybór właściwy jest ważny dla wydajności i funkcjonalności.

Typ 2. Tabele odwołań

Tabela referencyjna jest typem rozproszonej tabeli, której cała zawartość jest skoncentrowana na jednym fragmentie. Fragment jest replikowany dla każdego procesu roboczego. Zapytania dotyczące dowolnego procesu roboczego mogą uzyskiwać dostęp do informacji referencyjnych lokalnie bez konieczności żądania wierszy z innego węzła przez sieć. Tabele odwołań nie mają kolumny dystrybucji, ponieważ nie ma potrzeby rozróżniania oddzielnych fragmentów na wiersz.

Tabele odwołań są zwykle małe i są używane do przechowywania danych istotnych dla zapytań uruchomionych w dowolnym węźle roboczym. Przykładem są wyliczone wartości, takie jak stany zamówienia lub kategorie produktów.

Typ 3. Tabele lokalne

W przypadku korzystania z usługi Azure Cosmos DB for PostgreSQL węzeł koordynatora, z którym nawiązujesz połączenie, jest zwykłą bazą danych PostgreSQL. Można tworzyć zwykłe tabele na koordynatorze i nie fragmentować ich.

Dobrym kandydatem do tabel lokalnych byłoby małe tabele administracyjne, które nie uczestniczą w zapytaniach sprzężenia. Przykładem jest users tabela logowania i uwierzytelniania aplikacji.

Typ 4. Lokalne tabele zarządzane

Usługa Azure Cosmos DB for PostgreSQL może automatycznie dodawać tabele lokalne do metadanych, jeśli istnieje odwołanie klucza obcego między tabelą lokalną a tabelą referencyjną. Ponadto tabele zarządzane lokalnie można tworzyć ręcznie, wykonując funkcję create_reference_table citus_add_local_table_to_metadata w zwykłych tabelach lokalnych. Tabele obecne w metadanych są uważane za zarządzane tabele i mogą być odpytywane z dowolnego węzła, Citus wie, aby kierować do koordynatora w celu uzyskania danych z lokalnej tabeli zarządzanej. Takie tabele są wyświetlane jako lokalne w widoku citus_tables .

Typ 5. Tabele schematu

W przypadku fragmentowania opartego na schemacie wprowadzonego w programie Citus 12.0 schematy rozproszone są automatycznie skojarzone z poszczególnymi grupami kolokacji. Tabele utworzone w tych schematach są automatycznie konwertowane na kolokowane tabele rozproszone bez klucza fragmentu. Takie tabele są traktowane jako tabele schematów i są wyświetlane jako schemat w widoku citus_tables .

Odłamki

W poprzedniej sekcji opisano sposób przechowywania tabel rozproszonych jako fragmentów w węzłach procesu roboczego. W tej sekcji omówiono więcej szczegółów technicznych.

Tabela pg_dist_shard metadanych koordynatora zawiera wiersz dla każdego fragmentu każdej tabeli rozproszonej w systemie. Wiersz pasuje do identyfikatora fragmentu z zakresem liczb całkowitych w przestrzeni skrótu (shardminvalue, shardmaxvalue).

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)

Jeśli węzeł koordynacji chce określić, który fragment zawiera wiersz github_events, powoduje skrót wartości kolumny rozkładu w wierszu. Następnie węzeł sprawdza, który zakres fragmentów zawiera wartość skrótu. Zakresy są definiowane tak, aby obraz funkcji skrótu był ich rozłącznym związkiem.

Umieszczanie fragmentów

Załóżmy, że 102027 fragmentów jest skojarzony z danym wierszem. Wiersz jest odczytywany lub zapisywany w tabeli o nazwie github_events_102027 w jednym z procesów roboczych. Który proces roboczy? Jest to określane całkowicie przez tabele metadanych. Mapowanie fragmentu na proces roboczy jest nazywane umieszczaniem fragmentów.

Węzeł koordynacji ponownie zapisuje zapytania do fragmentów odwołujących się do określonych tabel, takich jak github_events_102027 i uruchamia te fragmenty dla odpowiednich procesów roboczych. Oto przykład zapytania uruchamianego w tle, aby znaleźć węzeł przechowujący identyfikator fragmentu 102027.

SELECT
    shardid,
    node.nodename,
    node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
  ON placement.groupid = node.groupid
 AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;

┌─────────┬───────────┬──────────┐
│ shardid │ nodename  │ nodeport │
├─────────┼───────────┼──────────┤
│  102027 │ localhost │     5433 │
└─────────┴───────────┴──────────┘

Następne kroki

Określanie typu aplikacji w celu przygotowania do modelowania danych
Sprawdź fragmenty i umieszczanie przy użyciu przydatnych zapytań diagnostycznych.

Share via