Freigeben über

Elastische Cluster in Azure-Datenbank für PostgreSQL flexibler Server (Vorschau)

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

Elastic-Cluster auf Azure Database for PostgreSQL Flexible Server sind ein verwaltetes Angebot der Open-Source-Erweiterung Citus für PostgreSQL, das horizontales Sharding von PostgreSQL ermöglicht.

Während Citus nur eine Erweiterung ist, verbindet es mehrere PostgreSQL-Instanzen. Wenn Azure Database for PostgreSQL – Flexibler Server mit Citus bereitgestellt wird, verarbeitet err die Verwaltung und Konfiguration mehrerer PostgreSQL-Instanzen als einzelne Ressource. Sie richtet auch automatisch die Knoten ein und macht sie der Citus-Erweiterung bekannt.

Elastische Cluster auf Flexible Server bieten zwei Modelle für Sharding: zeilenbasiertes Sharding und schemabasiertes Sharding. Weitere Informationen finden Sie in der Open-Source-Dokumentation zu Shardingmodellen.

Aufbau

Ein elastischer Cluster besteht aus einem oder mehreren Knoten der Azure-Datenbank für PostgreSQL Flexible Server. Diese Instanzen werden einander automatisch bekannt gemacht und mit einem Citus-Cluster miteindener verbunden. Die Knoten müssen derselben Compute- und Speicherebene entsprechen und können einheitlich auf höhere/niedrigere Ebenen skaliert werden.

Elastische Cluster verwenden Instanzen von Flexible Servern (als Knoten bezeichnet), um sich in einer "Shared-Nothing"-Architektur abzustimmen. Außerdem ermöglicht die Architektur das Skalieren der Datenbank durch Hinzufügen weiterer Knoten zum Cluster.

Wenn Sie über Port 5432 eine Verbindung mit Ihrem Cluster herstellen, gelangen Sie zum angegebenen Koordinatorknoten. Elastische Cluster ermöglichen es Ihnen auch, Verbindungen über das Cluster mithilfe einer Fünf-Tupel-Hashmethode zu laden, wenn Sie eine Verbindung mit Port 7432 herstellen. Mit 7432 können Sie weiterhin am aktuell festgelegten Koordinatorknoten landen. Für bestimmte clusterweite Vorgänge, z. B. das Verteilen von Tabellen, müssen Sie möglicherweise eine Verbindung über Port 5432 herstellen. Es wird dringend empfohlen, immer eine Verbindung mit Port 5432 herzustellen, wenn Sie beabsichtigen, Anwendungsschemaupgrades und ähnliche Änderungen durchzuführen. Wenn Sie PgBouncer auf elastischen Clustern aktivieren, können Sie Port 8432 verwenden, um Verbindungen zwischen PgBouncer-Instanzen auf jedem Knoten zu laden (oder Port 6432 für den angegebenen Koordinator zu verwenden).

Im Gegensatz zu Cosmos DB für PostgreSQL werden Knotenadressen nicht extern verfügbar gemacht. Wenn Sie sich Citus-Metadatentabellen wie pg_dist_node ansehen, stellen Sie möglicherweise fest, dass alle Knoten dieselbe IP-Adresse aufweisen wie im Beispiel 10.7.0.254, aber unterschiedliche Portnummern.

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)

In der Infrastruktur von Azure befinden sich diese Knoten auf verschiedenen virtuellen Computern, obwohl sie möglicherweise unterschiedliche Ports auf demselben Computer sind.

Weitere Informationen zu Citus finden Sie in der offiziellen Open-Source-Projektdokumentation.

Standardmäßig werden Tabellen und Schemas, die mit Citus erstellt wurden, nicht automatisch auf den Cluster verteilt. Sie müssen sich für ein Shardingmodell entscheiden und entweder Schemas oder die Tabellendaten mit zeilenbasiertem Sharding verteilen.

Der abgefragte Knoten leitet jede Abfrage für verteilte Tabellen entweder an einen einzelnen Workerknoten weiter oder parallelisiert sie über mehrere Knoten. Diese Entscheidung hängt davon ab, ob sich die erforderlichen Daten auf einem einzelnen oder auf mehreren Knoten befinden. Mit schemabasiertem Sharding leitet der Koordinator die Abfragen direkt an den Knoten weiter, der das Schema hostet. Sowohl bei schemabasiertem Sharding als auch zeilenbasiertem Sharding entscheidet der Knoten anhand von Metadatentabellen, was zu tun ist. In diesen Tabellen werden der Speicherort und die Integrität der Knoten sowie die Verteilung der Daten auf Knoten nachverfolgt.

Sobald Daten mithilfe eines der Shardingmodelle verteilt wurden, können Sie eine Verbindung mit einem der Knoten herstellen, um DML-Vorgänge (Data Modification Language) auszuführen (SELECT, UPDATE, INSERT, DELETE). Alle Knoten enthalten die Metadaten, die zum Suchen von Daten erforderlich sind, was für die Abfrage benötigt wird, und können sie abrufen, um die Abfrage zu beantworten.

DDL-Vorgänge (Data Definition Language) und clusterweite Vorgänge sind derzeit auf den Knoten beschränkt, der die Koordinatorrolle besitzt. Vergewissern Sie sich., dass Sie DDL/clusterweite Vorgänge ausführen, indem Sie eine Verbindung mit Port 5432 herstellen, anstatt Port 7432 zu verwenden.

Sie können einen elastischen Cluster verkleinern, indem Sie neue Knoten hinzufügen und die Daten darin neu ausgleichen. Das Neuausgleichen ist ein Onlinevorgang und blockiert nicht die Ausführung von Arbeitslasten.

Shards

Im vorherigen Abschnitt wurde beschrieben, wie verteilte Tabellen als Shards auf Workerknoten gespeichert werden. In diesem Abschnitt werden weitere technische Details zu diesen Shards erläutert.

Die Metadatentabelle pg_dist_shard enthält eine Zeile für jeden Shard jeder verteilten Tabelle im System. Die Zeile stimmt mit einem Shardbezeichner (shardid) mit einem Bereich von Integerwerten in einem Hashbereich (shardminvalue, shardmaxvalue) überein.

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)

Wenn der Knoten ermitteln möchte, welcher Shard eine Zeile von github_events enthält, berechnet er den Hashwert der Verteilungsspalte in der Zeile. Anschließend überprüft der Knoten, welcher Bereich des Shards den Hashwert enthält. Die Bereiche sind so definiert, dass das Image der Hashfunktion ihre disjunkte Vereinigung ist.

Shardplatzierungen

Angenommen, Shard 102027 ist der betreffenden Zeile zugeordnet. Die Zeile wird in einer Tabelle mit dem Namen github_events_102027 in einem der Worker gelesen oder geschrieben. Mit den informationen, die in den Metadatentabellen gespeichert sind, bestimmt die Erweiterung, was dieser bestimmte Worker ist. Die Zuordnung von Shard zu Worker wird als „Shardplatzierung“ bezeichnet.

Der Knoten schreibt Abfragen in Fragmente um, die auf die bestimmten Tabellen verweisen (z.B. github_events_102027), und führt diese Fragmente auf den entsprechenden Workerknoten aus. Nachfolgend sehen Sie ein Beispiel für eine Abfrage, die im Hintergrund ausgeführt wird, um den Knoten zu ermitteln, der den Shard mit dem Bezeichner 102027 enthält.

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 │
└─────────┴───────────┴──────────┘

Verwandte Inhalte