Condividi tramite

Scegliere il numero di partizioni in Azure Cosmos DB for PostgreSQL

  • Articolo

SI APPLICA A: Azure Cosmos DB for PostgreSQL (con tecnologia basata su estensione di database Citus per PostgreSQL)

La scelta del numero di partizioni per ogni tabella distribuita è un equilibrio tra la flessibilità di avere più partizioni e il sovraccarico per la pianificazione e l'esecuzione delle query. Se si decide di modificare il numero di partizioni di una tabella dopo la distribuzione, è possibile usare la funzione alter_distributed_table.

Caso d'uso relativo al SaaS multi-tenant

La scelta ottimale varia a seconda dei criteri di accesso per i dati. Ad esempio, nel caso d'uso del database SaaS multi-tenant è consigliabile scegliere tra 32 e 128 partizioni. Per carichi di lavoro di minori dimensioni, ad esempio <100 GB, è possibile iniziare con 32 partizioni e per carichi di lavoro di dimensioni maggiori è possibile scegliere 64 o 128. Questa scelta offre la flessibilità di dimensionare da 32 a 128 macchine di lavoro.

Caso d'uso relativo all'analisi in tempo reale

Nel caso d'uso di Analytics in tempo reale, il numero di partizioni deve essere correlato al numero totale di core nei ruoli di lavoro. Per garantire il massimo parallelismo, è necessario creare partizioni sufficienti in ogni nodo in modo che vi sia almeno una partizione per ogni core CPU. In genere è consigliabile creare un numero elevato di partizioni iniziali, ad esempio 2x o 4x il numero di core CPU correnti. La presenza di più partizioni consente il ridimensionamento futuro se si aggiungono altri ruoli di lavoro e core CPU.

Tenere presente che, per ogni query, Azure Cosmos DB for PostgreSQL apre una connessione di database per partizione e che queste connessioni sono limitate. Prestare attenzione a mantenere il numero di partizioni sufficientemente ridotto, così che le query distribuite non dovranno attendere spesso una connessione. Secondo un altro punto di vista, le connessioni necessarie, (max concurrent queries * shard count), non devono superare le connessioni totali possibili nel sistema, (number of workers * max_connections per worker).

Passaggi successivi