Dela via

Elastiska kluster i Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Elastiskt kluster i Azure Database for PostgreSQL – flexibel server är ett hanterat erbjudande för Citus-tillägget med öppen källkod till PostgreSQL som möjliggör horisontell horisontell partitionering av PostgreSQL.

Citus är bara ett tillägg, men ansluter flera PostgreSQL-instanser. När Azure Database for PostgreSQL – flexibel server distribueras med Citus hanterar den hantering och konfiguration av flera PostgreSQL-instanser som en enda resurs. Den konfigurerar också automatiskt noderna och gör dem kända för Citus-tillägget.

Elastiska kluster på flexibel server erbjuder två horisontell partitioneringsmodeller: radbaserad horisontell partitionering och schemabaserad horisontell partitionering. Läs dokumentationen med öppen källkod om horisontell partitioneringsmodeller om du vill veta mer.

Arkitektur

Ett elastiskt kluster består av en eller flera noder i Azure Database for PostgreSQL – flexibel server. Dessa instanser görs automatiskt kända för varandra och kopplas samman för att bilda ett Citus-kluster. Noderna måste ha samma beräknings- och lagringsnivå och kan skalas jämnt upp eller ned till högre eller lägre nivåer.

Elastiskt kluster använder instanser av flexibla servrar (kallas noder) för att samordna med varandra i en arkitektur med "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.

När du ansluter till klustret med port 5432 hamnar du på den avsedda koordinatornoden. Med elastiska kluster kan du också lastbalansera anslutningar i klustret med en hash-metod med fem tupplar om du ansluter med port 7432. Med hjälp av 7432 kan du fortfarande landa på den nod som för närvarande är utsedd till koordinator. För vissa klusteromfattande åtgärder, till exempel distribution av tabeller, kan du behöva ansluta via port 5432. Vi rekommenderar starkt att du alltid ansluter på port 5432 när du planerar att utföra uppgraderingar av programscheman och liknande ändringar.

Till skillnad från Cosmos DB för PostgreSQL exponeras inte nodadresser externt. Om du tittar på Citus-metadatatabeller som pg_dist_nodekan du märka att alla noder har samma IP-adress som i exemplet 10.7.0.254 men olika portnummer.

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)

I Azures infrastruktur finns dessa noder på olika virtuella datorer även om de kan verka vara olika portar på samma dator.

Mer information om Citus finns i den officiella projektdokumentationen med öppen källkod.

Som standard distribueras inte tabeller och scheman som skapats med Citus automatiskt mellan klustret. Du måste bestämma dig för en horisontell partitioneringsmodell och antingen välja att distribuera scheman eller välja att distribuera dina tabelldata med radbaserad horisontell partitionering.

För varje fråga i distribuerade tabeller dirigerar den efterfrågade noden den antingen till en enda nod eller parallelliserar den över flera noder. Beslutet beror på om nödvändiga data finns på en enskild nod eller på flera. Med schemabaserad horisontell partitionering dirigerar koordinatorn frågorna direkt till den nod som är värd för schemat. I båda, schemabaserad horisontell partitionering och radbaserad horisontell partitionering, bestämmer noden vad den ska göra genom att konsultera metadatatabeller. De här tabellerna spårar nodernas plats och hälsa samt fördelningen av data mellan noder.

När data har distribuerats med någon av partitioneringsmodellerna kan du ansluta till någon av noderna för att utföra DML-åtgärder (DataModifieringsspråk) (SELECT, UPDATE, INSERT, DELETE). Alla noder innehåller de metadata som krävs för att hitta data som behövs för frågan och kan hämta dem för att besvara frågan.

DDL-åtgärder (Data Definition Language) och klusteromfattande åtgärder är för närvarande begränsade till noden som innehar koordinatorrollen. Kontrollera att du utför DDL- och klusteromfattande åtgärder genom att ansluta till port 5432 i stället för att använda port 7432.

Du kan skala ut ett elastiskt kluster genom att lägga till nya noder och ombalansera data på det. Ombalansering är en onlineåtgärd och blockerar inte arbetsbelastningar som körs.

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 om dessa shards.

Metadatatabellen pg_dist_shard innehåller en rad för varje fragment av varje distribuerad tabell i systemet. Raden matchar en fragmentidentifierare (shardid) med ett intervall med heltal i ett hash-blanksteg (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 noden 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. Med den information som lagras i metadatatabellerna avgör tillägget vad som är den specifika arbetaren. Mappningen av shard till arbetare kallas shardplacering.

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

Relaterat innehåll