Knooppunten en tabellen in Azure Cosmos DB for PostgreSQL

  • Artikel

VAN TOEPASSING OP: Azure Cosmos DB for PostgreSQL (mogelijk gemaakt door de Citus-database-extensie naar PostgreSQL)

Knooppunten

Met Azure Cosmos DB for PostgreSQL kunnen PostgreSQL-servers (knooppunten genoemd) met elkaar samenwerken in een architectuur met 'gedeelde niets'. De knooppunten in een cluster bevatten gezamenlijk meer gegevens en gebruiken meer CPU-kernen dan mogelijk is op één server. Met de architectuur kan de database ook worden geschaald door meer knooppunten toe te voegen aan het cluster.

Coördinator en werknemers

Elk cluster heeft een coördinatorknooppunt en meerdere werkrollen. Toepassingen verzenden hun query's naar het coördinatorknooppunt, dat het doorstuurt naar de relevante werknemers en hun resultaten verzamelt.

Met Azure Cosmos DB for PostgreSQL kan de databasebeheerder tabellen en/of schema's distribueren , waarbij verschillende rijen op verschillende werkknooppunten worden opgeslagen. Gedistribueerde tabellen en/of schema's zijn de sleutel tot prestaties van Azure Cosmos DB for PostgreSQL. Als u tabellen en/of schema's niet distribueert, blijven ze volledig op het coördinatorknooppunt staan en kunnen ze niet profiteren van parallelle uitvoering van meerdere machines.

Voor elke query in gedistribueerde tabellen stuurt de coördinator deze naar één werkknooppunt of parallelliseert deze over meerdere, afhankelijk van of de vereiste gegevens zich op één knooppunt of meerdere bevinden. Met sharding op basis van schema's stuurt de coördinator de query's rechtstreeks naar het knooppunt dat als host fungeert voor het schema. In zowel op schema gebaseerde sharding als op rij gebaseerde sharding bepaalt de coördinator wat er moet worden uitgevoerd door tabellen met metagegevens te raadplegen. Deze tabellen volgen de DNS-namen en status van werkknooppunten en de distributie van gegevens over knooppunten.

Tabeltypen

Er zijn vijf typen tabellen in een cluster, die elk verschillend zijn opgeslagen op knooppunten en voor verschillende doeleinden worden gebruikt.

Type 1: Gedistribueerde tabellen

Het eerste type, en het meest voorkomende, is gedistribueerde tabellen. Ze lijken normale tabellen te zijn voor SQL-instructies, maar ze zijn horizontaal gepartitioneerd over werkknooppunten. Dit betekent dat de rijen van de tabel worden opgeslagen op verschillende knooppunten, in fragmenttabellen met de naam shards.

Azure Cosmos DB for PostgreSQL voert niet alleen SQL- maar DDL-instructies uit in een cluster. Het schema van een gedistribueerde tabel trapsgewijs wijzigen om alle shards van de tabel over werkrollen bij te werken.

Distributiekolom

Azure Cosmos DB for PostgreSQL maakt gebruik van algoritme-sharding om rijen toe te wijzen aan shards. De toewijzing wordt deterministisch gemaakt op basis van de waarde van een tabelkolom die de distributiekolom wordt genoemd. De clusterbeheerder moet deze kolom aanwijzen bij het distribueren van een tabel. Het maken van de juiste keuze is belangrijk voor prestaties en functionaliteit.

Type 2: Referentietabellen

Een verwijzingstabel is een type gedistribueerde tabel waarvan de volledige inhoud is geconcentreerd in één shard. De shard wordt op elke werkrol gerepliceerd. Query's op elke werkrol hebben lokaal toegang tot de referentiegegevens, zonder de netwerkoverhead van het aanvragen van rijen vanaf een ander knooppunt. Verwijzingstabellen hebben geen distributiekolom omdat er geen onderscheid hoeft te worden gemaakt tussen afzonderlijke shards per rij.

Referentietabellen zijn doorgaans klein en worden gebruikt voor het opslaan van gegevens die relevant zijn voor query's die worden uitgevoerd op een werkknooppunt. Een voorbeeld hiervan zijn opgesomde waarden, zoals orderstatussen of productcategorieën.

Type 3: Lokale tabellen

Wanneer u Azure Cosmos DB for PostgreSQL gebruikt, is het coördinatorknooppunt waarmee u verbinding maakt een gewone PostgreSQL-database. U kunt gewone tabellen maken in de coördinator en ervoor kiezen om ze niet te sharden.

Een goede kandidaat voor lokale tabellen is kleine beheertabellen die niet deelnemen aan joinquery's. Een voorbeeld hiervan is een users tabel voor aanmelding en verificatie van toepassingen.

Type 4: Lokale beheerde tabellen

Azure Cosmos DB for PostgreSQL kan automatisch lokale tabellen toevoegen aan metagegevens als er een verwijzing naar een refererende sleutel bestaat tussen een lokale tabel en een referentietabel. Daarnaast kunnen lokaal beheerde tabellen handmatig worden gemaakt door create_reference_table citus_add_local_table_to_metadata functie uit te voeren op normale lokale tabellen. Tabellen die aanwezig zijn in metagegevens worden beschouwd als beheerde tabellen en kunnen vanuit elk knooppunt worden opgevraagd. Citus weet dat ze naar de coördinator moeten worden gerouteerd om gegevens te verkrijgen uit de lokale beheerde tabel. Dergelijke tabellen worden weergegeven als lokaal in citus_tables weergave.

Type 5: Schematabellen

Met sharding op basis van schema's die zijn geïntroduceerd in Citus 12.0, worden gedistribueerde schema's automatisch gekoppeld aan afzonderlijke colocatiegroepen. Tabellen die in deze schema's worden gemaakt, worden automatisch geconverteerd naar gedistribueerde tabellen met een puntkomma zonder een shardsleutel. Dergelijke tabellen worden beschouwd als schematabellen en worden weergegeven als schema in citus_tables weergave.

Scherven

In de vorige sectie wordt beschreven hoe gedistribueerde tabellen worden opgeslagen als shards op werkknooppunten. In deze sectie worden meer technische details besproken.

De pg_dist_shard metagegevenstabel in de coördinator bevat een rij voor elke shard van elke gedistribueerde tabel in het systeem. De rij komt overeen met een shard-id met een bereik van gehele getallen in een hash-ruimte (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)

Als het coördinatorknooppunt wil bepalen welke shard een rij github_eventsbevat, heeft het de waarde van de distributiekolom in de rij. Vervolgens controleert het knooppunt welk shardbereik de hash-waarde bevat. De bereiken worden gedefinieerd zodat de afbeelding van de hash-functie de niet-aaneengesloten samenvoeging is.

Shard-plaatsingen

Stel dat shard-102027 is gekoppeld aan de betreffende rij. De rij wordt gelezen of geschreven in een tabel die wordt aangeroepen github_events_102027 in een van de werkrollen. Welke werknemer? Dit wordt volledig bepaald door de metagegevenstabellen. De toewijzing van shard aan werkrol wordt de shardplaatsing genoemd.

Het coördinatorknooppunt herschrijft query's in fragmenten die verwijzen naar de specifieke tabellen, zoals github_events_102027 en voert deze fragmenten uit op de juiste werkrollen. Hier volgt een voorbeeld van een query die achter de schermen wordt uitgevoerd om het knooppunt met de shard-id te vinden 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 │
└─────────┴───────────┴──────────┘

Volgende stappen