Sdílet prostřednictvím

Vyberte počet shardů ve službě Azure Cosmos DB pro PostgreSQL

  • Platí pro: ✅ PostgreSQL

Důležité

Azure Cosmos DB for PostgreSQL se už pro nové projekty nepodporuje. Tuto službu nepoužívejte pro nové projekty. Místo toho použijte jednu z těchto dvou služeb:

  • Azure Cosmos DB for NoSQL můžete použít pro distribuované databázové řešení navržené pro vysoce škálovatelné scénáře s 99,999% smlouvou o úrovni služeb (SLA), okamžitým automatickým škálováním a automatickým převzetím služeb při selhání napříč několika oblastmi.

  • Použijte funkci Elastic Clusters služby Azure Database for PostgreSQL pro horizontálně dělené PostgreSQL pomocí opensourcového rozšíření Citus.

Volba počtu shardů pro každou distribuovanou tabulku je vyvážením mezi flexibilitou větším počtem shardů a režií pro plánování a provádění dotazů napříč shardy. Pokud se rozhodnete změnit počet horizontálních oddílů tabulky po distribuci, můžete použít funkci alter_distributed_table .

Případ použití SaaS s více tenanty

Optimální volba se liší v závislosti na vzorech přístupu pro data. Například v případě použití víceklientské databáze SaaS doporučujeme zvolit mezi 32 až 128 shardy. U menších úloh, řekněme <100 GB, můžete začít s 32 shardy a u větších úloh můžete zvolit 64 nebo 128. Tato volba vám dává prostor pro škálování od 32 do 128 pracovních strojů.

Případ použití analýzy v reálném čase

Při použití analýzy v reálném čase by měl počet shardů souviset s celkovým počtem jader na pracovnících. Abyste zajistili maximální paralelismus, měli byste na každém uzlu vytvořit dostatek shardů, aby byl alespoň jeden shard na jádro procesoru. Obvykle doporučujeme vytvořit velký počet počátečních fragmentů, například 2x nebo 4x počet aktuálních jader procesoru. Mít více fragmentů umožňuje budoucí škálování, pokud přidáte další pracovní procesy a jádra procesoru.

Mějte na paměti, že pro každý dotaz Azure Cosmos DB for PostgreSQL otevře jedno připojení k databázi na shard a tato připojení jsou omezená. Dbejte na to, aby byl počet shardů dostatečně malý, takže distribuované dotazy nebudou často muset čekat na připojení. Jinými slovy, potřebná připojení by (max concurrent queries * shard count)neměla překročit celkové možné připojení v systému, (number of workers * max_connections per worker).

Další kroky

  • Last updated on