Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Importante
O Azure Cosmos DB para PostgreSQL está numa fase de reforma e já não é recomendado para novos projetos. Em vez disso, use um destes dois serviços:
Para cargas de trabalho PostgreSQL: utilize a funcionalidade Elastic Clusters da Azure Base de Dados para PostgreSQL para utilizar as funcionalidades de escalonamento horizontal e distribuição do PostgreSQL contidas na extensão open source Citus. Para orientação sobre migração, veja migrar para Base de Dados do Azure para PostgreSQL com Elastic Cluster.
Para cargas de trabalho NoSQL , utilize o Azure Cosmos DB para NoSQL como solução de base de dados distribuída que inclui um acordo de nível de serviço (SLA) de disponibilidade de 99,999%, escalabilidade automática instantânea e failover automático em múltiplas regiões.
Escolher a contagem de fragmentos para cada tabela distribuída é um equilíbrio entre a flexibilidade de ter mais fragmentos e a sobrecarga para o planeamento e a execução de consultas através deles. Se você decidir alterar a contagem de estilhaços de uma tabela após a distribuição, poderá usar a função alter_distributed_table .
Caso de uso de SaaS multilocatário
A escolha ideal varia dependendo dos seus padrões de acesso aos dados. Por exemplo, no caso de uso do banco de dados SaaS multilocatário, recomendamos escolher entre 32 a 128 fragmentos. Para cargas de trabalho menores, digamos <100 GB, você pode começar com 32 fragmentos e para cargas de trabalho maiores, você pode escolher 64 ou 128. Esta escolha dá-lhe a margem de manobra para escalar de 32 a 128 máquinas operárias.
Caso de uso de análise em tempo real
No caso de uso da Análise em Tempo Real, a contagem de partições deve relacionar-se com o número total de núcleos nos nós de processamento. Para garantir o máximo paralelismo, você deve criar fragmentos suficientes em cada nó para que haja pelo menos um fragmento por núcleo de CPU. Normalmente, recomendamos a criação de um alto número de fragmentos iniciais, por exemplo, 2x ou 4x o número de núcleos de CPU atuais. Ter mais fragmentos permite dimensionamento futuro se você adicionar mais trabalhadores e núcleos de CPU.
Lembre-se de que, para cada consulta, o Azure Cosmos DB para PostgreSQL abre uma conexão de banco de dados por fragmento e que essas conexões são limitadas. Tenha cuidado para manter a contagem de fragmentos pequena o suficiente para que as consultas distribuídas raramente precisem esperar por uma conexão. Dito de outra forma, as conexões necessárias, (max concurrent queries * shard count), não devem exceder o total de conexões possíveis no sistema, (number of workers * max_connections per worker).
Passos seguintes
- Saiba mais sobre as opções de desempenho do cluster.
- Dimensionar um cluster para cima ou para fora
- Reequilibrar estilhaços