Elastické clustery ve službě Azure Database for PostgreSQL

Elastické clustery ve službě Azure Database for PostgreSQL jsou spravovanou nabídkou open-source rozšíření Citus pro PostgreSQL, které umožňuje horizontální dělení PostgreSQL.

Citus je sice jen rozšíření, ale připojuje několik instancí PostgreSQL. Když je instance flexibilního serveru Azure Database for PostgreSQL nasazená pomocí Citus, zpracovává správu a konfiguraci několika instancí PostgreSQL jako jednoho prostředku. Také automaticky nastaví uzly a zpřístupňuje je rozšíření Citus.

Elastické clustery ve službě nabízejí dva modely horizontálního dělení: horizontální dělení na základě řádků a horizontální dělení založené na schématu. Další informace najdete v opensourcové dokumentaci k modelům horizontálního dělení.

Architektura

Elastický cluster se skládá z jednoho nebo několika uzlů instancí flexibilního serveru Azure Database for PostgreSQL. Tyto instance se navzájem automaticky zznají a vzájemně se propojují a tvoří cluster Citus. Uzly musí být stejné výpočetní a úložné vrstvy a dají se rovnoměrně škálovat nahoru nebo dolů na vyšší nebo nižší úrovně.

Elastické clustery používají instance flexibilních serverů (označovaných jako uzly) ke koordinaci s ostatními v architektuře "shared nothing". Architektura také umožňuje škálovat databázi přidáním dalších uzlů do clusteru.

Připojení ke clusteru pomocí portu 5432 vás přistane na určeném koordinačním uzlu. Elastické clustery také umožňují vyrovnávat zátěž připojení napříč clusterem pomocí pěti-prvkovou hashovou metodu, pokud se připojujete pomocí portu 7432. Pomocí 7432 můžete stále přistát na uzlu, který je aktuálně určen jako koordinátor. U některých operací v rámci clusteru, jako je distribuce tabulek, může být potřeba připojit se přes port 5432. Důrazně doporučujeme, abyste se vždy připojili na portu 5432, když plánujete provádět upgrady schémat aplikací a podobné změny. Pokud povolíte Nástroj PgBouncer v elastických clusterech, můžete pomocí portu 8432 vyrovnávat zatížení připojení mezi instancemi PgBouncer na každém uzlu (nebo použít port 6432 pro určený koordinátor).

Na rozdíl od Cosmos DB for PostgreSQL nejsou adresy uzlů externě vystavené. Pokud se podíváte na tabulky metadat Citus jako pg_dist_node, můžete si všimnout, že všechny uzly mají stejnou IP adresu jako v příkladu 10.7.0.254 , ale různá čísla portů.

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)

V infrastruktuře Azure tyto uzly žijí na různých virtuálních počítačích, i když se můžou zdát, že jsou na stejném počítači různé porty.

Další informace o Citus najdete v oficiální opensourcové dokumentaci k projektu.

Ve výchozím nastavení se tabulky a schémata vytvořená pomocí Citus automaticky nedistribuují mezi cluster. Musíte se rozhodnout o modelu horizontálního dělení a buď se rozhodnete distribuovat schémata, nebo se rozhodnete distribuovat data tabulky s horizontálním dělením na základě řádků.

U každého dotazu v distribuovaných tabulkách ho dotazovaný uzel buď směruje na jeden uzel, nebo ho paralelizuje napříč několika uzly. Rozhodnutí závisí na tom, jestli se požadovaná data nacházejí na jednom uzlu nebo na více. Při horizontálním dělení založeném na schématu směruje koordinátor dotazy přímo do uzlu, který je hostitelem schématu. V obou případech se horizontální dělení na základě schématu i horizontálního dělení na základě řádků rozhodne uzel, co dělat pomocí tabulek metadat. Tyto tabulky sledují umístění a stav uzlů a distribuci dat mezi uzly.

Jakmile se data distribuují pomocí jednoho z modelů horizontálního dělení, můžete se připojit k libovolnému uzlu a provádět operace DML (Data Modification Language) (SELECT, UPDATE, INSERT, DELETE). Všechny uzly obsahují metadata potřebná k vyhledání dat potřebných pro dotaz a jsou schopny je získat k zodpovězení dotazu.

Operace DDL (Data Definition Language) a operace v celém clusteru jsou v současné době omezené na uzel, který má koordinační roli. Ujistěte se, že provádíte operace DDL a clusteru tak, že se místo portu 7432 připojujete k portu 5432.

Elastický cluster můžete škálovat přidáním nových uzlů a opětovným vyvážením dat. Vyrovnávání je online operace a neblokuje spouštění úloh.

Střepy

Předchozí část popisuje, jak se distribuované tabulky ukládají jako horizontální oddíly na pracovních uzlech. Tato část popisuje podrobnější technické podrobnosti o těchto horizontálních oddílech.

Tabulka pg_dist_shard metadat obsahuje řádek pro každý horizontální oddíl každé distribuované tabulky v systému. Řádek odpovídá identifikátoru horizontálního oddílu (shardid) s rozsahem celých čísel v prostoru hash (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)

Pokud uzel chce zjistit, který horizontální oddíl obsahuje řádek github_events, zatřiďuje hodnotu distribučního sloupce v řádku. Pak uzel zkontroluje, který rozsah fragmentů obsahuje hodnotu hash. Rozsahy jsou definovány tak, aby obrázek funkce hash byl jejich nesouvislý sjednocení.

Umístění horizontálních oddílů

Předpokládejme, že 102027 horizontálních oddílů je přidružený k příslušnému řádku. Řádek se přečte nebo zapíše do tabulky volané github_events_102027 v jednom z pracovních procesů. Když jsou informace uložené v tabulkách metadat, rozšíření určuje, co je tento konkrétní pracovní proces. Mapování horizontálních oddílů na pracovní proces se označuje jako umístění horizontálních oddílů.

Uzel přepíše dotazy do fragmentů, které odkazují na konkrétní tabulky, jako jsou github_events_102027 a spouští tyto fragmenty u příslušných pracovních procesů. Tady je příklad dotazu spuštěného na pozadí a vyhledání uzlu, který obsahuje horizontální oddíl s identifikátorem 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 │
└─────────┴───────────┴──────────┘

Související obsah

• Modely horizontálního dělení v elastických clusterech ve službě Azure Database for PostgreSQL
• Typy tabulek v elastických clusterech ve službě Azure Database for PostgreSQL
• Nejčastější dotazy týkající se elastických clusterů s omezeními Služby Azure Database for PostgreSQL