Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Importante
O Azure Cosmos DB para PostgreSQL não tem mais suporte para novos projetos. Não use esse serviço para novos projetos. Em vez disso, use um destes dois serviços:
Use o Azure Cosmos DB para NoSQL para uma solução de banco de dados distribuída projetada para cenários de alta escala com um SLA (contrato de nível de serviço de disponibilidade) de 99,999%, dimensionamento automático instantâneo e failover automático em várias regiões.
Use o Recurso Clusters Elásticos do Banco de Dados do Azure para PostgreSQL no PostgreSQL compartilhado usando a extensão de código aberto Citus.
O particionamento em fragmentos é uma técnica usada em sistemas de banco de dados e computação distribuída para dividir dados em vários servidores ou nós de forma horizontal. Isso envolve dividir um grande banco de dados ou conjunto de dados em partes menores e mais gerenciáveis chamadas Fragmentos. Um fragmento contém um subconjunto dos dados e, juntos, os fragmentos formam o conjunto de dados completo.
O Azure Cosmos DB for PostgreSQL oferece dois tipos de fragmentação de dados, ou seja, baseado em linha e baseado em esquema. Cada opção vem com suas próprias Compensações de fragmentação, permitindo que você escolha a abordagem que melhor se alinha aos requisitos do aplicativo.
Fragmentação baseada em linha
A maneira tradicional pela qual o Azure Cosmos DB para PostgreSQL fragmenta tabelas é o modelo de banco de dados único e de esquema compartilhado, também conhecido como fragmentação baseada em linhas, onde os locatários coexistem como linhas dentro da mesma tabela. O locatário é determinado definindo uma coluna de distribuição, que permite dividir uma tabela horizontalmente.
O método baseado em linha é a maneira mais eficiente em termos de hardware para fragmentação de dados. Os locatários são densamente empacotados e distribuídos entre os nós no cluster. No entanto, essa abordagem requer garantir que todas as tabelas no esquema tenham a coluna de distribuição e que todas as consultas no aplicativo sejam filtradas por ela. A fragmentação baseada em linha atua nas cargas de trabalho de IoT e para obter a melhor margem fora do uso de hardware.
Benefícios:
- Melhor desempenho
- Melhor densidade de locatário por nó
Desvantagens:
- Requer modificações de esquema
- Requer modificações de consulta de aplicativo
- Todos os locatários devem compartilhar o mesmo esquema
Fragmentação baseada em esquema
Disponível com o Citus 12.0 no Azure Cosmos DB for PostgreSQL, a fragmentação baseada em esquema é o banco de dados compartilhado, modelo de esquema separado, o esquema se torna o fragmento lógico dentro do banco de dados. Os aplicativos multilocatários podem usar um esquema por locatário para fragmentar facilmente ao longo da dimensão do locatário. As alterações de consulta não são necessárias e o aplicativo precisa apenas de uma pequena modificação para definir o search_path adequado ao alternar locatários. A fragmentação baseada em esquema é uma solução ideal para microsserviços e para ISVs que implantam aplicativos que não podem passar pelas alterações necessárias para integrar a fragmentação baseada em linha.
Benefícios:
- Os locatários podem ter esquemas heterogêneos
- Não requer modificações de esquema
- Não requer modificações de consulta de aplicativo
- A compatibilidade do SQL com fragmentação baseada em esquema é melhor em comparação com a fragmentação por linha.
Desvantagens:
- Menos locatários por nó em comparação com a fragmentação baseada em linha
Compensações de fragmentação
| Fragmentação baseada em esquema | Fragmentação baseada em linha | |
|---|---|---|
| Modelo de multilocação | Esquema separado por locatário | Tabelas compartilhadas com colunas de ID de locatário |
| Versão do Citus | 12.0+ | Todas as versões |
| Etapas extras em comparação com o vanilla PostgreSQL | Nenhum, apenas uma alteração de configuração | Usar create_distributed_table em cada tabela para distribuir e colocar tabelas por ID de locatário |
| Número de locatários | 1 a 10 k | 1 a 1,5 milhão+ |
| Requisito de modelagem de dados | Nenhuma chave estrangeira em esquemas distribuídos | Precisa incluir uma coluna de ID de locatário (uma coluna de distribuição, também conhecida como chave de fragmentação) em cada tabela e, nas chaves primárias, chaves estrangeiras |
| Requisito do SQL para consultas de nó único | Usar um único esquema distribuído por consulta | As junções e cláusulas WHERE devem incluir a coluna tenant_id |
| Consultas entre locatários paralelas | Não | Sim |
| Definições de tabela personalizada por locatário | Sim | Não |
| Controle de acesso | Permissões de esquema | Permissões de esquema |
| Compartilhamento de dados entre locatários | Sim, usando tabelas de referência (em um esquema separado) | Sim, usando tabelas de referência |
| Locatário para isolamento de fragmentos | Cada locatário tem seu próprio grupo de fragmentos por definição | Pode fornecer às IDs de locatário específicas seu próprio grupo de fragmentos por meio do isolate_tenant_to_new_shard |