Välj shardantal i Azure Cosmos DB för PostgreSQL

GÄLLER FÖR: Azure Cosmos DB for PostgreSQL (drivs av Citus-databastillägget till PostgreSQL)

Att välja shardantalet för varje distribuerad tabell är en balans mellan flexibiliteten att ha fler shards och omkostnaderna för frågeplanering och körning i dem. Om du bestämmer dig för att ändra shardantalet för en tabell efter distributionen kan du använda funktionen alter_distributed_table .

SaaS-användningsfall för flera klientorganisationer

Det optimala valet varierar beroende på dina åtkomstmönster för data. I användningsfallet SaaS Database för flera innehavare rekommenderar vi till exempel att du väljer mellan 32 och 128 shards. För mindre arbetsbelastningar, till exempel <100 GB, kan du börja med 32 shards och för större arbetsbelastningar kan du välja 64 eller 128. Det här valet ger dig möjlighet att skala från 32 till 128 arbetsdatorer.

Användningsfall för realtidsanalys

I användningsfallet realtidsanalys bör antalet shard-värden vara relaterade till det totala antalet kärnor för arbetarna. För att säkerställa maximal parallellitet bör du skapa tillräckligt med shards på varje nod så att det finns minst en shard per CPU-kärna. Vi rekommenderar vanligtvis att du skapar ett stort antal inledande shards, till exempel 2x eller 4 gånger så många aktuella CPU-kärnor. Om du har fler shards kan du skala i framtiden om du lägger till fler arbetare och processorkärnor.

Tänk på att Azure Cosmos DB for PostgreSQL för varje fråga öppnar en databasanslutning per shard och att dessa anslutningar är begränsade. Var noga med att hålla shardantalet så litet att distribuerade frågor inte ofta behöver vänta på en anslutning. På ett annat sätt bör de anslutningar som behövs, (max concurrent queries * shard count), inte överskrida de totala anslutningar som är möjliga i systemet, (number of workers * max_connections per worker).

Nästa steg

• Läs mer om prestandaalternativ för kluster.
• Skala upp eller ut ett kluster
• Balansera om shards