Modelos de fragmentação em clusters elásticos na base de dados do Azure para PostgreSQL

O compartilhamento é uma técnica usada em sistemas de banco de dados e computação distribuída para particionar horizontalmente dados em vários servidores ou nós. Isso envolve dividir um grande banco de dados ou conjunto de dados em partes menores e mais gerenciáveis chamadas Shards. Um fragmento contém um subconjunto dos dados e, juntos, fragmentos formam o conjunto de dados completo.

Os clusters elásticos no Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL oferecem dois tipos de fragmentação de dados: baseada em linha e baseada em esquema. Cada opção vem com suas próprias compensações, permitindo que você escolha a abordagem que melhor se alinha com os requisitos do seu aplicativo.

Fragmentação baseada em linha

Tabelas de fragmentos no modelo de esquema compartilhado de banco de dados único, também conhecido como fragmentação baseada em linha, os locatários coexistem como linhas dentro da mesma tabela. O locatário é determinado pela definição de uma coluna de distribuição, que permite dividir uma tabela horizontalmente.

A fragmentação baseada em linha é o método mais eficiente em termos de hardware. Os locatários são densamente compactados e distribuídos entre os nós no cluster. No entanto, essa abordagem requer certificar-se de que todas as tabelas no esquema tenham a coluna de distribuição e que todas as consultas no aplicativo sejam filtradas por essa coluna. A fragmentação baseada em linha brilha em cargas de trabalho de IoT e para alcançar a melhor margem de uso de hardware.

Benefícios:

• Melhor desempenho.
• Melhor densidade de locatários por nó.

Desvantagens:

• Requer modificações de esquema.
• Requer modificações de consulta de aplicativo.
• Requer que todos os locatários compartilhem o mesmo esquema.

Fragmentação baseada em esquema

A fragmentação baseada em esquema é o banco de dados compartilhado, um modelo de esquema separado, e 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 a dimensão do locatário. As alterações de consulta não são necessárias, e o aplicativo só precisa de uma pequena modificação para definir a search_path adequada ao mudar de locatário. A fragmentação baseada em esquema é uma solução ideal para microsserviços e para ISVs (Fornecedores Independentes de Software) que implantam aplicativos que não podem sofrer as alterações necessárias para integrar a fragmentação baseada em linha.

Benefícios:

• Os locatários podem ter esquemas heterogêneos.
• Não são necessárias modificações de esquema.
• Nenhuma modificação de consulta de aplicativo é necessária.
• A compatibilidade SQL de fragmentação baseada em esquema é melhor em comparação com a fragmentação baseada em linha.

Desvantagens:

• Menos locatários por nó em comparação com a fragmentação baseada em linha.

Compartilhamento de compensações

	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 do locatário
Versão Citus	12.0+	Todas as versões
Passos extras em comparação com o PostgreSQL baunilha	Nenhuma, apenas uma alteração de configuração	Use create_distributed_table em cada tabela para distribuir tabelas de colocalização & por ID de locatário
Número de inquilinos	1-10K	1-1 M+
Requisito de modelagem de dados	Sem chaves estrangeiras em esquemas distribuídos	Necessidade de incluir uma coluna de ID do locatário (uma coluna de distribuição, também conhecida como chave de fragmentação) em cada tabela e, em chaves primárias, chaves estrangeiras
Requisito SQL para consultas de nó único	Usar um único esquema distribuído por consulta	As cláusulas Joins e WHERE devem incluir tenant_id coluna
Consultas paralelas entre locatários	Não	Sim
Definições de tabela personalizadas por locatário	Sim	Não
Controlo de acesso	Permissões de esquema	Permissões de esquema
Partilha de dados entre inquilinos	Sim, usando tabelas de referência (em um esquema separado)	Sim, usando tabelas de referência
Inquilino para isolamento de estilhaços	Cada inquilino tem o seu próprio grupo de fragmentos por definição	Pode dar IDs de locatário específicos ao seu próprio grupo de estilhaços via isolate_tenant_to_new_shard

Conteúdos relacionados

• Visão geral de clusters elásticos.
• Tipos de tabela em clusters elásticos no Banco de Dados do Azure para PostgreSQL.
• Perguntas frequentes sobre clusters elásticos do Azure Database para limitações do PostgreSQL.