Escolher a contagem de partições horizontais no Azure Cosmos DB para PostgreSQL

  • Artigo

APLICA-SE A: Azure Cosmos DB para PostgreSQL (com tecnologia da extensão da base de dados Citus para PostgreSQL)

Escolher a contagem de partições horizontais para cada tabela distribuída é um equilíbrio entre a flexibilidade de ter mais partições horizontais e a sobrecarga para o planeamento e execução de consultas nas mesmas. Se decidir alterar a contagem de partições horizontais de uma tabela após a distribuição, pode utilizar a função alter_distributed_table .

Caso de utilização SaaS multi-inquilino

A escolha ideal varia consoante os padrões de acesso dos dados. Por exemplo, no caso de utilização da Base de Dados SaaS multi-inquilino, recomendamos que escolha entre 32 a 128 partições horizontais. Para cargas de trabalho mais pequenas, por <exemplo, 100 GB, pode começar com 32 partições horizontais e, para cargas de trabalho maiores, pode escolher 64 ou 128. Esta opção dá-lhe a margem de manobra para dimensionar de 32 para 128 máquinas de trabalho.

Caso de utilização da análise em tempo real

No caso de utilização do Real-Time Analytics, a contagem de partições horizontais deve estar relacionada com o número total de núcleos nas funções de trabalho. Para garantir o paralelismo máximo, deve criar partições horizontais suficientes em cada nó para que exista, pelo menos, uma partição horizontal por núcleo da CPU. Normalmente, recomendamos a criação de um número elevado de partições horizontais iniciais, por exemplo, 2x ou 4x o número de núcleos de CPU atuais. Ter mais partições horizontais permite o dimensionamento futuro se adicionar mais funções de trabalho e núcleos de CPU.

Tenha em atenção que, para cada consulta, o Azure Cosmos DB para PostgreSQL abre uma ligação de base de dados por partição horizontal e que estas ligações são limitadas. Tenha cuidado para manter a contagem de partições horizontais suficientemente pequena para que as consultas distribuídas não tenham muitas vezes de esperar por uma ligação. Dito de outra forma, as ligações necessárias, (max concurrent queries * shard count), não devem exceder o total de ligações possíveis no sistema, (number of workers * max_connections per worker).

Passos seguintes