Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Elastiska kluster i Azure Database för PostgreSQL-tjänsten är ett hanterat erbjudande av Citus-tillägget med öppen källkod till PostgreSQL som möjliggör horisontell partitionering av PostgreSQL.
Citus är bara ett tillägg, men ansluter flera PostgreSQL-instanser. När du distribuerar en Azure Database for PostgreSQL flexibel server 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 i tjänsten erbjuder två horisontell partitioneringsmodeller: radbaserad horisontell partitionering och schemabaserad horisontell partitionering. Mer information finns i dokumentationen med öppen källkod om horisontell partitionering av modeller.
Architecture
Ett elastiskt kluster består av en eller flera noder av Azure Database for PostgreSQL flexibla servrar. Dessa instanser identifierar automatiskt varandra och ansluter till ett Citus-kluster. Noderna måste vara samma beräknings- och lagringsnivå och du kan skala dem jämnt upp eller ned till högre eller lägre nivåer.
Elastiska kluster använder instanser av flexibla servrar (kallas noder) för att samordna med varandra i en arkitektur med "delat ingenting". Arkitekturen gör också att databasen kan skalas genom att lägga till fler noder i klustret.
Elastiska kluster använder flexibla servrar (kallas noder) för att samordna med varandra i en delad ingenting-arkitektur . Arkitekturen gör också att databasen kan skalas genom att lägga till fler noder i klustret.
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. Omfördelning är en onlineåtgärd och blockerar inte pågående arbetsbelastningar.
Skärvor
I föregående avsnitt beskrevs hur distribuerade tabeller lagras som fragment på arbetsnoder. Det här avsnittet behandlar fler tekniska detaljer om dessa skärvor.
Metadatatabellen pg_dist_shard innehåller en rad för varje fragment av varje distribuerad tabell i systemet. Raden kopplar en shardidentifierare (shardid) till ett intervall av heltal i ett hashutrymme (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 i github_events, hashar den värdet i radens distributionskolumn. 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äses eller skrivs i en tabell som heter github_events_102027 av en av arbetarna. Med hjälp av informationen som lagras i metadatatabellerna avgör tillägget vilken specifik arbetare som ska användas. Kartläggningen 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 │
└─────────┴───────────┴──────────┘