Sdílet prostřednictvím

Výběr distribučních sloupců ve službě Azure Cosmos DB for PostgreSQL

  • Článek

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

Výběr distribučního sloupce tabulky představuje jedno z nejdůležitějších rozhodnutí při modelování. Azure Cosmos DB for PostgreSQL ukládá řádky do horizontálních oddílů na základě hodnoty distribučního sloupce řádků.

Správná volba seskupí související data na stejných fyzických uzlech, což umožňuje rychlé dotazy a přidává podporu pro všechny funkce SQL. Nesprávná volba způsobí, že systém běží pomalu.

Obecné tipy

Tady jsou čtyři kritéria pro výběr ideálního distribučního sloupce pro distribuované tabulky.

  1. Vyberte sloupec, který je centrální součástí úlohy aplikace.

    Tento sloupec si můžete představit jako "srdce", "centrální část" nebo "přirozenou dimenzi" pro dělení dat.

    Příklady:

    • device_id v úloze IoT
    • security_id finanční aplikace, která sleduje cenné papíry
    • user_id v analýze uživatelů
    • tenant_id pro víceklientské aplikace SaaS

  2. Vyberte sloupec s slušnou kardinalitou a rovnoměrným statistickým rozdělením.

    Sloupec by měl mít mnoho hodnot a důkladně a rovnoměrně distribuovat mezi všechny horizontální oddíly.

    Příklady:

    • Kardinalita nad 1000
    • Nevybíjejte sloupec, který má stejnou hodnotu u velkého procenta řádků (nerovnoměrná distribuce dat).
    • V úloze SaaS může mít jeden tenant mnohem větší než zbytek, který může způsobit nerovnoměrnou distribuci dat. V takovém případě můžete pomocí izolace tenanta vytvořit vyhrazený horizontální oddíl pro zpracování tenanta.

  3. Vyberte sloupec, který má výhody pro vaše stávající dotazy.

    Pro transakční nebo provozní úlohu (kde většina dotazů trvá jen několik milisekund), vyberte sloupec, který se zobrazí jako filtr v WHERE klauzulích pro nejméně 80 % dotazů. Například device_id sloupec v SELECT * FROM events WHERE device_id=1.

    Pro analytickou úlohu (kde většina dotazů trvá 1 až 2 sekundy) vyberte sloupec, který umožňuje paralelizaci dotazů napříč pracovními uzly. Například sloupec, který se často vyskytuje v klauzulích GROUP BY, nebo dotazovaný na více hodnot najednou.

  4. Vyberte sloupec, který se nachází ve většině velkých tabulek.

    Tabulky nad 50 GB by se měly distribuovat. Výběr stejného distribučního sloupce pro všechny z nich umožňuje společně vyhledat data pro tento sloupec na pracovních uzlech. Spolulokace umožňuje efektivní spouštění joinů a kumulativních funkcí a vynucování cizích klíčů.

    Ostatní (menší) tabulky můžou být místní nebo referenční tabulky. Pokud menší tabulka potřebuje SPOJIT s distribuovanými tabulkami, vytvořte ji jako referenční tabulku.

Příklady použití

Viděli jsme obecná kritéria pro výběr distribučního sloupce. Teď se podíváme, jak se vztahují na běžné případy použití.

Aplikace s více tenanty

Architektura s více tenanty používá k distribuci dotazů napříč uzly v clusteru formu hierarchického modelování databáze. Horní část hierarchie dat se označuje jako ID tenanta a musí být uložena ve sloupci v každé tabulce.

Azure Cosmos DB for PostgreSQL kontroluje dotazy, abyste zjistili, které ID tenanta zahrnují, a najde odpovídající horizontální oddíl tabulky. Dotaz směruje do jednoho pracovního uzlu, který obsahuje horizontální oddíl. Spuštění dotazu se všemi relevantními daty umístěnými na stejném uzlu se nazývá kolokace.

Následující diagram znázorňuje kolokaci v datovém modelu s více tenanty. Obsahuje dvě tabulky, klienty a kampaně, z nichž každý distribuuje account_id. Stínovaná pole představují horizontální oddíly. Zelené horizontální oddíly se ukládají společně na jednom pracovním uzlu a modré horizontální oddíly se ukládají na jiný pracovní uzel. Všimněte si, že dotaz spojení mezi účty a kampaněmi obsahuje všechna potřebná data na jednom uzlu, pokud jsou obě tabulky omezené na stejnou account_id.

Víceklientskokace

Pokud chcete tento návrh použít ve vlastním schématu, určete, co představuje tenanta ve vaší aplikaci. Mezi běžné instance patří společnost, účet, organizace nebo zákazník. Název sloupce bude něco podobného company_id nebo customer_id. Prozkoumejte každý z vašich dotazů a zeptejte se sami sebe, fungovalo by to, kdyby obsahovalo více klauzulí WHERE, aby se omezily všechny tabulky, které jsou součástí řádků se stejným ID tenanta? Dotazy v modelu s více tenanty jsou vymezeny na tenanta. Dotazy na prodej nebo inventář jsou například vymezeny v určitém obchodě.

Osvědčené postupy

  • Distribuce tabulek běžným sloupcem tenant_id Například v aplikaci SaaS, kde jsou tenanti společnostmi, bude tenant_id pravděpodobně company_id.
  • Převeďte malé tabulky napříč tenanty na referenční tabulky. Pokud několik tenantů sdílí malou tabulku informací, distribuujte ji jako referenční tabulku.
  • Omezte filtrování všech aplikačních dotazů podle tenant_id. Každý dotaz by měl požadovat informace pro jednoho tenanta najednou.

Příklad sestavení tohoto typu aplikace najdete v kurzu s více tenanty.

Aplikace v reálném čase

Architektura s více tenanty představuje hierarchickou strukturu a používá kolokaci dat ke směrování dotazů na tenanta. Naproti tomu architektury v reálném čase závisí na konkrétních distribučních vlastnostech jejich dat, aby bylo dosaženo vysoce paralelního zpracování.

Jako termín pro distribuční sloupce v modelu v reálném čase používáme "ID entity". Typické entity jsou uživatelé, hostitelé nebo zařízení.

Dotazy v reálném čase obvykle požádají o číselné agregace seskupené podle data nebo kategorie. Azure Cosmos DB for PostgreSQL odesílá tyto dotazy do každého horizontálního oddílu pro částečné výsledky a sestaví konečnou odpověď na koordinačním uzlu. Dotazy běží nejrychleji, když co nejvíce uzlů přispívá, a když žádný jeden uzel nesmí provádět nepřiměřenou práci.

Osvědčené postupy

  • Zvolte sloupec s vysokou kardinalitou jako distribuční sloupec. Pro porovnání je pole Stav v tabulce objednávek s hodnotami New, Paid a Shipped špatnou volbou distribučního sloupce. Předpokládá pouze ty málo hodnot, které omezují počet horizontálních oddílů, které můžou uchovávat data, a počet uzlů, které je můžou zpracovat. Mezi sloupci s vysokou kardinalitou je také vhodné zvolit sloupce, které se často používají v klauzulích seskupit podle nebo jako spojovací klíče.
  • Zvolte sloupec se sudým rozdělením. Pokud distribuujete tabulku ve sloupci nerovnoměrně s určitými běžnými hodnotami, data v tabulce se obvykle hromadí v určitých horizontálních oddílech. Uzly, které obsahují tyto horizontální oddíly, končí větší práci než jiné uzly.
  • Distribuce tabulek faktů a dimenzí ve společných sloupcích Tabulka faktů může mít pouze jeden distribuční klíč. Tabulky, které se spojují na jiném klíči, nebudou společně s tabulkou faktů společné. Zvolte jednu dimenzi, která se má přidělovat na základě četnosti spojení a velikosti spojovacích řádků.
  • Změňte některé tabulky dimenzí na referenční tabulky. Pokud tabulku dimenzí nelze společně s tabulkou faktů připojit, můžete zlepšit výkon dotazů tak, že distribuujete kopie tabulky dimenzí do všech uzlů ve formě referenční tabulky.

V kurzu řídicího panelu v reálném čase si můžete přečíst příklad, jak tento druh aplikace sestavit.

Data časových řad

V úloze časových řad se aplikace dotazují na poslední informace, zatímco archivují staré informace.

Nejběžnější chybou při modelování informací časových řad ve službě Azure Cosmos DB for PostgreSQL je použití samotného časového razítka jako distribučního sloupce. Distribuce hodnot hash založená na čase distribuuje časy zdánlivě náhodně do různých horizontálních oddílů a nedrží rozsahy času v horizontálních oddílech. Dotazy, které zahrnují časové rozsahy obecně odkazovaných na časové intervaly, například nejnovější data. Tento typ distribuce hodnot hash vede k režii sítě.

Osvědčené postupy

  • Nevybírejte časové razítko jako distribuční sloupec. Zvolte jiný distribuční sloupec. V aplikaci s více tenanty použijte ID tenanta nebo v aplikaci v reálném čase použijte ID entity.
  • Místo toho používejte dělení tabulek PostgreSQL. Dělení tabulky slouží k rozdělení velké tabulky časově uspořádaných dat do několika zděděných tabulek s každou tabulkou obsahující různé časové rozsahy. Distribuce postgres dělené tabulky vytvoří horizontální oddíly pro zděděné tabulky.

Další kroky

  • Zjistěte, jak kolokace mezi distribuovanými daty pomáhá rychle spouštět dotazy.
  • Seznamte se s distribučním sloupcem distribuované tabulky a dalšími užitečnými diagnostickými dotazy.