Knoten und Tabellen in Azure Cosmos DB for PostgreSQL

  • Artikel

GILT FÜR: Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)

Knoten

Mit Azure Cosmos DB for PostgreSQL können PostgreSQL-Server (sogenannte Knoten) in einer „Shared-Nothing-Architektur“ miteinander koordiniert werden Die Knoten in einem Cluster enthalten zusammen mehr Daten und verwenden mehr CPU-Kerne, als auf einem einzelnen Server möglich wäre. Außerdem ermöglicht die Architektur das Skalieren der Datenbank durch Hinzufügen weiterer Knoten zum Cluster.

Koordinator und Worker

Jeder Cluster verfügt über einen Koordinatorknoten und mehrere Worker(knoten). Anwendungen senden ihre Abfragen an den Koordinatorknoten, der sie an die relevanten Worker weiterleitet und die Ergebnisse sammelt.

Azure Cosmos DB for PostgreSQL ermöglicht es dem Datenbankadministrator, Tabellen und/oder Schemas zu verteilen und verschiedene Zeilen auf verschiedenen Workerknoten zu speichern. Verteilte Tabellen und/oder verteilte Schemas sind entscheidend für die Leistung von Azure Cosmos DB for PostgreSQL. Wenn Tabellen und/oder Schemas nicht verteilt werden, verbleiben Sie vollständig auf dem Koordinatorknoten und profitieren nicht von computerübergreifender Parallelität.

Der Koordinator leitet jede Abfrage für verteilte Tabellen entweder an einen einzelnen Workerknoten weiter oder parallelisiert sie über mehrere Knoten, je nachdem, 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 Koordinator anhand von Metadatentabellen, was zu tun ist. In diesen Tabellen werden die DNS-Namen und die Integrität der Workerknoten sowie die Verteilung der Daten auf Knoten nachverfolgt.

Tabellentypen

In einem Cluster gibt es fünf Typen von Tabellen, die jeweils unterschiedlich auf Knoten gespeichert und für unterschiedliche Zwecke verwendet werden.

Typ 1: Verteilte Tabellen

Beim ersten und am häufigsten verwendeten Typ handelt es sich um verteilte Tabellen. Es scheint sich um normale Tabellen für SQL-Anweisungen zu handeln, sie sind jedoch auf Workerknoten horizontal partitioniert. Dies bedeutet, dass die Zeilen der Tabelle auf verschiedenen Knoten gespeichert werden: in Fragmenttabellen, so genannten Shards.

Azure Cosmos DB for PostgreSQL führt nicht nur SQL-, sondern auch DDL-Anweisungen in einem Cluster aus. Das Ändern des Schemas einer verteilten Tabelle aktualisiert kaskadierend alle Shards der Tabelle über mehrere Workerknoten hinweg.

Verteilungsspalte

Azure Cosmos DB for PostgreSQL verwendet algorithmisches Sharding, um Shards Zeilen zuzuweisen. Die Zuweisung erfolgt deterministisch basierend auf dem Wert einer Tabellenspalte, die als Verteilungsspalte bezeichnet wird. Der Clusteradministrator muss diese Spalte beim Verteilen einer Tabelle festlegen. Für Leistung und Funktionalität ist es wichtig, die richtige Entscheidung zu treffen.

Typ 2: Verweistabellen

Eine Verweistabelle ist ein Typ von verteilter Tabelle, deren gesamter Inhalt in einem einzigen Shard konzentriert ist. Der Shard wird auf jedem Workerknoten repliziert. Abfragen für jeden Worker können lokal auf die Verweisinformationen zugreifen, und zwar ohne den Netzwerkmehraufwand für das Anfordern von Zeilen von einem anderen Knoten. Verweistabellen weisen keine Verteilungsspalte auf, weil nicht zwischen separaten Shards pro Zeile unterschieden werden muss.

Verweistabellen sind in der Regel klein. Sie werden zum Speichern von Daten verwendet, die für Abfragen relevant sind, die auf allen Workerknoten ausgeführt werden. Ein Beispiel hierfür sind Enumerationswerte wie Auftragsstatus oder Produktkategorien.

Typ 3: Lokale Tabellen

Wenn Sie Azure Cosmos DB for PostgreSQL verwenden, handelt es sich bei dem Koordinatorknoten, mit dem Sie eine Verbindung herstellen, um eine reguläre PostgreSQL-Datenbank. Sie können auf dem Koordinatorknoten normale Tabellen erstellen und diese nicht horizontal partitionieren.

Kleine Verwaltungstabellen, die nicht an Join-Abfragen teilnehmen, würden sich gut als lokale Tabellen eignen. Ein Beispiel hierfür ist eine users-Tabelle für die Anmeldung und Authentifizierung von Anwendungen.

Typ 4: Lokale verwaltete Tabellen

Azure Cosmos DB for PostgreSQL kann automatisch lokale Tabellen zu Metadaten hinzufügen, wenn ein Fremdschlüsselverweis zwischen einer lokalen Tabelle und einer Verweistabelle vorhanden ist. Darüber hinaus können lokal verwaltete Tabellen manuell erstellt werden, indem die Funktion create_reference_table citus_add_local_table_to_metadata auf normalen lokalen Tabellen ausgeführt wird. Tabellen, die in Metadaten vorhanden sind, gelten als verwaltete Tabellen und können von jedem Knoten aus abgefragt werden. Citus weiß, dass er an den Koordinator weitergeleitet werden muss, um Daten aus der lokalen verwalteten Tabelle abzurufen. Solche Tabellen werden in der Ansicht citus_tables als lokal angezeigt.

Typ 5: Schematabellen

Mit dem in Citus 12.0 eingeführten schemabasierten Sharding werden verteilte Schemas automatisch einzelnen Zusammenstellungsgruppen zugeordnet. Die in diesen Schemas erstellten Tabellen werden in zusammengestellte verteilte Tabellen ohne Shardschlüssel konvertiert. Solche Tabellen gelten als Schematabellen und werden in der Ansicht citus_tables als Schema angezeigt.

Shards

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

Die Metadatentabelle pg_dist_shard auf dem Koordinatorknoten enthält eine Zeile für jeden Shard jeder verteilten Tabelle im System. Die Zeile stimmt mit einer Shard-ID 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 Koordinatorknoten 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 Shard den Bereich mit dem 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. Um welchen Worker handelt es sich dabei? Dies wird vollständig von den Metadatentabellen bestimmt. Die Zuordnung von Shard zu Worker wird als „Shardplatzierung“ bezeichnet.

Der Koordinatorknoten 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 die Shard-ID 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 │
└─────────┴───────────┴──────────┘

Nächste Schritte