Noder och tabeller i Azure Cosmos DB för PostgreSQL

Artikel
08/15/2024

GÄLLER FÖR: Azure Cosmos DB for PostgreSQL (drivs av Citus-databastillägget till PostgreSQL)

Noder

Med Azure Cosmos DB for PostgreSQL kan PostgreSQL-servrar (kallas noder) samordna med varandra i en arkitektur för "delat ingenting". Noderna i ett kluster innehåller tillsammans mer data och använder fler CPU-kärnor än vad som skulle vara möjligt på en enskild server. Arkitekturen gör också att databasen kan skalas genom att lägga till fler noder i klustret.

Koordinator och arbetare

Varje kluster har en koordinatornod och flera arbetare. Program skickar sina frågor till koordinatornoden, som vidarebefordrar dem till relevanta arbetare och ackumulerar sina resultat.

Med Azure Cosmos DB for PostgreSQL kan databasadministratören distribuera tabeller och/eller scheman och lagra olika rader på olika arbetsnoder. Distribuerade tabeller och/eller scheman är nyckeln till Azure Cosmos DB för PostgreSQL-prestanda. Om det inte går att distribuera tabeller och/eller scheman lämnar de dem helt på koordinatornoden och kan inte dra nytta av parallellitet mellan datorer.

För varje fråga i distribuerade tabeller dirigerar koordinatorn den antingen till en enda arbetsnod eller parallelliserar den över flera beroende på om nödvändiga data finns på en enda nod eller flera. Med schemabaserad horisontell partitionering dirigerar koordinatorn frågorna direkt till den nod som är värd för schemat. I både schemabaserad horisontell partitionering och radbaserad horisontell partitionering bestämmer koordinatorn vad som ska utföras genom att konsultera metadatatabeller. Dessa tabeller spårar DNS-namn och hälsotillstånd för arbetsnoder och fördelningen av data mellan noder.

Tabelltyper

Det finns fem typer av tabeller i ett kluster, var och en lagras på olika sätt på noder och används för olika ändamål.

Typ 1: Distribuerade tabeller

Den första typen, och den vanligaste, är distribuerade tabeller. De verkar vara normala tabeller till SQL-instruktioner, men de är horisontellt partitionerade mellan arbetsnoder. Det innebär att raderna i tabellen lagras på olika noder, i fragmenttabeller som kallas shards.

Azure Cosmos DB for PostgreSQL kör inte bara SQL utan DDL-instruktioner i ett kluster. Om du ändrar schemat för en distribuerad tabell kaskad uppdateras alla tabellens shards mellan arbetare.

Distributionskolumn

Azure Cosmos DB for PostgreSQL använder algoritmisk horisontell partitionering för att tilldela rader till shards. Tilldelningen görs deterministiskt baserat på värdet för en tabellkolumn som kallas för distributionskolumnen. Klusteradministratören måste ange den här kolumnen när en tabell distribueras. Att göra rätt val är viktigt för prestanda och funktioner.

Typ 2: Referenstabeller

En referenstabell är en typ av distribuerad tabell vars hela innehåll är koncentrerat till en enda shard. Fragmentet replikeras på varje arbetare. Frågor om alla arbetare kan komma åt referensinformationen lokalt, utan nätverkskostnaderna för att begära rader från en annan nod. Referenstabeller har ingen distributionskolumn eftersom det inte finns något behov av att särskilja separata shards per rad.

Referenstabeller är vanligtvis små och används för att lagra data som är relevanta för frågor som körs på alla arbetsnoder. Ett exempel är uppräknade värden som orderstatusar eller produktkategorier.

Typ 3: Lokala tabeller

När du använder Azure Cosmos DB för PostgreSQL är den koordinatornod som du ansluter till en vanlig PostgreSQL-databas. Du kan skapa vanliga tabeller på koordinatorn och välja att inte fragmentera dem.

En bra kandidat för lokala tabeller skulle vara små administrativa tabeller som inte deltar i anslutningsfrågor. Ett exempel är en users tabell för programinloggning och autentisering.

Typ 4: Lokala hanterade tabeller

Azure Cosmos DB for PostgreSQL kan automatiskt lägga till lokala tabeller i metadata om det finns en referens för sekundärnyckel mellan en lokal tabell och en referenstabell. Dessutom kan lokalt hanterade tabeller skapas manuellt genom att köra create_reference_table citus_add_local_table_to_metadata funktion i vanliga lokala tabeller. Tabeller som finns i metadata betraktas som hanterade tabeller och kan frågas från valfri nod, Citus vet att dirigera till koordinatorn för att hämta data från den lokala hanterade tabellen. Sådana tabeller visas som lokala i citus_tables vy.

Typ 5: Schematabeller

Med schemabaserad horisontell partitionering som introducerades i Citus 12.0 associeras distribuerade scheman automatiskt med enskilda samlokaliseringsgrupper. Tabeller som skapats i dessa scheman konverteras automatiskt till samallokerade distribuerade tabeller utan en shardnyckel. Sådana tabeller betraktas som schematabeller och visas som schema i citus_tables vy.

Skärvor

I föregående avsnitt beskrevs hur distribuerade tabeller lagras som shards på arbetsnoder. I det här avsnittet beskrivs mer teknisk information.

Metadatatabellen pg_dist_shard på koordinatorn innehåller en rad för varje fragment av varje distribuerad tabell i systemet. Raden matchar ett shard-ID med ett intervall med heltal i ett hash-utrymme (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)

Om koordinatornoden vill avgöra vilken shard som innehåller en rad med github_eventshashar värdet för distributionskolumnen på raden. Noden kontrollerar sedan vilket shard-intervall som innehåller det hashade värdet. Intervallen definieras så att bilden av hash-funktionen är deras osammanhängande union.

Shard-placeringar

Anta att shard-102027 är associerad med raden i fråga. Raden läss eller skrivs i en tabell som heter github_events_102027 i en av arbetarna. Vilken arbetare? Det bestäms helt av metadatatabellerna. Mappningen av shard till arbetare kallas shardplacering.

Koordinatornoden skriver om frågor till fragment som refererar till specifika tabeller som github_events_102027 och kör dessa fragment på lämpliga arbetare. Här är ett exempel på en fråga som körs i bakgrunden för att hitta noden som innehåller shard-ID:t 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 │
└─────────┴───────────┴──────────┘

Nästa steg

Fastställa programmets typ för att förbereda för datamodellering
Granska shards och placeringar med användbara diagnostikfrågor.

Dela via