Udostępnij za pomocą

Klastry elastyczne w usłudze Azure Database for PostgreSQL

Klastry elastyczne w usłudze Azure Database dla PostgreSQL to zarządzana usługa rozszerzenia Citus typu open source dla bazy danych PostgreSQL, która umożliwia poziome sharding bazy danych PostgreSQL.

Chociaż Citus jest tylko rozszerzeniem, łączy wiele wystąpień postgreSQL. Gdy wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL jest wdrażane za pomocą rozwiązania Citus, obsługuje zarządzanie i konfigurację wielu wystąpień bazy danych PostgreSQL jako pojedynczy zasób. Ponadto automatycznie konfiguruje węzły i udostępnia je rozszerzeniu Citus.

Klastry elastyczne w usłudze oferują dwa modele fragmentowania: fragmentowanie oparte na wierszach i fragmentowanie oparte na schemacie. Jeśli chcesz dowiedzieć się więcej, zapoznaj się z dokumentacją typu open source dotyczącą modeli fragmentowania.

Architektura

Klaster elastyczny składa się z jednego lub więcej węzłów elastycznych serwerów instancji Azure Database for PostgreSQL. Te wystąpienia są automatycznie znane sobie i połączone między sobą w celu utworzenia klastra Citus. Węzły muszą być w tej samej warstwie obliczeniowej i magazynowania i mogą być równomiernie skalowane w górę lub w dół do wyższych lub niższych warstw.

Klastry elastyczne używają instancji elastycznych serwerów, które nazywane są węzłami, aby koordynować się w architekturze "nic współdzielonego". Architektura umożliwia również skalowanie bazy danych przez dodanie kolejnych węzłów do klastra.

Nawiązywanie połączenia z klastrem przy użyciu portu 5432 ląduje w wyznaczonym węźle koordynatora. Klastry elastyczne umożliwiają również równoważenie obciążenia połączeń w klastrze przy użyciu metody skrótu z pięcioma krotkami, jeśli połączysz się przy użyciu portu 7432. Przy użyciu 7432 nadal można wylądować w węźle wyznaczonym obecnie jako koordynator. W przypadku niektórych operacji obejmujących cały klaster, takich jak dystrybucja tabel, może być wymagane nawiązanie połączenia za pośrednictwem portu 5432. Zdecydowanie zalecamy zawsze nawiązywanie połączenia na porcie 5432 podczas planowania przeprowadzania uaktualnień schematu aplikacji i podobnych zmian. Jeśli włączysz usługę PgBouncer w klastrach elastycznych, możesz użyć portu 8432 do równoważenia obciążenia połączeń między wystąpieniami narzędzia PgBouncer w każdym węźle (lub użyć portu 6432 dla wyznaczonego koordynatora).

W przeciwieństwie do usługi Cosmos DB for PostgreSQL adresy węzłów nie są uwidocznione zewnętrznie. Jeśli przyjrzysz się tabelom metadanych Citus, takim jak pg_dist_node, możesz zauważyć, że wszystkie węzły mają ten sam adres IP co w przykładzie 10.7.0.254 , ale różne numery portów.

select nodeid, nodename, nodeport from pg_dist_node;

 nodeid |  nodename  | nodeport
--------+------------+----------
      1 | 10.7.0.254 |     7000
      2 | 10.7.0.254 |     7001
 
(2 rows)

W infrastrukturze platformy Azure te węzły działają na różnych maszynach wirtualnych, mimo że mogą wydawać się różne porty na tej samej maszynie.

Aby dowiedzieć się więcej o usłudze Citus, zapoznaj się z oficjalną dokumentacją projektu open source.

Domyślnie tabele i schematy utworzone za pomocą usługi Citus nie są automatycznie dystrybuowane między klastrem. Musisz zdecydować się na model fragmentowania i zdecydować się na dystrybucję schematów lub zdecydować się na dystrybucję danych tabeli przy użyciu fragmentowania na podstawie wierszy.

Dla każdego zapytania w tabelach rozproszonych węzeł, którego dotyczy zapytanie, kieruje go do jednego węzła lub równoległie je w kilku węzłach. Decyzja zależy od tego, czy wymagane dane są przechowywane w jednym węźle, czy na wielu. W przypadku fragmentowania opartego na schemacie koordynator kieruje zapytania bezpośrednio do węzła, który hostuje schemat. W obu przypadkach fragmentowanie oparte na schemacie i fragmentowanie oparte na wierszach węzeł decyduje o tym, co zrobić, korzystając z tabel metadanych. Te tabele śledzą lokalizację i kondycję węzłów oraz rozkład danych między węzłami.

Gdy dane są dystrybuowane przy użyciu jednego z modeli fragmentowania, można nawiązać połączenie z dowolnymi węzłami, aby wykonać operacje DML (język modyfikacji danych) (SELECT, UPDATE, INSERT, DELETE). Wszystkie węzły zawierają metadane wymagane do zlokalizowania danych potrzebnych dla zapytania i są w stanie uzyskać je w celu udzielenia odpowiedzi na zapytanie.

Operacje DDL (Data Definition Language) i operacje całego klastra są obecnie ograniczone do węzła, w którym jest przechowywana rola koordynatora. Upewnij się, że wykonasz operacje DDL i całego klastra, łącząc się z portem 5432, zamiast używać portu 7432.

Klaster elastyczny można skalować w poziomie, dodając nowe węzły i ponownie zrównając dane. Ponowne równoważenie jest operacją online i nie blokuje uruchomionych obciążeń.

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 dotyczących tych fragmentów.

Tabela pg_dist_shard metadanych zawiera wiersz dla każdego fragmentu każdej rozproszonej tabeli w systemie. Wiersz pasuje do identyfikatora fragmentu (shardid) 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ł 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 shardu 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. Dzięki informacjom przechowywanym w tabelach metadanych rozszerzenie określa, co to jest konkretny proces roboczy. Mapowanie fragmentu na proces roboczy jest nazywane umieszczaniem fragmentów.

Węzeł 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 fragment z identyfikatorem 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 │
└─────────┴───────────┴──────────┘

Powiązana zawartość

  • Last updated on