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

Viktigt!

Azure Cosmos DB for PostgreSQL stöds inte längre för nya projekt. Använd inte den här tjänsten för nya projekt. Använd i stället en av dessa två tjänster:

• Använd Azure Cosmos DB för NoSQL för en distribuerad databaslösning som är utformad för storskaliga scenarier med ett serviceavtal på 99,999% tillgänglighet , omedelbar autoskalning och automatisk redundans i flera regioner.

• Använd funktionen Elastiska kluster i Azure Database For PostgreSQL för fragmenterad PostgreSQL med citus-tillägget med öppen källkod.

Att välja antalet shards för varje distribuerad tabell är en balans mellan flexibiliteten att ha fler shards och omkostnaderna för frågeplanering och körning över 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 med SaaS-databasen för flera användare rekommenderar vi till exempel att du väljer mellan 32 och 128 fragment. 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 shards vara relaterat till det totala antalet kärnor på 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
• Återbalansera shards