Sdílet prostřednictvím

Uzly a tabulky ve službě Azure Cosmos DB for PostgreSQL

PLATÍ PRO: Azure Cosmos DB for PostgreSQL (využívající rozšíření databáze Citus do PostgreSQL)

Uzly

Azure Cosmos DB for PostgreSQL umožňuje, aby servery PostgreSQL (označované jako uzly) vzájemně koordinovaly v architektuře "shared nothing". Uzly v clusteru souhrnně obsahují více dat a používají více jader procesoru, než by bylo možné na jednom serveru. Architektura také umožňuje škálování databáze přidáním dalších uzlů do clusteru.

Koordinátor a pracovníci

Každý klastr má koordinační uzel a více pracovních uzlů. Aplikace odesílají své dotazy do koordinačního uzlu, který je předává příslušným pracovníkům a shromažďuje jejich výsledky.

Azure Cosmos DB for PostgreSQL umožňuje správci databáze distribuovat tabulky nebo schémata a ukládat různé řádky do různých pracovních uzlů. Distribuované tabulky a/nebo schémata jsou klíčem k výkonu služby Azure Cosmos DB for PostgreSQL. Nedostatečné rozložení tabulek nebo schémat znamená, že zůstanou zcela na koordinačním uzlu a nemůžou využít výhod paralelismu mezi počítači.

Pro každý dotaz v distribuovaných tabulkách ho koordinátor buď směruje do jednoho pracovního uzlu, nebo ho paralelizuje mezi několika v závislosti na tom, jestli se požadovaná data nacházejí v jednom uzlu nebo 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 horizontálního dělení, a to jak na základě schématu, tak na základě řádků, se koordinátor rozhodne, co má dělat, konzultováním tabulek metadat. Tyto tabulky sledují názvy DNS a stav pracovních uzlů a distribuci dat mezi uzly.

Typy tabulek

V clusteru je pět typů tabulek, z nichž každý je uložený jinak na uzlech a používá se pro různé účely.

Typ 1: Distribuované tabulky

Prvním typem a nejběžnějším typem jsou distribuované tabulky. Zdá se, že se jedná o normální tabulky příkazů SQL, ale jsou horizontálně rozdělené mezi pracovní uzly. To znamená, že řádky tabulky jsou uložené na různých uzlech v tabulkách fragmentů nazývaných shardy.

Azure Cosmos DB for PostgreSQL spouští nejen příkazy SQL, ale i DDL v celém clusteru. Změna schématu distribuované tabulky se projeví kaskádově a aktualizuje všechny fragmenty tabulky napříč pracovními procesy.

Distribuční sloupec

Azure Cosmos DB for PostgreSQL používá algoritmické horizontální dělení k přiřazování řádků horizontálním oddílům. Přiřazení se deterministicky provádí na základě hodnoty sloupce tabulky označovaného jako distribuční sloupec. Správce clusteru musí tento sloupec určit při distribuci tabulky. Správná volba je důležitá pro výkon a funkčnost.

Typ 2: Referenční tabulky

Referenční tabulka je typ distribuované tabulky, jejíž celý obsah je soustředěný do jednoho horizontálního oddílu. Fragment je replikován na každého pracovníka. Dotazy na kteréhokoli pracovníka mohou přistupovat k referenčním informacím přímo místně, bez síťové režie při vyžádání řádků z jiného uzlu. Referenční tabulky nemají žádný distribuční sloupec, protože není potřeba rozlišovat samostatné shardy na řádek.

Referenční tabulky jsou obvykle malé a používají se k ukládání dat, která jsou relevantní pro dotazy spuštěné na jakémkoli pracovním uzlu. Příkladem jsou výčtové hodnoty, jako jsou stavy objednávek nebo kategorie produktů.

Typ 3: Místní tabulky

Pokud používáte Službu Azure Cosmos DB for PostgreSQL, je koordinační uzel, ke kterému se připojujete, běžnou databází PostgreSQL. V koordinátoru můžete vytvořit běžné tabulky a zvolit, že je nebudete horizontálně dělit.

Vhodným kandidátem pro místní tabulky by byly malé administrativní tabulky, které se neúčastní dotazů spojení. Příkladem je users tabulka pro přihlašování a ověřování aplikací.

Typ 4: Místní spravované tabulky

Azure Cosmos DB for PostgreSQL může automaticky přidávat místní tabulky do metadat, pokud existuje odkaz na cizí klíč mezi místní tabulkou a referenční tabulkou. Kromě toho je možné místně spravované tabulky vytvořit ručně spuštěním create_reference_table citus_add_local_table_to_metadata funkce v běžných místních tabulkách. Tabulky, které jsou přítomné v metadatech, se považují za spravované tabulky a dají se dotazovat z libovolného uzlu. Citus ví, že se má směrovat do koordinátora za účelem získání dat z místní spravované tabulky. Tyto tabulky se zobrazují jako místní v zobrazení citus_tables.

Typ 5: Tabulky schématu

S horizontálním dělením založeným na schématu zavedeným v Citus 12.0 se distribuovaná schémata automaticky přidružují k jednotlivým skupinám kolokace. Tabulky vytvořené v těchto schématech se automaticky převedou na souběžně distribuované tabulky bez klíče pro horizontální rozdělení. Tyto tabulky jsou považovány za tabulky schématu a zobrazují se jako schéma v pohledu citus_tables.

Střepy

Předchozí část popsala, jak se distribuované tabulky ukládají jako datové fragmenty na pracovních uzlech. Tato část popisuje podrobnější technické podrobnosti.

Tabulka pg_dist_shard metadat v koordinátoru obsahuje řádek pro každý shard každé distribuované tabulky v systému. Řádek odpovídá ID fragmentu s rozsahem celých čísel v hashovacím prostoru (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 koordinační uzel chce určit, který shard obsahuje řádek github_events, použije hašovací funkci na hodnotu distribučního sloupce v řádku. Uzel pak zkontroluje, který rozsah horizontálních oddílů obsahuje hodnotu hash. Rozsahy jsou definovány tak, aby obraz funkce hash byl jejich nespojité sjednocení.

Umístění shardů

Předpokládejme, že shard 102027 je přidružen k příslušnému řádku. Řádek se přečte nebo zapíše do tabulky nazvané github_events_102027 v jednom z pracovníků. Který pracovník? To je určeno zcela tabulkami metadat. Mapování dílu na pracovníka se označuje jako umístění dílu.

Koordinační uzel přepíše dotazy do fragmentů, které odkazují na konkrétní tabulky, jako je github_events_102027 a spouští tyto fragmenty u příslušných pracovníků. Tady je příklad dotazu spuštěného na pozadí pro nalezení uzlu obsahujícího ID shardu 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 │
└─────────┴───────────┴──────────┘

Další kroky